The 20-Percent Startup Solution

How to stop playing games with your project schedule

Most baselined project plans are inaccurate because they have unrealistic start dates, finish dates, work hours, costs, and/or durations. The following are examples of this age old problem and how the 20% startup solution can be applied to build more accuracy and creditability into your project plans. Keep in mind that poor estimating during the planning phase is the largest contributor to project failures.


Realistic Work Schedules

The standard work week is normally set at 40 hours or 2,400 minutes. Let’s be realistic! No one is available 100% of their time to work on project(s)! People take breaks, have long lunches, have-one-one meetings, get stuck in traffic, have time off, and so on. Therefore, you should assume a resource is only available 80% of their time, at best, to work on projects. 80% of a work week is equivalent to a four day work week. It’s likely that management would never buy into four day work weeks, so you have to stick with the standard five days, but you should set the maximum units of availability for each resource at 80%. If a resource is available only half-time for a project, then set the maximum units of availability at 40%. Also remember, when setting up your project’s working time, to include corporate holidays, plant shutdowns, training, maternity leave, and/or individual vacations.


Buffer Insurance Protection

No plan ever runs according to schedule. It’s inevitable that some tasks will come in late, so you will need some wiggle or breathing room. A good idea is to add a buffer task at the end of a “difficult” phase (for example, limited or no experience using a new technology) by manually extending its’ summary end date for that phase by 20% from its’ original duration. To be more clear, if the original phase duration is 100 days, manually extend it to 120 days.

If you are fortunate and find out you didn’t need this entire buffer for a “difficult” phase, you can always reduce the buffers’ duration time to get an accurate project completion date. If you find out you defined a buffer task at the end of a “difficult” phase and didn’t need it at all, delete or inactivate it (inactivation removes values from your rolled up schedule). In this situation, I would recommend inactivating the task rather than deleting it, as you could later reactivate the buffer task if needed for some emergency reason.


Managing Risks Wisely

Most IT organizations talk a lot about their risk and issue management policies/processes which gives’ one an impression they spend about the same amount of time in each area. In reality, most spend most of their time on project issues. If companies spent more time on risk management (remember, the movers of tomorrow are taking risks today), they would end up spending less time on issues/change management which would ultimately mean they could go under budget and/or schedule for most of their projects. They might cancel some projects before they start because of the high risks involved. Since this usually is not the case, contingency funds totaling 20% of the total budget should be setup for each project.

A risk is really an unknown event, but there are two types of risks. Known/unknowns are risks that are identified at the beginning of the project, and unknown/unknowns are risks that are identified during the execution of the project. A “contingency fund” of 10% of the budget should be setup for known/unknowns, and a “management reserve” of 10% of the budget should be setup for unknown/unknowns. Some of the monies from the “management reserve” could be used for minor changes to the project and other miscellaneous expenses. These two types of contingency funds or “safety margins” should eliminate padding task estimates (the worst habit to get into) and similar games. Instead, this approach will help to produce an honest project plan giving you more creditability and acceptance with stakeholders.



Running a project is akin to reading a book. You have a beginning (for example, a project charter) and an ending (for example, a close-out). The book consists of many chapters which gives you numerous “highs” and “lows” in running your project. If you follow the above tips, you will definitely have more “highs” in your project, which will improve your project’s performance and creditability. Furthermore, this will increase your chances of having a successful project that comes in on time and under budget!

If you find out over time and through lessons learned that the 20% startup solution number is not accurate enough for some or all of the mentioned areas in your organization, then update the percentage number (for example, 15.5% or 25%). Lastly, continue to monitor the accuracy of all the percentages on an ongoing basis to see what works best for your organization.

This is an update of PMI’s PM Network article from December 2015


Share This Post
Avatar photo
Written by Ronald Smith
Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.
  1. Ron,
    Your three 20% rules are a great start for novice schedulers and for experienced project managers that are new to the type of their next project.
    For everyone else, there is historic data available to make these percentages more accurate, or, better yet, to use as input for applying Monte Carlo simulation to their schedule to gain a real sense of how big your buffers should be.

    Thanks Ron, I am fan of your contributions!


  2. Ron,

    Perfect timing! I am working with some PMs today and mentioned a task I have used called “schedule reserve” — I discourage strongly task padding, so if they feel they must do this for difficult phases, then keep your tasks “honest” and use the buffer task.

Leave a Reply