(A guide for the hasty, the inexpert, and even Dilbert's© Boss)*
One of my greatest bugbears is the lack of planning that goes into projects, particularly in the information technology sphere. To coin a phrase uttered by Bill Britt, a salesman who built a multi million pound direct selling empire out of nothing;
"To fail to plan is to plan to fail"
Indeed, I have witnessed on many accounts what planning failure can lead to. So to the uninformed below you will find a simple diagram outlining the progress of a typical planning stage.
Ok does this seem a bit simplistic? Correct because it is. However, the evidence is that this is beyond the gen of many projects that I have had the misfortune to see. What happens? The project is generated from some bright idea, a project team assembled and then they get on with producing something. Lo and behold along comes a bean counter and says OK what is the business benefit of doing all this work and suddenly the project team is gathering their P45's and heading for the Job Centre. The above is the very simplest that the project planning cycle can be distilled to and to see the much more frightening version you will have to take a look at the detailed planning cycle that I show on another page <to be drawn later :- ed>.
Suffice to say that if you follow the process detailed here at last you will have a defendable plan of how you are to achieve your project goals, for defending why you are doing it in the first place, see the pages on a PID. (Project Initiation Document).
The first step is to identify the components that make up the shape of the deliverable you are working on. <more information> then identify the tasks needed to produce each component of that deliverable. This forms the task list for the project
I had many discussions with Mike Bickerstaff over the correct order for doing this, Mike was the co-ordinator for the development of Prince for the CCTA in the UK. This is used as a defacto standard for many organisations. The prince method suggested that the dependencies should be planned after the resources however with most packages on the market today, it is easier to enter the dependencies on the fly as it were, since in most planning packages it is easy to enter dependencies at the same time as the activity itself. Thus I tend to put this in as a parallel activity, i.e. enter the activity, with "logic chaining" on and enter the resources. Again most packages allow a central cost base for the resource, with adjustable override in the activity itself for exceptional work. From this you will be able to get a cash spend profile over the duration of the project and what the Americans fondly call a "bottom Line". Mike's point was that if the project is going to be too expensive then there is little point in working out the project dependencies, my point is it that this view is irrelevant since most planning packages can chain together activities on the fly, so not putting in activities in most projects, will actually create a great deal of extra work later to backfill the logic.
Each task should be looked at and an estimate in person days made as to how much effort is needed by each type of resource to complete it. This can be adjusted for various earned value techniques at a later stage. This should give you a general picture of what is needed in both cost and people terms. If you are not using a formal planning tool then a spreadsheet such as Quattro or 123 could be used to tot up the total.
If all these are fed into a scheduling tool with the estimates for duration of the activities and cost of the resource, then a reasonable estimate can be ascertained for the project as a whole. For tools see the resources page where there are some links to some good vendors. (Own reviews to be complied later...). It is possible to manually schedule a plan using simple critical path method, but I would tend to advise against it. When I used to teach people use of Primavera Project Planner, one exercise I conducted was to get my students to manually schedule a simple 6 activity diagram, apply resources and manually level. Most of my students did not get the initial schedule correct, let alone a correct levelled plan.
Suffice to say the information is only as good as that entered, although the tool does have an impact. I would suggest that for brevities sake you look for a tool that can handle different earned value calculations, resource profile on activity (ie a surveyor might turn up on the first 5th and final day of an activity, you would not want to cost them across the whole duration). Finally I pay a great deal of attention to reports and only PMW, Project Scheduler, Artemis and Suretrak/P3 can generate reporting that I find satisfactory. (See note)
By this I am referring to planning conflicts, not the other type that seem to absorb 90% of project managers time, Most decent scheduling tools can level resources to extend project duration according to rules set down in the scheduling set up. (NB I strongly advise against this, amongst many other things, when using microsoft project; it has highly unpredictable results). Therefore where it appears that on the shortest path through a project there are not enough resources to conduct it, the levelling process can "level" the resources to a point where they are within the limits of what they can perform. (See my note below)
This page has been designed to give you a glimpse of an insight into the most superficial planning, the links below lead to more pages being developed (my apologies now for the duff links) which give a greater insight into the planning process. If you read nothing else, look at the Batty Method, a planning methodology (oh how I hate that word, associated with all that is pretentious and hidden behind big fees and inexperienced "consultants"). It is a technique refined from one taught to me by some very great independent consultants with many years of experience behind them. I hope you find it helpful.
Thanks to the staff of the Hotel du Rhone, Geneva where I have written many of these pages. They put up with me while I was dying with flu, keeping me fed with "pression" and entertained with the piano. I will persuade Christian to make long Island Ice Teas yet....
Some years ago I had cause to be responsible for the roll out of around 300 computers for a large corporate headquarters. The problem was not how to logically link the activities together for planning purposes, but rather to establish what order the equipment was to be delivered in and when it was due. Spc on the site was limited so I could only hold a few days equipment supply for roll out. The rest had to be shipped and have the "standard" desktop installed elsewhere (That's another story) a complex logistical and planning exercise. The result I came up with was to import a list of users to "suretrak" with an id to say whether they were a vanilla install (simple one) or a bespoke one with complex supplementary software. I assigned a department and location code to each user and then resource scheduled the plan based firstly on whether it was a complex/ vanilla install and then against the department. The levelling was based on the size of my install team pool. I then sent the resulting delivery schedule to the suppliers. Suffice to say that barring an ordering snafu, the project was delivered on schedule and under budget, without a single logic link in the plan, with each contiguous user group being rolled out at the same time. That is where a good resource scheduling algorithm can win out.
These pages are copyright of Esper Consulting Ltd and Rebecca Baty. They are free to be reproduced so long as credit is made to the author and that they are not reproduced in any form for profit. I and others who have collaberated to produce these seek to improve the quality and skill in Project Management.
* Dilbert is a registered trade mark of United Media Corp and Scott Adams, if you have not seen it you don't know what you have missed....<Dilbert Icon Here WICBB>