Brian Cryer's
Project Planning Principles
The following are principles for project planning which I have learnt through my own experience.
These are principles and not hard and fast rules. For each principle there will be exceptions, but these are rare and break a principle at your peril!
- If you don't plan then you plan to fail.
- A plan is only as good as the estimates on which it is based.
- Change in requirements necessitates a change in estimate.
- Parallel tasks require parallel resources (tasks in series only need a single resource).
- Plans can slip, but you never make up time against the plan.
- A change in the start date changes the end date.
- The myth of the man-day/month.
- Be wary of bringing in extra staff for a single task unless that task can be treated as a separate sub-plan.
- A plan with unfinished tasks in the past, is a plan with an unachievable end date in the future.
- Monitor a plan or expect failure.
- Large tasks cannot be monitored.
- Plans can change as they progress.
- Don't be afraid to put contingency down as contingency.
- Nothing is for free - other work always has a time impact.
- One person's estimates cannot be transferred to another.
- Projects need start-up time.
- Testing takes time.
- Fixing isn't the same as Testing.
- What about holidays and sickness?
- Not everyone can plan and manage a project.
I will expand upon these notes as and when time allows.
1. If you don't plan then you plan to fail
If a project needs to be completed by a certain date then it needs to be planned, and part of that planning should involve estimating the work required.
Estimates on their own are only of limited use. In order to identify when a project will complete you need to start from the project start date and add the estimates to the start date to come up with a projected completion date. If you have different people doing different tasks then some of those tasks can run in parallel, but those tasks done by the same person can only be done in series, i.e. one after another.
If you don't work from the start date and apply the estimates in this manner then you don't know the projected end date. All too many projects over run because right at the start the estimates were never used to calculate a projected end date.
Tools such as Microsoft Project can help here. If you only have one person working on a project then a simple spreadsheet can suffice (but do allow for weekends and other non work days.)
2. A plan is only as good as the estimates on which it is based.
Notes to follow.
3. Change in requirements necessitates a change in estimate.
Notes to follow.
4. Parallel tasks require parallel resources (tasks in series only need a single resource)
Notes to follow.
5. Plans can slip, but you never make up time against the plan
It should be expected that some bits of planned work will take longer than expected and that others will take less time than expected. This is normal on any project.
Project slip can come from a variety of sources:
- Tasks simply take longer than estimated for - minor slip.
- Tasks are far more complex than originally thought and take significantly longer than estimated.
- Tasks are identified which were missed from the original project plan.
- Non-availability of staff (for example through illness).
Each of these will arise on projects and will cause the end date to slip.
Equally it is possible to make up time against a plan - either because some estimated work is no longer required (rare) or a piece of work didn't take as long as expected.
Whilst it is easy to hope that the gains will cancel out the slips, the reality is that the slips are almost always greater than the gains. So a simple rule of thumb is that overall you never make up time against a plan, so plans can only slip.
There are things you can do about this. Typical responses are:
- Accept that the end date will slip and live with it. Not an option for many projects.
- Bring in extra staff.
- Require overtime of your staff.
- Build in contingency into the original plan. ← This is the best approach.
6. A change in the start date changes the end date.
Notes to follow.
7. The myth of the man-day/month.
Notes to follow.
8. Be wary of bringing in extra staff for a single task unless that task can be treated as a separate sub-plan.
Notes to follow.
9. A plan with unfinished tasks in the past, is a plan with an unachievable end date in the future.
Notes to follow.
10. Monitor a plan or expect failure.
Notes to follow.
11. Large tasks cannot be monitored.
Notes to follow.
12. Plans can change as they progress.
Notes to follow.
13. Don't be afraid to put contingency down as contingency.
Contingency is time put down on the plan to allow for slippage (where something takes longer than it was planned for) or unforeseen eventualities (typically where something arises which was not foreseen and this has necessitated extra work.)
For a short project, and in particular where the work is well understood, it may be tempting to avoid putting down any contingency. Worse, project managers (or their management) often look at end date, state that the project is too long and start looking for something to cut and typically it is contingency which gets cut first (then testing, then work estimates.)
Sometimes you can get away with little or no contingency. In reality, almost every project experiences some slippage. Contingency is a way of allowing for this before it happens. So avoid the temptation to cut back on contingency. Over time you may be able to better estimate the amount of contingency you need, but be assured that you will need some contingency.
If you learn that management doesn't like seeing contingency on a plan then disguise it as something else. Just be sure to include it.
A rule of thumb is that a project plan with no contingency is a project plan which will over-run.
So how much contingency should there be? That does depend on a number of factors, but I would advocate contingency to be in the 10-20% of your project work estimates. If in reality it turns out that you've allowed too much contingency (which is rare), then you can take pride in knowing that you have been able to bring your project in under budget.
14. Nothing is for free - other work always has a time impact.
It may seem obvious, but everything takes time. When it comes to a project plan anything which is not allowed for in the project plan is extra work and extra work always takes time.
Other, unanticipated work can crop up from any number of sources. The following list is not exhaustive, but may give you an idea:
- Changes to something already done (however trivial those changes might seem).
- New requirements (however trivial those might seem).
- Requests to do anything not covered by the plan - whether for the project or for another project.
- Other obligations not on the plan - such as mentoring, fire-warden and meetings (including appraisals).
A warning sign for this type of thing is when you ask where the work is on the plan and are told to "just fit it in".
Note: Software developers have a tendency to look at a change request or new feature request and if they think its trivial to say its "a 5 minute job". Such "trivial" tasks don't seem to take long, but the reality is that a 5 minute task is rarely 5 minutes. Some are, but these are rare - even for a "trivial" task there is the time to run up the development environment, find where the change needs to be made, make the 5 minute task (oops it actually takes a bit longer), then there is testing and sometimes knock-on effects elsewhere, plus the disruption from what the developer might otherwise have been working on. Even if this "trivial 5 minute" task realistically takes an hour or just half an hour, how many tasks like these often get added to a plan?
All these things add up. Unless you ask people work unpaid overtime then time for extra work doesn't come for free. If you do get people to work unpaid overtime then you risk loosing goodwill and eventually your people.
This is another reason why (i.) every plan needs contingency and (ii.) why you need to monitor a plan.
15. One person's estimates cannot be transferred to another.
Notes to follow.
16. Projects need start-up time.
Notes to follow.
17. Testing takes time
Consider: A product which hasn't been tested is a product which doesn't work.
Whilst it should be encouraged that people (developer's especially) test their work as they go along, formal system testing should always be included in a plan. It is suggested that 5 to 10% of the total project time should be spent on formal system testing.
One thing which inevitable gets squeeze (especially on IT projects) is testing. Typically:
- Some plans omit testing because it is seen as an after thought or something which takes no time.
- If, before it has even started, the plan seems too long then testing is a common target to squeeze and economise on.
- If other things over run then testing is seen as an easy option to squeeze.
If you economise on testing then inevitably your customers will end up doing the testing for you and will not be happy when they discover problems that rightly ought to have been found before the product was released. This tends to antagonise customers, and it is widely recognised that fixing bugs when a product has been released costs more (typically in total man hours) that it would have done had the problem been found earlier.
Note also that system testing is not the same as customer acceptance testing. Customer acceptance testing is typically much shorter than formal system testing. Formal system testing is for you to identify problems before it reaches the customer. Customer acceptance testing is to satisfy that the system meetings its functional requirements, and is often also a payment milestone.
18. Fixing isn't the same as Testing
Notes to follow ...
... and of course if fixing isn't the same as testing then you probably need to allow time for retesting.
19. What about holidays and sickness?
Notes to follow ...
20. Not everyone can plan and manage a project
It is a mistake to assume that anyone can plan and manage a project.
A successful project manager will understand that few plans survive unchanged. The German field marshal Helmuth Karl Bernhard Graf von Molke is attributed as saying that "no plan survives contact with the enemy". So it is with any plan. A successful project manage will appreciate this, will anticipate problems and develop strategies to manage.
About the author: Brian Cryer is a dedicated software developer and webmaster. For his day job he develops websites and desktop applications as well as providing IT services. He moonlights as a technical author and consultant.