Better Software - November 2008 - (Page 38)

Schedule How long will the project take? Are we on track to deliver the product as promised? Many organizations ask these questions, but few project managers have ready access to the information needed to answer them. Good schedules are based upon defined chunks of project work called tasks, assumptions about the effort required to perform these tasks, and assumptions about the availability of people to work on the tasks. This information is combined to create duration estimates for each task. Task duration combines with task sequence information to create baseline schedule information. The schedule doesn’t just answer the question “When will the project be finished?” The schedule also describes a baseline that indicates when the project’s component tasks will occur. Like resource status, the challenge when providing schedule status is to summarize information so that executives don’t get buried in data and lose important information. Anyone who has worked on a large system project has seen complex schedules with hundreds of tasks maintained in a scheduling tool. If it is kept current, this detailed information can be useful to a project manager; in its raw form it is usually not helpful for briefing executives. Fortunately, complex schedule information can be summarized with milestones. “Milestone” is a technical scheduling term that is worth understanding because milestones are useful. A milestone represents the moment in time when a specified condition is met. People often confuse tasks with milestones because the two are related, but they are as distinctly different as programs and data. A task describes a unit of work. Tasks consume resources and have a duration that describes how much time is estimated to elapse between the start and finish of the task. Milestones consume no resources, have zero duration (they represent a specific moment in time), and are used to give visibility to the completion of one or more tasks or to represent significant moments in the project’s life. Figure 4 provides an example of a milestone. The milestone labeled “Dressing Figure 4 hardware initially planned for October purchase is being procured early. The resource consumption (aka “burn”) rate often varies a bit from one month to the next, so small adjustments aren’t necessarily a concern. To track overall budget performance, the missing piece of the puzzle is a summary of all expenses and updated estimates compared to the original baseline budget, which might look like figure 3. As shown in figure 3, the current expectation is that the project will finish about $9,000 over budget. While this might be an issue for the executive sponsors, it helps put September’s progress in context. While budget information alone will not help us know whether the project is on track to deliver a quality product at the desired time, it does represent an important part of the overall picture. Figure 5 38 BETTER SOFTWARE NOVEMBER 2008 www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

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.