How to Write a Project Plan 1/5 - Long or Short?

Having at least checked the viability of the timeframes you have been asked to deliver to by creating a plan (Milestones) you are now ready to start write a project plan which in the business is also known as detailed planning. This is where the fun really starts! The first thing you need to consider is how detailed a plan you want or need to write. Many rookie Project Managers make the mistake of going into incredible detail with no thought for how this will be maintained during the project lifecycle. It's almost as if they think that if they spend an inordinate amount of time creating an incredibly complicated plan, that somehow it will miraculously be followed and be delivered. If only that were true! The reality is that having a project plan will not by itself achieve anything. Yes you as the Project Manager will be able to monitor progress and see which workstream is slacking but in order to get the project delivered you will still be required to run around chasing people, troubleshooting the inforseen and basically getting things done. So when considering whether to write a long or short plan the things to consider and include are:

Milestones and Tasks

Work Breakdown Structure (WBS)

Length each task will take

Dependencies between the Tasks Resource Type and Quantity Required

Please note these will be covered in more depth in additional sections which will be coming soon!

How Detailed a Plan?

Remember that a project plan isn't a "to do" list. I really can't emphasise that enough. The amount of detail included in your plan should merely be sufficient to enable you to know when work has to be done, allocate that work effectively and monitor progress. Obviously teams can have infinite amount of tasks they need to perform in order to get work done. Everything from setting up environments to checking in code into version manager. Do you really need to know all of this? Probably not. It all depends on how good your team resources are and how much confidence you have in their ability. Personally I keep my plans short (under 400 lines) and trust my teams. The workstreams I have a bad feeling about, I keep a closer eye on them. This means at a higher level, not by micromanaging resources. Project Manager's who call their team leads numerous times a day just so they can tick off the tasks in their too detailed plan, quickly discover no-one wants to work on their projects! And once you have that reputation it is very hard to disprove it. Plus remember that detailed plans have to be maintained. Do you really have enough time to spend 1-2 hours a day maintaining a plan? If you do then either you're managing a very small project, work

insane hours or are in control of a project which is soon going to hit the buffers because you didn't spend enough time on the really important things. Further, a detailed plan whilst looking very impressive at the outset often causes Project Manager's to lose sight of the big picture ie the overall objective and timelines. After all if a few tasks slip is it really a big deal in the grand scale of the project? For example on a recent large project I managed, the Software Development team delivered their High Level Design 2 weeks late. I wasn't concerned even though development was already underway. The reason being that I knew that the slippage had arisen purely because of a shortage of resources to document the design, not because there were disagreements over the solution proposed.

How to Write a Project Plan 1/5 Long or Short? - Tip

You may well be faced with a large project which merits a long complicated plan. However be aware that you don't need to have just one massive master plan. It is far more efficient to have a number of smaller plans, perhaps by project phase. Being able to write a project plan is an absolutely vital skill for any project manager to have and whilst it is by no means the only skill required, it is the one which most people associated with project management. Now whilst some people will still do plans in Microsoft Excel, the usual tools used by project managers is Microsoft Project which is what we are using here in the examples shown.

Project Plan Milestones and Tasks

Looking at the example plan above you will see the Milestones and Tasks highlighted. Basically a project plan is a list of tasks each of which a project manager can track and report on. However this

will quickly drive you mad if your project is anythng other than simple. Therefore most project managers will break the project into a series of phases, the completion of which is marked as a milestone. Think of these as similar to reaching the completing the key milestones in life such as 18, 21 and 40 years of age. As you will see these phases of work can overlap or they may be purely sequential. It really depends on what development approach you are utilising on the project. HOwever the aim of milestones in a pure project management sense is to have checkpoints on the plan which enable clear progress of the project to be measured. This is paricularly the case if you assign a tangible deliverable to the completion of each milestone ie the end of the Requirements phase occurs when all Requirements are documented and approved. Now you can document milestone's frequently like every month, or specifically at the end of phases. I personally prefer putting milestones at the end of phases as it reduces the project reporting overhead and gives you more time to rectify things if dates are slipping. However new project managers in particular, like putting them in more frequently so that they can get fast help should the project start to unravel.

How to Write a Project Plan 2/5 Milestones & Tasks- Tip

Milestone and Tasks are the at the core of every project plan. Learning how to document these is the most important technical skill a project manager can have in the planning area. The good news is that it's not a difficult skill to learn. However knowing how to plan is! It is now time to break the project plan into even more detail by using the Work Breakdown Structure (WBS). If you don't know what this is you can find more information at what is a work breakdown structure? Basically the WBS enables big and complex project to be broken down into more mangeable phases allowing Project Managers and Stakeholders to make sense of it all. After all if you have a project with potentially thousands of tasks, it can be difficult to understand what needs to be done when. If you have a look at the example below it will give you a better understanding of Phases:

As you will see there are a number of Phases listed such as Requirements Phase. Within this you will see a number of tasks and deliverables listed. Now all these tasks are related to different requirements which need to be gathered and documented. By grouping them with a number of other related tasks it makes it easy to quantify this activity as well as to see when this phase will be complete and all Requirements will be documented. Now because of the way the project is being delivered you will see most of the Phases are around related work ie Software Development or Testing. However this isn't the only way Phases can be detailed. Another way of grouping tasks into Phases is by deliverable. So say a deliverable is to have all the Interactive deliverables completed. This may encompass requirements gathering, design, development and test. Now all these may seem unrelated tasks but put together they all add up to completing a specific project deliverable.

How Many Phases?

It may seem like a great idea to have loads of Phases. After all if you do so then it surely becomes easier to check on deliverables and that deadlines are being met? however in practice projects never run that smoothly no matter how well planned. Therefore it can make sense to reduce the number of phases in order to give you some flexibility as well ensuring you don't have to repeatedly explain to Project Sponsor's why the project appears to be missing all its deadlines! Now Work Breakdown Structure's can get extremely complicated because after all it was developed by the US Military for use in huge defence projects. As such I'm not going to go into further detail on this because it isn't relevant for IT Projects. Certainly in 13 years experience I've never had to do so.

How to Write a Project Plan 3/5 Work Breakdown Structure (WBS)? - Tip
Get your workstream leads into a meeting and discuss with them the best way to get the project delivered. Is it by grouping all activity by workstream or by deliverable? Always ask because each project is different either in terms of scope, resources, timeframes or budget and all these can have an impact on how to detail the Phases required to deliver the project. Further it is worth remembering that many ITQA functions like to hold End Stage Assessments (ESA) at the end of each Phase, therefore unless you want a great deal of additional overhead work prepping for these, be careful how many phases of work you document in your plan. Dependencies or Successors are a key element when writing a Project Plan. They basically inform what tasks need to be done before another one can start. As such they are vital in determining the order tasks need to be done. Usually when a plan is written, it is done so in date order by workstream. The problem with this is that often certain tasks need to be completed by one workstream before another workstream can start their task. An example of this is a development team needing to complete a code build before testing on it can start by the test team. Documenting these in a project plan is relatively easy. Using Microsoft Project you simply need to look at the task which must be completed before another can start and then put the line number of that task in the Successors or Dependencies column. This is demonstrated below in the example shown.

Once you have done this, the software should automatically align up dates which should quickly demonstrate whether your plan is feasible. Further it will also highlight the "must have" things which are required. So for example the Creative Design Team say they need the Marketing Brief from the business before the website designs can be completed and signed off. This then means you have to chase up the relevant Marketing Leads to ensure they prioritise this work to meet the timeframes. It is important to give teams this kind of notice because they may not have been aware of the urgency in getting their deliverables done, and also not realise the impact on other teams if their delivery is delayed. You would be surprised at how much in silos Teams work.

Dependencies Between Projects

Now besides there being dependencies between tasks in the project there are also dependencies between Projects. In fact it is extremely unusual for projects to operate in complete isolation They usually always have some kind of dependency on a deliverable from another projects. Now this could be anything from getting resources and environments from one project to needing another project to complete their development so that your project can start developing on the codebase. These kind of inter project dependencies can be detailed in a plan in a separate section, but also should be documented in your weekly Project Management Report. This way if any inter project dependencies slip, it is easy to highlight these and ensure they are escalated upwards for resolution.

How to Write a Project Plan 4/5 Detailing Dependencies - Tip

You may well be able to make an educated guess what the Dependencies are but always double check these with your workstream leads before baselining your plan just in case you've missed something.

Assuming you have followed the previous 4 parts of this How to Write a Project Plan section, you will now have a good idea of Milestones and Tasks, Dependencies and Work Breakdown Structure. Now it's time to move onto determining what Resource Type and Quantity will be required. This is an important part of any plan because if you can't get hold of the right resources at the time needed, the project will be undeliverable. Therefore not only does the plan highlight to resource managers when your project will need resources, it also illustrates where the resourcing conflicts are. This is absolutely vital to know at the beginning of a project if possible, because it gives you the time to either recruit, start de-scoping functionality or else escalating the matter upwards for resolution and prioritisation. Determining what resources will be required and when can be relatively simple if you have experienced Workstream Leads. Often in fact they will point out resource types you will have completely missed, such as DBA's (Database Administrators) or Environment Resources. That is because, even if you have not delivered a project of this nature before, it is highly likely that from their perspective they have seen it all before. Therefore use them to determine what resources and how many they will require to deliver their tasks, rather than you deciding for them. Once you have an idea of how many resources each workstream will require and for how long it is time to put this into your project plan. As you will see below this is extremely simple to do in Microsoft Project. Simply go to the Resource Names column and type in the names required. This should be in the format of, Name-Comma-Space Name-Comma-Space. As you will see in the example below this does not have to be specific named individuals. Instead you can put in Contract BA 1. Permie BA 1, as shown. This basically means that you are expected to utilise 1 Permanent Business Analyst and 1 Contract Business Analyst. It is important to make this distinction at this stage as the usually the difference between Contract and Permanent resources are huge and will have a big impact on your project budget.

You will also see the following in the example above: Contract BA 2{50%}. This basically means that you will require one Business Analyst only 50% of the time stated. It is important to state this as it will help the resource managers and workstream leads to properly plan their resourcing requirements. Remember these streams will not only be delivering your project, but usually numerous others. And you will find that whilst every Project Manager thinks their project is the most

important, Stream Leads have no choice but to try to resource all of them as best they can, unless a Programme Manager makes priority calls on which projects are the most important. I should mention that in the real world this tends not to happen!

How to Write a Project Plan 5/5 Resource Type & Quantity Required - Tip
Workstream Leads are great for determining what resource types will be needed and how many. However don't assume that you shouldn't push back on these estimates. I find Stream Leads tend to seriously over-estimate how many resources will be required to deliver the work because it makes for an easier life for them. So push back and you'll be surprised at how fast estimates can come down. In one recent instance the Test Team admitted they had given an over-estimate. On reviewing it they reduced it from 5 full-time testers for 20 days, down to 2 full-time testers for just 5 days. That certainly helped the project budget as well as the the timeframes!
01.How to Write a Project Plan 1/5 - Long