Better Software - November 2008 - (Page 39) “when asked whether the project manager should try to show bad news to executives in the best possible light, a friend once answered, ‘i didn’t invent reality; they pay me to explain it to them.’” Complete” is used to designate the completion of the tasks that precede and comprise it. The milestone is defined as “This milestone is complete when ‘Put on Tie,’ ‘Put on Shoes,’ and ‘Put on Smile’ are all complete.” If you are in my carpool, you don’t care about the details of my morning dressing ritual, but you do care when I’m dressed and ready to go. This milestone encapsulates the details. I can tell you that I expect the milestone to be complete at 7:30, and you need not concern yourself with when I put on my socks. Another use of milestones is to identify and bring visibility to a project’s external dependencies—key events in the project that are not directly within our control. For example, imagine that operations tells us that our server will be available for use on August 15. One way to show that event in our schedule is by creating a milestone called “New Server Available to the Project Team.” The milestone would be scheduled to occur on August 15 based upon the information from operations, and we would plan our project as if this were the case. Examples of milestones include: • Unit testing for all modules complete • Customer approval of prototype received • Data conversion complete • New disk space available to the project team • Project ready for Beta distribution When the initial project schedule is constructed, prudent project managers identify milestones that are significant and can be explained easily to executives. The baseline schedule shows when these milestones are expected to occur. Subsequent status can show any changes in that expectation. The milestone chart in figure 5 shows schedule performance for our sample project. What is not shown in this summary but must be carefully monitored and managed are the relationships and dependencies among the milestones. Failure to complete some milestones on time can have a ripple effect through the project that may require explanation. Project management tools help manage these dependencies. its sponsoring executives and represents these as part of status. Again, the important idea is to capture the baseline (original scope goals), the progress toward the baseline, and any changes anticipated. Imagine we begin a software project with the assumption that the final product will represent fifty user stories. Using fifty stories as a crude baseline measure for scope, we could track stories through a “lifecycle” consisting of: • Identification—Analyst identifies story • Approval—User agrees story correct and in scope • Implementation—Add support for the story to the product • Testing—Complete testing for the story • Acceptance—User signs off that the story is acceptable as implemented Figure 6 shows not only status for the date in question but also progress Scope The scope dimension of the project accounts for whether we are accomplishing the objectives initially envisioned for the project. This includes implementation and delivery of the products or services with all features, functions, performance, reliability, quality, and compliance with process constraints that were agreed upon. Measures of scope can be complicated and vary by project, but a good project manager seeks useful summaries and surrogates for the dimensions of quality important to the project and Figure 6 www.StickyMinds.com NOVEMBER 2008 BETTER SOFTWARE 39 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.