.png)
Twitter
Facebook
RSS
Linkedin
Scheduling on Trouble Projects
From years of experience investigating troubled projects, the timeline is often the entire problem. Auditing the schedule starts by looking at the parameters used to build it. Three primary methods are used to build a schedule:
- Backward pass: start with the end date and build the schedule backwards to arrive at the start date.
- Forward pass: begin with a projected start date and add tasks to determine the end date.
- The squeeze method: set an end date and change durations and dependencies until the project fits in the time allowed.
The first two are sensible ways to build a schedule. All too often, though, the third option is used. The latter builds an unrealistic schedule. Assuming task duration estimates are correct, the only way to squeeze projects reliably into a timeline is to change the methodology, remove scope, or, most likely, a mixture of both. Simply making it fit is a common problem with a project manager who wants to please upper management that has unrealistic expectations.
When a project must meet a specific date, the primary triple constraint is obvious—the schedule—scope, budget, or both must suffer. Contrary to popular belief, money does not solve everything, so scope must be cut until a forward built schedule achieves meeting the required end date.
|
Even when all the tasks fit into the timeline, some schedules are better than others. Ensure that high-risk tasks are scheduled as early as possible. Front-loading risk provides reaction time. If trouble arises, often scope items can be changed, re-scheduled, or removed to compensate and hold the original schedule.
Thinking that it is all going to fit somehow is unrealistic and sets the project up for future issues.
When a Due Date Cannot Change
Projects with absolute time constraints are abundant. To name a few, they may be related to tax cycles, school sessions, elections, census data, or government regulations. Missing the deadline by days may postpone the project's usefulness by years. Consider what would happen if one of the multiple U.S. personal tax programs used by millions of people was delayed until March, when taxes are due April 15. The impact would be devastating to the business. In these cases, the cost of a delay is so large that everything else is subordinate to the release date. Canceling the project is not an option, as that would be tantamount to closing the doors on the business. There is really only one option—reduce scope.
Reducing scope does not require removing any item; it may simply mean delivering some functionality later. Segmenting the deliverables to provide the core requirements on time and other less important functions later, may solve the problem. As an example, the tax programs mentioned above all deliver the core program by the end of the year, however, during the first few months of the year they provide updates for last minute changes in the tax laws. If there are forms that are not complete, the program warns the taxpayer telling them to wait to submit them. Most taxpayers are able to submit taxes as soon as their W2s arrive, others must wait for the final tested forms.
A similar option is to phase the project. Phasing divides deliverables into sets of prioritized features. The most needed features are deployed first and others are delivered later. Configuration of the packages is highly dependent on the specifics of the project and usually requires significant negotiation with the customer and the end users. For example, if a project is supposed to acquire data on sales to allow managers to see trends, data are needed prior to reporting. It could take months of collection before enough data are available to generate meaningful reports. Many customers will be upset not being able to report on the data as soon as the system goes live, however this option is better than losing months of critical data waiting for reports to be completely designed and approved.
.png "Filling Exectution Gaps cover")
.png "Buy RPP on our site")
