By Dominic Moss:
Over the past 20 years I have met numerous individuals who aspire to create the perfect project plan. Whilst their dedication to the cause is unquestionable their expectations are probably best described as unrealistic and that will ultimately lead to disappointment.
Perfection and fit for purpose are two subtly different things. I am not advocating carelessness or low standards but a more realistic and workable approach to project planning.
Computer based tools provide us with the means to craft sophisticated and valuable project schedules, however using a tool does not automatically ensure a perfect project plan. Back in the mid 1990’s I was issued with a portable computer that ran a project scheduling software package. This was back in the day when few people in their roles had access to a computer let alone one that could be carried with you. We would visit potential customers and proceed to produce a project plan using the computer, the output was invariably regarded as being beyond question as it was computer generated – in this day and age we are more aware of computers and appreciate that their outputs are only ever as good as our inputs.
A project schedule is an indicative guide rather than a definitive timetable. Producing a precise and 100% accurate project schedule is nigh on impossible as not everything always goes to plan and we cannot always anticipate every possible eventuality that might arise in the prosecution of a project.
However you should strive to build a realistic and workable project schedule to act as your reference point for you to manage and control your project and the following suggestions point as to how you can use Microsoft Project to provide this information.
1. Use “Project Information” to specify the Start Date for your project, for your own sanity and peace of mind stick with the default option “Schedule from Project Start Date” so that all tasks begin as “soon as possible”.
2. Use Auto Scheduled Task Mode not Manually Scheduled Task Mode.
3. Employ a consistent “Task Type” for all tasks in the schedule. The default is Fixed Units not Effort Driven. Fixed Units being your available resources which is the most common restriction facing most organisations.
4. Break your project down in to stages or phases, these can be represented by Summary Tasks which provide a high level strategic view of the project. Repeatedly ask the question “what do we need to do to do this?” This will dissemble your project down in to its constituent tasks.
5. Engage your team in the planning process, they may alert you to risks you are oblivious to or solutions you would never have thought of. Involving the team also allows them to identify dependencies and how team members are dependent upon each other. It can also foster a sense of engagement, common purpose and a sense of valued recognition.
6. Mark the end of each stage or phase with a Milestone.
7. Ideally Outline Level 1 tasks or “Top Level Tasks” should be purely Summary Tasks, if you have tasks or Milestones at this highest level of detail they can sometimes corrupt the calculation of the critical path.
8. Allow Summary Tasks to display discrete sections of the schedule, avoid using “Blank Rows” to differentiate sections of your schedule.
9. If you want to show the overall duration of your project use the “Project Summary Task” this will leave Outline Level 1 tasks as representing the stages or phases of the project schedule.
10. Don’t link Summary Tasks to each other or to or from any other task in the schedule, Summary Tasks should reflect the schedule not affect the schedule.
11. Use Milestones to “Close” a stage or phase of your project, tasks in the stage or phase should be predecessors to the stage/phase milestone, either directly or indirectly.
12. Avoid linking tasks just because you can, only link tasks if there is a logical valid reason to do so.
13. Try to avoid “cross summary task” links, regard each stage or phase of your project as a self-contained entity – ideally each stage or phase of your project will have a single commencing task and a single concluding milestone with the commencing task typically being either the first task in the schedule or being preceded by a milestone in the previous stage or phase of the schedule.
14. Ideally every task in your schedule with two exceptions should have at least one predecessor and one successor, the exceptions being the first and last tasks in the schedule.
15. Try to break the schedule down so that individual tasks in the main have a duration of between 1 day and 1 week, if you have numerous tasks of less than a day you may be trying to Micro-Manage things, if you have lots of tasks with lengthy durations you may not have sufficient detail in the schedule to accurately measure and control progress. This level of detail will fit well with the natural rhythm of most organisations where a weekly review serves to identify what has been completed, what is in progress and what is imminent.
16. Remember Duration and Work are not the same thing, regard durations as being “delivery periods” in most cases as long as something is completed to the required standard by close of business on the agreed date everyone will be happy.
17. If you schedule by means of duration as in points 15 & 16 above then in essence every task in your schedule will have an “implied” level of contingency allocated to it. In theory people could turn around tasks quicker than they estimate but the estimates provided are realistic and optimal rather than optimistic and maximal.
18. Whatever you do, never show “Contingency” explicitly in your schedule as senior management will inevitably seek to remove it to achieve a more ambitious (read unrealistic) completion date.
19. Try to ensure that you have a mix of critical and non-critical tasks, if every task in the schedule is critical how can you prioritise? Similarly if every task is critical your schedule may be a high risk proposition.
20. Avoid assigning multiple resources to tasks, ideally there should be one resource per task to ensure ownership and accountability. Follow the “Highlander Rule”, there can be only one!
21. Plan your schedule in isolation and as you see fit, avoid compromising the schedule to account for external factors you are aware of as circumstances can change.
22. Don’t compromise your schedule to allow for resource commitments elsewhere, create your schedule in isolation and ensure that it on its own does not provoke significant resource conflicts.
23. Don’t “Dread the Red” – occasional resource overloads are difficult to avoid, however you should ensure no resource is excessively overloaded for extended periods of time. Use your judgement to assess how onerous forecast resource workloads are. We have all probably worked more hours than required on occasion to achieve a deadline but it is not something we would want to be doing all the time.
24. Review the resource workload across concurrent projects and let Microsoft Project identify where there may be potential resource conflicts and then pro-actively manage these on a regular basis throughout the project. Focus upon the immediate outlook, resolving “forecast” problems more than 6 weeks into the future may be a waste of time and things can change.
25. Don’t assign resources to Milestones or Summary tasks.
26. Avoid entering dates as a matter of course, dates should be an output from not an input to Microsoft Project. If you do have to “Constrain” tasks due to non-negotiable factors add a note to such tasks explaining the reason for the constraint as circumstances can change rendering constraints redundant.
27. Baseline the schedule once you are satisfied it is a realistic proposition.
28. Update progress on a regular basis and if required take corrective action to get back on track sooner rather than later – check my soon to be published guide on tactics to recover your schedule.
29. Make use of the “Status Date” feature and for robust updating use the “reschedule uncompleted work to start after” the status date option, in essence this means that anything that has not been done so far can only be done in the future.
30. If your project has a deadline model it using the “Finish No Later Than” constraint date on the last milestone in your schedule. Provided that you have a “closed network” (see point 8 above) as long as you are on target there will be no warnings but as soon as your schedule slips to the point where your deadline is in jeopardy the planning wizard will alert you to the peril and you can then consider your options.
Source: https://www.linkedin.com/pulse/my-30-golden-rules-creating-realistic-project-plan-microsoft-moss
Services from Bizville Project Management are:
Follow us on Social Media: