Project management tools and techniques help us to do the job we need to do. Yet, the tools can often become overwhelming with updating them, trying to get just the right report out of them, etc. It is easy to lose track of what we are trying to achieve. Estimating a schedule is one of the most critical things we will do so let’s see if we can get it right.

Is Our Project Estimating Facing The Diet Dilemma?

The diet dilemma is generally that everyone knows how to lose weight. The crucial issue is the ability to carry it out. There is a billion dollar industry that caters to “helping” folks lose weight. However, the fundamental is that one needs to burn more calories than one consumes. Simple? Yes. Easy? No, not for many people. Focusing on all the weight loss products, techniques and alternatives can easily obscure the fundamental of simply consuming less calories than one burns. Once we get back to basics, then these diet techniques and programs, just like project management tools for a project, can vault us to success. The trick is to keep our focus on the real purpose at each phase and to recognize the real reason why it is hard.

Get The Overall Schedule Right.

The classic method to setting a schedule is to call multiple meetings or send out multiple requests to get all the details and then roll them up into a plan and a schedule. Inevitably the schedule is adjusted to meet the desired delivery or completion date. Has this worked in your company? Often, the answer is no.

Why not? Because something was missed or something unexpected came up in the actual project. Alternatively, we were given a deadline and told this is what our plan has to show in the end. Our job is to figure out how to deliver by the given date.

How do we fix this in our project? Call more meetings? Get more people involved? Include more details in the Gantt/WBS? Get better project management schedule tools?

No. This is treating the symptoms and not the causes.

The cause? We don’t know everything up front that needs to happen or what will go wrong. On top of that, if we could collect up and enumerate everything that must happen in the exact order, we probably could never finish recording it all, and we probably couldn’t find a tool that could capture all the details in an appropriate way. Managing the project management tools themselves becomes a significant task (i.e., the diet dilemma) and starts to distract from managing the actual effort.

Collectively, however, we do know everything that needs to be done. How do we remember a song? We certainly don’t have every word explicitly memorized. Instead as we sing the first part, the next part naturally pops to mind. We have to sing the whole song to write it down. The same is true for a project. The catch is that to sing a project, we have to do the project. The key is that what needs to be done comes back to people as they do it. Again the classic approach is to try and figure out all the details in advance and to embed these details into something like Microsoft Project. Instead, we want to leverage James Surowiecki’s “The Wisdom of Crowds ” in our planning. This becomes a balancing act between getting the key milestones and durations but leaving the details to the folks doing the work. One key detail is how to get a good estimate of the overall project time. This is often easier than one would expect.

Also look at It Is The Project Schedule Stupid

Get The Schedule Right By Looking At Recent Projects.

We do have a record or data on previous, similar projects, yes? If so, we will want to spend time seeking evidence to one question: How long did it actually take? We will also want to do this with the actual people who’ve managed these other projects. Keep in mind that most people, no matter how intellectually gifted, simply will not remember accurately how long things took or where they spent their time. So pulling data from records of actual projects is critical. This is not always easy as project records may be hard to find. The dates projects started and finished may not have been recorded. Records that are kept may have been of the “last replan” and not of the whole project from beginning to end. Nevertheless, capture what data we can and see how long projects like ours appear to have taken.

To track estimate accuracy see You Really Can Know If Your Project Estimates Are Accurate

So we now know that projects such as ours took, for example, about twelve months. Some took longer and some took shorter.

The Most Recent Completed Project Is Probably How Our Project Will Go.

What has happened most recently reflects the net effect of: people + processes + tools + culture of our organization. The chances that it will change significantly during our project is slender. Many people would tell me that I shouldn’t base my project on the ones just completed. “You will not have all the problems they had!” Or they will say, “We have fixed all those problems!” Don’t believe it. It is a good goal, but it is a good bet that any non-trivial change to an organization will take years to have a true impact. Of course, if a project was delayed due to hurricane Katrina, we probably need to base our schedule upon another project.

For more see Getting The Schedule Right Is Hard! But Not For The Obvious Reasons

Expect To Have Problems We Can’t Anticipate.

But we can plan for them. We just did. By basing our schedule estimates on recently completed projects we’ve factored in many things that went wrong. We will have some of the same problems. We will have some problems that were not seen by those other projects. By using the track record of the previous completed projects, we have planned for a typical amount of things going wrong. Many project management methodologies include a method of putting slack or buffers into the schedule. Using recent projects naturally includes these items and does so based upon actual data rather than on guesstimates (e.g., add 10%, etc.).

If in fact our project delivery process is improving, we will still pick up these improvements in our schedule. Our project’s end results will show improvements. The next project that leverages off our experience will get our schedule improvements and build on them. What too many projects attempt to do is to spend their productivity improvements before they have any. I’ve often had to explain to folks that the new initiatives that intend to improve things by, for example, 20% will benefit the next project, not the current one. The initiatives that we will get the benefits from are those that were started in recent past projects. These are the improvements that are proven and mature and have become part of the process. Many improvement efforts never succeed. We don’t want to base our schedule on the gains of a still theoretical improvement.

Trust People To Know How To Do The Job.

If we can’t trust people to do their job, we are in a real pickle anyway, and project management tools are not going to help. Also, these same people are the best ones to figure out that they don’t know something, or they’ve overlooked something. They are the best people to fix a problem in their area when it comes up. We want to empower them to identify and fix the problems. We have. We gave them the time they needed by the way we set the overall schedule.

If we have a classically compressed schedule, what will happen when a problem comes up? A milestone will slip and previous milestones have either also slipped or have certainly not come in early. We will ask for more status and regular updates from our team to explain to more senior management what is going wrong and how we will fix it. We might have multiple meetings a day. We will probably be having multiple meetings with more senior management. They will want more information and probably bring in “help.” This “expert” help will need more information. These “experts” will need time with our folks doing the work to get up to speed. Everyone will then pepper our team with questions, with meeting requests and with requests for updated status. If this is happening to us or typically happens on past projects, this is a good indication that our schedules are not in line with reality.

Highlight Problems As They Happen.

Don’t panic, but don’t hide the problems. Show the problems as they happen and show how past problems have been resolved. They have been resolved, yes? If we have a reasonable schedule then probably yes. If we gave our team a reasonable schedule, they’ve probably also completed or delivered some things early and a bunch on-time. This also builds confidence so when something does go wrong, and it will, more senior management (and our management peers) will be more inclined to monitor what is happening rather than intervene in what is going on. If this is our first project or our organization consistently has problem projects, then we may get more help then we want. Our job is to have confidence in our planning and our team and to reflect that back to those trying to help.

Capture What Actually Happens In Our Project, As It Happens.

We will keep some kind of meeting minutes, yes? Status slides? Project plans? Keep and archive every version of the status and of the plan. If we find ourselves “replanning” to fix a project, still keep the history that led up to the replanning. Most major projects I’ve worked on have been replanned numerous times. The instinct is to throw away all the previous data, slipped milestones, etc., because they no longer seem relevant and who wants to dwell on them. Yet, it is exactly this information that is most useful to the next project (our next project). The key insight is not that it finally took 12 months from the last replanning effort. The key insight is that a major project will get replanned three times over the first six months and then end with a final 12 month plan.

Planning For Problems Is Not “Planning To Fail.”

This one mystifies me. In one company for whom I worked, every product project we had leading up to the current project was late by at least three months. Every one of them missed their “final software” delivery point. We had to continue delivering new software many months after the date when the software should have been development complete. So while I showed the classic “final software” date in my plan, I also showed how we would fold in and manage any late software deliveries, since we always had them. “You are planning to fail!” was the reaction. On another project, when told by the software development team the date when they would be development complete, I asked them how we would handle any late deliveries that did not make that date. Their response was “we don’t plan for late deliveries.” I asked them how many times had they been 100% complete on the indicated date. They said never, but they would this time. I asked them how many times in the past have they made that same promise. They said every time. I asked them why it would be different this time. They gave me a list of reasons. I asked them if they had a list of reasons the last time they said they would be on time. They said yes.

There is a fear that planning for problems, especially a slip in schedule, communicates to folks that it is OK to be late or to have problems. It is not the plan that influences folks. It is the past history of such plans. At the same company I mention above, we always missed our ship date by at least three months. So the development teams knew they had more time than indicated, because they knew the schedules were unrealistic. They knew that the corporate culture required them to say yes they can hit the schedule but they also knew it was normal to miss it. At this same company when we finally gave the teams a realistic schedule, one that unsurprisingly was three months longer than we normally planned, we delivered the product on time for the first time in the memory of our largest European customer. Common wisdom would have suggested that by allowing three more months the team would have taken those three months and then added a few more on top of them. It didn’t happen that way. In fact, in over 30 years of managing projects in both government and industry, it never happened that way. The trick to on time delivery is to know how to set a good overall schedule.

For more see why In Project Management 9+3 Is Not Equal To 12

Getting The Schedule Right Is The Best Thing We Can Do For Our Project.

In my 30 plus years of managing efforts, once the planned schedule got a dose of reality, many of the regular problems go away. The critical problem that goes away is the inability to complete a project on time. Many other problems, that often look technical in nature, also tend to go away as we have now allocated the right amount of time to do them. This includes the time needed to handle the typical things that go wrong. Also, many of the existing management oversight procedures and processes tend to become obsolete. This is because they were generally put in place as a reaction to past compressed schedule induced problems.

Padding The Schedule Is Not The Same As Getting The Schedule Right.

Padding in this case means to arbitrarily put in extra time. We want to put in only the time we need. That is why we base our efforts on recent completed projects that are similar to our own. When I mentioned above that we “added” three months, we really didn’t add anything. We just observed that it took us consistently 18 months to deliver a new product, but we consistently planned as if it took 15 months. If we truly believe our project will be more challenging than those that came before it, then we will pick the longer projects upon which to base our project.

We want a challenging schedule where everyone has to be on the top of their game to get it done on time (for reasons why, see 3 Secrets For Successfully Putting Your Project Management Team At Risk). We want to finish exhausted but with success. People will work hard and long and keep coming back for more if the efforts are successful. Failures will wear them out. While many will continue to work their hearts out, we will not get the same productivity and creativity out of them that a successful effort would generate.

We can use all sorts of project management tools to help us get the schedule right. I’ve found that focusing on tools to get it right often encounters the “diet dilemma” where we spend more time on feeding the technique than on getting a schedule we can believe in. Once we’ve mastered scheduling based upon recent past performance, we are in a better position to get the most out of schedule estimating tools and techniques.

Does your organization consistently deliver their projects on time?