SOME OF YOU OLD-TIMERS may remember a classic critique of the U.S. educational systems titled “Why Johnny Can't Read.” I have adapted that title for this column, but have changed the name in the interests of gender equity.
Q. I recently worked on a project that was able to meet its scheduled completion date only by severely overworking every member of the team. Pretty much every other project I have ever worked on has been late, over budget, or both. Am I the only one?
You do have lots of company. If you didn't, PMI® probably wouldn't have grown as fast as it has over the past several years. But I have worked on many projects that were completed successfully without burning out the team. The successful projects all did the following:
Treated each phase of the project life cycle as a separate project when there was significant uncertainty in product scope
Developed a work breakdown structure that was as complete as possible at the start of the project or phase and then updated it regularly throughout the project
Developed range estimates of effort, cost, and duration for every WBS item
Had cost and schedule baselines that included an allowance for risk
Made resource commitments part of the plan (and if the promised resources did not materialize, the dates were changed)
Held regular, rigorous performance review meetings.
What prevents everyone from doing this? Generally, it is a management issue. How can you tell if your organization has a management problem? Look to see who gets rewarded. If it's the “heroes” who go to extraordinary lengths at the last minute to overcome their lack of planning, then you know the answer.
But keep in mind that management is seldom 100 percent responsible. You may have to provide them with a little bit of education.
Q. I‘d like to use range estimates, but both my project management software and my manager insist on a single point estimate. Any suggestions?
William R. Duncan, PMP, is with Project Management Partners, a project management consulting and training firm headquartered in Lexington, Mass., USA. He is the former director of standards for PMI and was the primary author of the 1996 version of A Guide to the Project Management Body of Knowledge.
The first step is to help your manager understand the difference between an estimate and a budget. Although the current edition of A Guide to the Project Management Body of Knowledge is not quite as clear on the subject as it might be, the following quote from the introduction to Section 7.2 should help:
“Cost estimating involves developing an assessment of the likely quantitative result—how much will it cost the performing organization to provide the product or service involved. Pricing is a business decision—how much will the performing organization charge for the product or service.”
These two sentences apply whether we are discussing the project as a whole or as individual activities within the project. You should develop a range estimate first, and then use that estimate as input to the pricing/ budgeting decision.
Q. My manager is complaining about the poor quality of our schedule estimates. Yet in every case, the reason we were late was because of product scope changes.
Hmmm. If I understand correctly, your manager would consider the project well-estimated if it finished on time and delivered half the desired product scope, but would count it poorly estimated if it were a month late and delivered twice as much. Maybe what we've got here, in the words of the warden in Cool Hand Luke, is “a failure to communicate.”
I‘m going to assume that your manager is rational and reasonably intelligent (if that's not true, skip the following and go find another job). For such a manager, I think you have two choices:
Argue for both a cost and schedule contingency on your next project to accommodate the product scope changes that you know are going to occur. You can calculate how much you need by looking at previous projects. A separate contingency budget has the added benefit of allowing you to track the impact of changes more accurately.
Argue for a revised definition of schedule success that is driven by the accuracy of your individual activity estimates rather than by the project as a whole.
One other point:You also need to make sure that the process of approving product scope changes is appropriate so that you don't create a false sense of success by turning bad planning into approved scope changes.
Q. I work on high-technology projects where product scope changes are the rule rather than the exception. We are thinking of changing our approach to state that schedules are only fixed to the next significant milestone. Your thoughts?
Schedules are only fixed (and fixable) to the extent that the assumptions which underlie your duration estimates remain constant. Rather than state that the schedule isn't fixed or can't be fixed, let's state the assumptions that a “fixed” schedule is based on:
The work definition (WBS) is complete.
Our estimates are reasonable.
Adequate resources (adequate in terms of both quantity and quality) will be provided when needed.
Deliverables will be reviewed and approved in a timely fashion.
There are no major holes in our understanding of the product.
Our performance measurement baseline includes reserves to accommodate minor holes in our understanding of the product.
We are willing to sacrifice something else (cost, scope, or quality) in order to ensure that the date is met.
There will be no major product scope changes.
So, “should we change our approach to state that schedules are only fixed to the next significant milestone?” The answer is no if the assumptions are true, and yes if they aren't.
Reader Service Number 030
There is an exception. You may need to make a commitment for business reasons (e.g., to get a contract) that you wouldn't normally want to make for project management reasons. But if you do this, you'd better be ready to take a hit or plan to work like crazy to get all your assumptions into the contract.
Q. When I am developing a range estimate, should the high and low limits of the range reflect different assumptions?
You should not vary any assumption that will have a direct and predictable impact on the estimate: different scope, different resource skill level, and so on. For example, if the resource assigned to do the work changes, the estimate will change unless both resources have similar skills. Range estimates are intended to accommodate random variation in outcomes.
Q. I have several activities on my project that may take no time at all, or may take several days (never less than five). In developing a range estimate, should I use zero days as my optimistic number?
No. In general, range estimating requires a continuous distribution, and your distribution is not continuous—there are no possible outcomes between zero and five days. What you really have is a decision-tree-like situation:
X probability that the result will be zero duration
100 - X probability that the result will fall within the range of five to whatever the upper limit is.
As a first step, you can use project management software to run a simulation that allows for this type of probabilistic analysis. There are a number of software vendors that provide this capability—check out the recently released Software Survey. In addition, there are some workarounds that might also give you a good result:
If this work isn't on the critical path, you may be able to safely ignore the possibility of zero results.
If there are many activities with zero results possible, you may be able to accommodate them with a smaller schedule contingency.
A simulation will help you understand the range of probable project outcomes, and it may also provide insight into the best way to schedule the individual activities and resources as well. You might also plan on some extra management time for this project to accommodate the schedule adjustments that will be needed when one of these activities takes no time at all.
Q. Can you point me to any studies, analyses, data, experiences, or otherwise educated guesses on how much time an individual project team member typically spends on nonproject work?
There was a Bell Labs time-and-motion study back in the late 1950s or early 1960s that was widely quoted, but I don't have the exact reference readily available.
I have a number of clients who have internal, unpublished data based on years of time reporting. This data generally shows 25-40 percent of total staff time devoted to nonproject activities. This data is for individuals who are “full time” on projects; the percentages would obviously be lower for someone who also has functional responsibilities. Lower percentages tend to prevail at smaller companies without much infrastructure, but these same companies also tend to have people working longer hours, so the total number of hours devoted to nonproject work is similar.
Some other thoughts:
I think it is important to use your own time reporting data to develop your own numbers. This provides both credibility with management and greater assurance that the numbers will work for you in your organization.
Be careful about using someone else's data unless you know all the details. For example, does the base include vacation and holidays or only days actually worked?
I would normally include things like project status reporting as project work; others might not. Another example of the importance of getting your terms defined.
I heard of a U.S. Department of Defense study that said time-spent data had to be recorded by the employee daily (you can report it less frequently, but write it down at the end of the day) or it was subject to a 20-30 percent accuracy error.
Accurate time reporting provides another benefit: It is required for feedback as to project performance and estimating accuracy.
GOT A QUESTION about the practice of project management? Send it via e-mail to [email protected] or fax it to +781-862-9908.