Writing a Project Initiation Document - Initial Plan 10/13

01.Document Change History, Related Documents and Purpose
02.Project Scope Statement
03.Project Background
04.Project Definition
05.Assumptions, Dependencies and Constraints
06.Business Case
07.Organisation and Governance
08.Communications Plan
09.Quality Plan
10.Initial Project Plan
11.Project Controls
12.Initial Risks and Issues Log
13.Initial RFC's, Open Questions, Training & Appendix
14.Getting A PID Approved

10.0 Project Initial Plan

Many new Project Managers go completely overboard when faced with completing this section. It is almost as if they feel that have to produce something incredibly detailed and complicated to justify their role as they relate Project Management with planning.

In fact the best thing you can do is keep it simple and as vague as possible. After all, unless you've had serious amounts of time to properly scope out the project requirements and gain viable estimates this plan can be nothing more than a finger in the air exercise which gives your Business Stakeholders a feeling of confidence that the project can be delivered within the timeframes they require.

Most Project Managers will complete this plan in either MS Project, Excel or as I've done below, in a Table in Word which gives you an idea of what a Initial Plan should look like.

Basically the phases which I've detailed are the one's you would normally find in any IT Software Development project. As you will see it is done by months, does not include any scope and looks plausible, which is enough to get the PID Approved. Once the Project is initiated you will then have to drill down into the project detail and write a plan which covers the reality of what needs to be done to meet the delivery date.

Project Initial Plan - Tip

When writing an Initial Plan for the PID, work backwards from the proposed date and detail phases accordingly. However whilst doing this, also do some sanity checking to make sure you have a good chance of delivering to that date. I have found that Business Stakeholders often ask projects to be delivered to impossible dates.

If this is the case, make sure you hightlight this before committing to delivering the scope required, as it will save you a great deal of pain later on. Further most Business Stakeholders are often more than willing to be flexible either by changing the launch date or reducing scope, as long as you have a compelling argument for why this needs to happen. And let's be honest, the sooner you start building this kind of relationship with your Business Stakeholder the easier it will be later on when more pressing concerns regarding scope are raised.