Managing On A Mobius Strip

The two most common project attributes that raise the red flag are cost and timeline problems. Both are easily measured and inextricable intertwined. As the timeline extends, there is a commensurate increase in cost; similarly, as cost goes up (usually from increased scope) the timeline increases. However, time is different. Benjamin Franklin said it best, "You may delay, but time will not." Work can stop (controlling the burn rate) extraneous features can be removed (decreasing the required work) but time marches on. We cannot control time. Although intuitively obvious, the concept seems to escape a large number of managers and executives.

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.

Case Study: Starting a Project Red

More than once I have been asked to work on projects that are red, only to find they have not been started. On one in particular, I was close enough to watch the situation as it slowly drifted toward the crimson end of the spectrum; and, too distant to correct the situation.

This project was a small part of a much larger program. The program had a twelve-month delivery schedule and the date was immutable—specific government regulations required the system be in place on a specific date. The project in question was initiated on the date the program started; however, there was significant confusion on how to utilize a large software vendor. Besides selling software, this vendor also had a systems integration (SI) division that could help with the implementation. The client wanted to contract the SI group on a fixed-price contract and the vendor wanted to use a time-and-materials model. The internal debate on whether to use the SI and negotiations on the Statement of Work took six months of the allotted year.

To make the project fit, numerous compromises were struck with the customer and one of the three software packages from the vendor was only partially deployed. Because of the compromises, the customer had to implement dozens of labor-intensive processes. Nonetheless, the government requirements were met and the project was considered a success. The complete functionality was deployed nearly eight months after the initial deadline. The cost to the company was huge, but paled in comparison to the hundreds of millions of dollars in new revenue.

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.

Delicious

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.

Tags: IT Failure, Project Management, Scheduling