So far in this series of blogs we have taken the definition of the project goal for granted and looked instead at the start up of a project; understanding where the project is starting from and how to gauge progress toward the identified goal. You may have noted how each of the steps we have looked at so far has a significant human and communication element and as we move on to the Plan it may be no surprise that this continues.
The project plan is often seen as a highly technical exercise of identifying EVERYTHING about the project and allocating it a time and someone to do it. This is a bit of an arrogant view particularly if the project has multiple contributing groups with their own critical expertise and knowledge. Choosing the level of detail in which you plan a project is critical – over plan and not only are you doomed to long hours of correcting adjusting and updating the plan, but you risk loosing any enthusiasm of your teams by coming into the drawing office and asking ” the pencils were supposed to be sharpened by 8:30 – have they been done” (OK that shows my age but I cannot think of a digital equivalent). Equally if the plan omits major elements you could find the whole thing running dramatically over budget and time. So what is the top level plan for? I would suggest it is to:-
- Identify major deliverables/desirable outcomes
- Identify Major Risks/Critical Items(within each work block)
- Allow effective co-ordination and communication between different groups (particularly what will be passed over and when)
- Allow a timescale to be defined for delivery and tracking.
- Allow a budget to be generated for approval and measurement.
The last one is interesting and is the major victim if the planning is in the inappropriate degree of detail. From a motivational point of view getting the degree of detail correct is key – too much and contributing groups feel they are being over managed and too little and they feel that management is not taking the project seriously. People’s commitment to a project is critical after all they are doing the work.
A good method for getting the level of detail is to focus on the above items in order with the groups involved. Start by planing the risky activities and critical items and allow the routine to be other things to drop into “other activities” simply as a to-do list with a resource allocation which has got to be completed by a certain time. Then consider the co-ordination activities within groups such as work handover etc. This method expects Group Leaders to fit in the to do list items when it seems most appropriate – so if the critical or risk activity is delayed for some reason the team can get on with the to-do list, equally if there is the opportunity to take advantage of an unexpected occurrence (eg. early availability of test equipment etc) the team can plough on with the risk/critical activities and push the to-do list back a little. The over-riding aim of the plan is to hit the group co-ordination deadlines since in my experience it is these “hand-offs” that cause the most delays and disputes in a project.
By using the above techniques you are implementing one element of what is called Agile Project planning. This type of approach helps to ensure commitment from the groups involved and also results in a less “top heavy” plan, by just planning the critical items and leaving less critical issues to be organised within the groups. Many project planning systems including MS Project have methods of dealing with this sort of approach by allowing sub-projects (controlled by the groups) to be defined within an overall project.
So talk to your teams and try this type of slimmed down Agile planning you may find it useful and we will talk about some of the other elements of Agile in later blogs.