The Work Breakdown Structure and Project Estimation

1. Define Activities

   Nota:

   • Identifying what activities must be completed to produce the project scope deliverables
2. Sequence Activities

   Nota:

   • Determining whether activities can be completed sequentially or in parallel and any dependencies that may exist among them
3. Estimate Activity Resources

   Nota:

   • Identifying the type of resources (people, technology, facilities, etc.) and the quantity of resources needed to carry out project activities
4. Estimate Activity Durations
5. Develop Schedule

   Nota:

   • Based on the availability of resources, the activities, their sequence, and time estimates, a schedule for the entire budget can be developed
6. Control Schedule

   Nota:

   • Ensuring that proper processes and procedures are in place in order to control changes to the project schedule

1. framework for developing a tactical plan to structure the projectwork
2. PMBOK : hierarchical decomposition of the project’s scope

   Nota:

   • that the project team will deliver over the course of the project.
3. Total scope of the project divided and subdivided into into specific deliverables

   Nota:

   • that can be more easily managed
4. provides an outline for all of the work the project team will perform.
5. Work Packages
   1. WBS decomposes, or subdivides, the project into smaller components and more manageableunits of work calledwork packages
      1. provide a logical basis for defining the project activities and assigning resources to those activities
         1. each phaseshould provide at least one specific deliverable
6. Closely related

   Nota:

   • For example, a deliverable may be a prototype of the user interface, but the milestone would be a stakeholder’s formal acceptance of the user interface.  Only the formal acceptance or approval of the user interface bythe project sponsor would allow the project team to move on to the next phase of the project.
   1. Deliverables
      1. Tangible, verifiable work products
         1. Includes
            1. presentations or reports
            2. plans
            3. prototypes
            4. the final applicationsystem
   2. Milestones
      1. significant event or achievement
         1. provides evidence
            1. deliverable has been completed or that a phase is formally over.
      2. advantages
         1. keep the project team focused

            Nota:

            • concentrate your attention and efforts on a series of smaller, short-term deliverables than on a single
         2. motivate a project team
         3. reduce the risk of a project
            1. review the progress of the project

               Nota:

               • Additional resources should be committed at the successful completion of each milestone, while appropriate plans and steps should be taken if the project cannot meet its milestones.
            2. acting as cruxes

               Nota:

               • E.g.  suppose that an organization is building a data warehouse using a particular vendor’s relational database product for the first time. A crux for this project may be the collection of data from several different legacy systems, cleansing this data, and then making it available in the relational database management system.
               1. testing of an idea, concept, ortechnology that is critical to the project’s success
         4. mechanism for quality control
            1. deliverables should be accepted after users are satisfied that their requirements are met
         5. Keeps team focused
            1. project tasks must not only be completed and deliverables are delivered, but must be done right
7. Developing WBS
   1. Deliverable Oriented
      1. produce something, not merely on completing a specified number of activities
   2. Support the Project’s MOV
      1. Ensure WBS allows for the delivery of all the project’s deliverables as defined in project scope

         Nota:

         • this will ensure that the project is more likely to achieve its MOV
         1. 100 percent rule

            Nota:

            • criterion in developing and evaluating the WBS
            • The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher(parent) element.
   3. The Level of Detail Should Support Planning and Control
      1. bridge between the project’s scope and project plan

         Nota:

         • i.e. schedule and budget support not only the development of the project plan but allow the project manager and project team to monitor and compare the project’s actual progress to the original plan’s schedule and budget.
         1. Error
            1. Too little detail

               Nota:

               • result in a project plan that overlooks and omits important activities and tasks -> overly optimistic schedule and budget
            2. Too much details

               Nota:

               • should not be a to-do list of one-hour tasks.
               • excessive detail results in micromanagement
   4. Involve the People Who Will Be Doing the Work

      Nota:

      • ensure that the WBS has the appropriate level of detail
      • A person who has experience and expertise in a particular area probably has a better feel for what activities need to be performed in order to produce a particular project deliverable.
      • confusion and misunderstanding can occur when different people work on different parts of the WBS
      1. WBS dictionary

         Nota:

         • where various work packages can be described
         1. code or account identifier
         2. a description of the work
         3. a list of the project team members assigned to carry out the work,
         4. contract information
         5. quality standards, and resources required.
   5. Learning Cycles and Lessons Learned Can Support the Development of a WBS
      1. project team focus
         1. facts
         2. assumptions
         3. research
   6. Develop work packages for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC)

1. Guesstimating
   1. Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget.
2. Delphi Technique
   1. multiple experts who arrive at a consensus after a series of round-robin sessions in which information and opinions are anonymously provided to each expert.
3. Time Boxing
   1. a box of time is allocated to a specific task.
4. Top-Down estimating
   1. involves estimating a schedule or budget based up on how long the project or an activity should take or how much it should cost.
      1. used whencompetitive necessity is an issue
      2. unrealistic expectations can lead to projects with very little chance of meeting their objectives.
5. Bottom-Up estimating (WBS)
   1. The WBS outlinesthe activities that must be completed, and anestimate is made for each of the activities.
   2. estimates are a function of the activity itself, the resources, and the support provided.

      Nota:

      • These esti- mates are also a function of the activity itself (degree of complexity, structuredness, etc.), the resources assigned (a person’s knowledge, expertise, enthusiasm, etc.) and support (tech- nology, tools, work environment, etc.).
   3. Estimates may be analogous to other projectsor based on previous experience
   4. The various durations are then added together to determine the total duration of the project.
6. Analogous Estimates (Past experiences, ISBSG)
   1. developing estimates based upon one’s opinion that there is a significant similarity between the current project and others (Rad 2002).
7. Parametric Modeling (Statistical – Function Point, etc.)

1. Brooks’ Law
   1. Adding manpower to a late software project makes it later.
2. Increases the total effort necessary
   1. The work & disruption of repartitioning
   2. Training new people

Nota:

• introduced for estimating the software development effort

1. Lines of code (LOC)
   1. counting or try-ing to estimate the amount of code that must bewritten
   2. The number of LOC may provide an idea of the size of a project, but it does not consider the complexity,constraints, or influencers that must be taken into account.
2. Function points
   1. synthetic measures that take into accountthe functionality and complexity of software
   2. function points are independent of the technology or programming language used,one application system can be compared with another.
3. COCOMO
   1. COnstructive COst MOdel
   2. Estimates for a software systems effort are deter-mined by an equation based on the project’s complexity.
   3. software project classification
      1. organic (relatively simple and straightforward)
      2. embedded (difficult)
      3. semidetached (somewhere in the middle)
   4. Once the effort, in terms of person-months,is calculated, a similar procedure using another model can estimate the project’s duration.
4. Heuristics
   1. rules of thumb that are applied to estimating a software project.
   2. basic premise is that the same activities will be repeated on most projects.
   3. may include
      1. assigning a specific percentage of the project schedule to specific activities
      2. using other metrics such as function points.

1. Scope changes
2. Overlooked tasks
3. Poor developer-user communication
4. Poor understanding of project goals
5. Insufficient analysis
6. Changes in team
7. Lack of project control
8. Not identifying or understanding impact of risks

1. Rate at which requirements may change
2. Experience & capabilities of project team
3. Process or methods used in development
4. Specific activities to be performed
5. Programming languages or development tools to be used
6. Probable number of bugs or defects & removal methods
7. Environment or ergonomics of work space
8. Geographic separation of team across locations
9. Schedule pressure placed on the team

1. Experience
   1. Lesson Learned
   2. Best Practic
2. Revision
3. Monitor
4. Focus on deliverables
5. Control