Lines in the sand
The earliest plans were probably lines drawn in sand or on the walls of caves. They were pretty simple plans because tasks were simple, resources were few and maybe there was only a handful of people in the “team”.
As the human race has progressed we have undertaken more and more complex activities, the Ancient Egyptians built the pyramids. This required a grand architect some design engineers, teams of masons to cut blocks plus thousands of slaves to move them into place. So although the number of people in the team was very high the number people actually in control and therefore needing an understanding of the plan was still comparatively low.
NASA and PERT
The NASA programmes that put man on the moon required complex plans and PERT analysis was developed as a result but the plans were still hand drawn on paper albeit with draughting aids. These plans were vast and they probably lined the walls of a programme room where team leaders would review and update status and be able see the impact of any delays on the overall programme.
Then we progressed to computer aided planing tools, great for organising small projects but capable of allowing us to plan programmes with ten’s of thousand’s of activities. However with this came a problem, a reduced level of communication because initially, due to licence and training costs, only the planning team had access to the planning tool. The tools could roll up tasks but then the overall planning logic then got obscured and there was further problem, one of version control. In short, we had great tools which were helping us in many ways but they were also making our lives more difficult in others.
The Purpose of Planning
Think about the purpose of a plan:
- It helps us organise the order of work
- It helps us plan the duration of activities and the likelihood of the completion date
- It helps us get the right materials and the right people to work on the right activities at the right time
- It allows us to communicate to the team and to the customer and whoever else has a need to know
Do I look like a Man with a Plan?
I have worked with several organisations that have produced schedules that:
- Ran into thousand’s of lines
- Contained dependencies with complex relationships often resulting in critical paths that made no sense
- Resulted in nobody outside of the scheduling team understanding or believing in them
- Were always in revision, i.e. out of date
- Couldn’t be articulated to the customer correctly for progress reports
- Cost the organisation money in review effort, incorrect tasking and resourcing and in reputation
- Moved control away from the programme manager and the customer
- Produced Level 0 and Level 1 plans that communicated nothing
- Resulted in the programme manager producing his own simple plan, one that was dangerously disconnected from the detail!
So like Dr Frankenstein the scheduling department had created a monster!
These were not immature companies, these were not simple programmes and these were not small customers.
If you can’t get it on one sheet of paper it’s not a plan!
One of the key purposes of the plan is communication. Remember what I have said about Discretionary Contribution in a previous post? If people don’t fully understand how their work fits into the big picture they won’t give 100%, you will be lucky of they give 60% and that’s not the basis on which you estimated activities and planned your resources. The Ancient Egyptians had a solution to this with their labourers but it’s hardly relevant today!
So no matter how complex the detail of a schedule is we must be able to communicate it simply. We must be able to explain to a customer the impact of a change they are imposing and we must be able to explain to a team whose work is late exactly how their work is impacting the overall programme and other teams.
The Work Breakdown Structure must not be too flat, it must have sufficient hierarchy that it allows this “Big Picture” plan to exist and to be consistent with the detail. There are add-on applications that work with many of the most popular planning tools that produce these visual summaries totally consistent with the detailed plan.
8 Points for Effective Planning
- Never forget about communication, make a plan on a page and make it available to all, use it to explain progress, successes and setbacks
- The Project Manager (PM) must never relinquish control to the planning department
- Ensure the WBS reflects the work and it is not too flat, think about it in the way you would do any system design
- Never use complex dependencies as these confuse communication
- Be cautious about resourcing a plan, use the information wisely again making sure that the PM is in control
- Ensure that any schedule risk analysis throws up critical paths that make sense intuitively, if they don’t check the dependencies
- Update the plan with progress carefully and review the effect of any delays
- Use Earned Value Analysis but don’t expect customers or your senior teams to understand the metrics, better to communicate the issues as simply as possible