Sunday, 18 July 2010 00:00

Management On A Mobius Strip

Rate this item
(0 votes)

Dilbert's Boss' Visionary Leadership, Dilbert © September 9, 1999, United Feature Syndicate, Inc.

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 work (controlling the burn rate) and 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:

  1. Backward pass: start with the end date and build the schedule backwards to arrive at the start date.
  2. Forward pass: begin with a projected start date and add tasks to determine the end date.
  3. 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 properly. 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.

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.

Read 12229 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • Organization Change Management for Project Teams Workshop
    Want to buy it now?

    Ask for more info below, or if you are convinced, just add it to your cart.

    Projects are never a success when they are delivered—their product must be adopted to declare success. Whether you are delivering a process for HR, creating new model of cell phone for your customers, or implementing a new ERP system for your company, if they do not see value in the output of your project, it is a failure. Most project teams, however, are focused on maintaining scope, schedule, and budget, they are far removed from the end-user, and they have little concept on how to persuade someone to use what they are developing. The fact of the matter is, though, that if they are the first people involved in the making a tangible product that their customers can use, adapt, and enhance to create value.

    Organization Change Management for Project Teams helps your project manager, their teams, and their stakeholders:

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References

Sitemap