Project Office

A Project Plan provides a roadmap for detailing HOW your project will reach its desired goals.  It should be written in the Project Planning phase, once the project has been initiated and received preliminary approval and funding to be scoped out further. It normally follows the Business Case , and should primarily focus on HOW the project will proceed rather than WHY.

Why is the Project Plan so important?

The Project Plan is one of the most important and useful documents in your toolkit, and should be referred to and updated throughout the project lifecycle. Its initial purpose is to kick-start the project by convincing the decision makers (usually the people who control the funds e.g. the Project Board or Steering Committee) that the project is viable and and will meet their needs and timeframes / budgets / expectations. If the Project Plan is poorly written or contains insufficient detail, the project may not even get past this first decision gate and may never actually get off the ground. Many viable projects have floundered at this stage due to poor planning and communication. On the flip side, if you can deliver a great Project Plan, it establishes your credibility as a Project Manager, starts the project on a sound footing, and provides the team with a mandate for action and a clear direction to follow.

Don't confuse a Project Plan with a Project Schedule. A schedule is merely a component of a Project Plan, and usually takes the form of a timeline / GANTT chart depicting tasks vs. timeline. A project schedule is a vital tool and should complement the project plan.  Larger Project Plans contain several schedules, normally as appendices, that are referred to throughout the document. Such schedules would include an overall timeline, a test schedule, an implementation schedule, the critical path analysis, a resource allocation schedule….etc

Part 1 – Writing a good Project Plan / What should be in a Project Plan?

The Project Plan serves as a roadmap for the entire project team providing guidance on the priority of activities, the scope of work, the methodologies and governance to be used, who the stakeholders are, the broad strategy to take, how costs and people will be managed, the quality standards in the project, how the project will communicate with stakeholders, how performance and benefits will be measured…etc

The main areas you need to cover in your plan include:

• Project Background
• Objectives
• Scope
• Constraints
• Assumptions
• Dependencies & Impacts
• Issues & Risks
• Methodologies & Strategy
• Controls – Scope, Time, Cost, Quality, Resources
• Communications
• Schedule of delivery
• Performance Measurement
• Benefits Realisation

As you can see there are many elements to a Project Plan, and some of the larger plans can stretch well over a hundred pages. This makes structuring your document all the more important. A consistent format with a logical order and clear headings will allow your readers to quickly navigate through the document and get to the details that are important to them. Ideally use a standard template to make this task easier.

Try not to omit any of the key areas outlined above, as doing so may come back to bite you, proving costly further down the line should a misunderstanding arise. For example, if you fail to adequately document what is in and out of scope of the project, you may get in to a dispute about who is delivering what. Or you may find that the project delivers a product which you believe is satisfactory, but fails to meet the expectations of the customer as they have different quality criteria to you. These are not situations which you want to find yourself in, and they can be easily avoided by writing a thorough Project Plan. The more relevant information and detail you can include in your plan at this stage, the better…..but there is an emphasis on relevant! Avoid the temptation to bulk out your document with unnecessary paragraphs and try not to repeat yourself. If you do need to re-emphasise a point, simply cross-reference the original section in your document (using headings), rather than repeating the whole section. Your readers will thank you for this, and it will also make editing the document far easier for you. Gauging the appropriate level of detail is difficult and comes with experience. Once you have written a few project plans you will know how to tailor each one according to the size of the project and expectations of your audience.

Tailor to your audience

The Project Plan is often one of the first points of reference for stakeholders, whether they are new staff, executives, customers, users, suppliers or interested third parties. So when writing your plan bear in mind that it needs to be suitable for such a wide audience and could be read by someone with no prior knowledge of the project. Always ensure that you introduce the context of the project and provide some background and history behind what you are doing. Include a glossary or terms of reference to explain any abbreviations and acronyms. When referring to other documents it may be useful to include details in the appendices for the benefit of people who have not read these documents before.

Part 2 - Selling the Project Plan

Writing your project plan is only the first part of the job. The equally important next step is to successfully sell the project to stakeholders – without this all of your efforts will be wasted. Whilst some Project Managers are in the fortunate position of already having the ‘go-ahead', most projects have to compete for funding and prioritisation with a realm of other business priorities, whether within a program / portfolio of work, or across different business functions. This makes the job of selling the project plan that much harder. Normally the business case is the main selling tool of the project, as it states WHY a project is being undertaken, listing out all of the potential benefits and costs of completing the work. However, the Project Plan also forms a key component of your strategy, as you have to be able to demonstrate credibility and feasibility. The decision makers need to be convinced that you're up to the job, that you know exactly how you want to deliver the project, that the project is feasible and worth doing, and that it will be delivered in accordance with their expectations. So be realistic – don't make bold claims or have overly optimistic expectations that you can't substantiate. These will come back to bite you in the future! It is far better to play it safe and include fairly conservative and realistic statements that you are confident can be delivered. Don't create a noose for your own neck!

Working with your stakeholders

Work with the decision makers and involve them early in the process if you can. It is far easier to take these people on the journey with you, than to sell it to them ‘cold' at the end. Consult with them about their requirements and expectations, talk through your thoughts and review early drafts with them. Make sure that you have addressed any concerns they raise before you get to the final review, so by that stage they are entirely comfortable with what's in the document and most importantly there are no surprises. Working one-on-one with all of the key stakeholders may be time consuming, but its well worth the effort, especially if you haven't yet built a relationship with these people. This process will allow them to see how you work, and will help you build important allies which will be crucial as the project progresses. Getting people on-side early will make life so much easier when things get tougher later on. Taking this approach should mean that the final version of the Project Plan sails through the Planning stage and is fully endorsed to proceed to the next stage of the project.

Baseline it!

Once the Project plan gets approval, make sure you baseline the document and ensure there is a clear and transparent process in place for managing further changes. Note - you should have documented this in the ‘Project Controls' section of your plan! It is vital to do this, as the plan must maintain its integrity as an endorsed document so that it can be referred to as a ‘baseline' for the rest of the project. Every time a change is made to the plan, it is updated to a new version and re-baselined; that then becomes the latest version to refer to.

Once your plan is signed off and baselined, you are ready to move on to the next stage of the project – the Execution Phase.

Article Source: http://www.articlesbase.com/project-management-articles/how-to-write-a-project-plan-4767907.html

For further information on Project Planning, or any  other stage in the Project Lifecycle, refer to http://www.project-documents.com