Page 49 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT
P. 49

Unit 2: Step Wise Project Planning




          2.1.2 Scope Definition                                                                Notes

          Scope explanation often account for a paragraph or two in a Business Case or Project Charter.
          Regularly, they are qualitative and/or focus on general statements. “We will develop service by
          providing an information system to answer to customer inquiries.” Is it a real time system? Is it
          all screen-based? What reports can be produced? Where does the knowledge come from? What
          management is required  for the  data? Is all the data compatible?  Do you want to  generate
          standard letters? How many letters? How customizable are the letters? Do you want to store the
          questions? Do you  want to  store the answers?  In order  to define the scope, there will  be
          supposition that need to be made. There is no point in waiting until everything is clear to define
          scope. By that time, the project will possibly be finished. Each of these assumptions should be
          documented and followed up at a later date to validate the scope. If the supposition is false, it
          may have an impact on the scope.
          There are plentiful  ways to define. Ideally several ways should be used. Each  looks at the
          situation from a different perception and will elicit different information. We look at three main
          ways in this paper. They are:

              Define  Deliverables
              Define Functionality and Data

              Define Technical Structure
          Define Deliverables

          One method to focus people on the scope is to describe the internal and external deliverables:

              External deliverables are things the project delivers to the users, e.g., screens and reports.
               Users usually think of a system in these terms. It also comprises any hardware or software
               required by the users or the project team.
              Internal deliverables are things the project makes internally, e.g., Project Charter, Business
               Requirement Specification, etc.
          It is likely that the users will not be completely clear on all the deliverables. In this situation you
          can make generic assumptions. For example, you might not know precisely what reports are
          required but you allow for 12 unspecified reports.

          Once the  external  deliverables are described,  the  Project Manager can define the internal
          deliverables.

          Example External Deliverables

           Name              Description
           License Detail Screen.   Screen to enter and view license details
           Company Summary   Screen to view all licenses issued by a particular company. Facility to drill
           Screen            down to License Detail Screen.
           License Due Report   Report listing all licenses due in the next period. Facility to select a period e.g.
                             1 week, 4 weeks, quarter
           5 Reports         Allow for 5 unspecified reports
           Server            Server to run the application
           Etc.






                                           LOVELY PROFESSIONAL UNIVERSITY                                   43
   44   45   46   47   48   49   50   51   52   53   54