Little River Software
Home -> Articles -> Project Management
Costing & Resourcing Planning

Risk Analysis

Project Planning

Perhaps this chapter should have gone right at the end, but its useful to have a framework when discussing some other topics.

Project Management tools allow the Project Manager to make useful diagrams of the project, to report on project performance, and to help manage the project. Unfortunately the software tools, now available for managing projects, are often better than the Project Manager, at which point the project plan becomes a goal in its self in place of a tool for project management.

Prepare a draft plan early on, so that it can be used in agreeing the budget. Make very sure that the draft plan does not suddenly become the real plan without a careful review to make sure it will really work. This is a common mistake, and can leave the project team attempting to work to an impossible plan. One way to avoid this is to create a draft plan that has no dates on it (just elapsed times). Also make sure the words 'draft' are all over the plan.

Steps for preparing a project plan:

  • List the tasks, and time taken.
  • List the people available, and when they are available to the project.
  • Note task dependencies.
  • Note any external dependencies (e.g. the server will arrive on Monday).
  • Assign task priorities.
  • Group tasks into useful blocks.
  • Sort the tasks using their dependencies and priorities.
  • Resolve people working on more than one thing at a time.
  • Make a 'calendar for the project. In other words put dates to the tasks.
  • Now work out how to make the deadline.
  • Agree milestones so that the progress can be assessed throughout the project.

Tips for preparing a project plan:

  • In all but the smallest project, get a reasonable piece of project management software.
  • Preparing the plan must be done by someone qualified. They should preferably have sufficient experience in actually doing the project tasks, to accurately assess the time and resources required. Alternatively they should be the type of person who is prepared to admit when they do not know, and to know the right person to ask. This sounds really obvious, but a suprising number of project plans do not reflect this ability.
  • The completed plan cannot be produced effectively until after:
    • The Requirements/Scope has been agreed by all parties.
    • The budget has been finalised. This means that the deal has actually been signed.
  • Completely disregard all deadlines during the initial project planning. Get the tasks listed, and ordered, get times assigned, get people assigned to tasks, pad the required time by a factor (use experience based on the entire project environment), now pad the time again. Then see how to meet the deadline.
  • The plan cannot be produced in isolation. Producing a plan requires a great deal of communication.
  • The plan needs to identify all the tasks involved but retain a sufficiently high level view that it remains usable. Personal preference will dictate exactly what constitutes 'high level'. If there are 1000 tasks on the plan, some re-thinking is clearly required. Complex task sets can often be split off as sub projects. For example the production of a sub-module in the system (or a sub-assembly for our moon transport), if sufficiently complex, could be run as a separate project.
  • Eliminate all working time between Christmas and New Year(ce) as nothing is going to get done then anyway. Look for other slow times as well (public holidays, local festive seasons, etc), and cut them out too. These days can be left as fully productive time in the plan, but experience shows that even though everyone will supposedly be at the office, sudden leave applications will get accepted, no-one will feel much like working, and in short nothing will get done.
  • Do not plan on any person working more than 7 hours per day, for a 5 day week. If you later need to ask someone to put in more time on the project, the time is available. If tasks got allocated to that extra time right from the beginning then you are stuck. Oh and most countries have laws governing how much time the employer can demand. Plenty of employees will put in a bit extra, but you can neither demand nor expect it.
  • Watch out for allocating whole days to people who still have other responsibilities. For example the users of a new system are probably still doing their jobs on the old system. Also watch for weekly/monthly/annual fluctuations in the general workload. For example:
    • Accounting staff have little spare time when the annual budgets are nearing completion.
    • Credit controllers may be more rushed at month end.
    • Debtors staff are busy when they raise monthly charges, or send out statements.
    • Candle makers are busy at Christmas and Diwali.
    • Wage clerks are busier near the end of the week.
    • Astronauts are busy at full moon (Just kidding), but medical staff can be.
  • Expect that someone, usually the Management either from the client or the supplier side, will attempt to cut down the time you have carefully calculated. Despite the fact that your numbers should be more realistic, this almost always happens. If you are burdened with a scenario like this, you are about to loose some of the padding you added earlier. Hopefully you added enough to tolerate this loss.

The entire point of a project plan is a working document that assists in making sure the project runs smoothly. It is a working document, it gets updated as tasks are completed. It gets amended to reflect changes in the environment.

Costing & Resourcing Planning

Risk Analysis