The Development Plan describes the solution development process used for the project in order to achieve the Project Objectives as defined in the Project Charter. This plan complements the Requirements specifications that details what will be built and provides consistent guidelines and processes to the teams creating the solution.

Here is a list of some things to consider when creating the Development Plan (this is not necessarily the complete list of considerations; your project may have more):

• Intermediate deliverables needed to achieve the Project Objectives. For software, this list includes documents for Requirements, Design, Configuration, Build, Test and Deploy.

• Delivery Strategy (e.g. phased implementations, high-priority/high-risk items first, “depth-first”, “breadth first”, “features, then performance tuning”)
• Design Goals (e.g. create reusable components, use existing components, ease of maintenance vs. speed of delivery, security, etc)
• Development and Build Environment – this has the potential to be a high-work, high-risk area. Include source code control, software and tools needed, test data, connectivity to other environments, security, tool and run-time licensing etc
• Naming Conventions
• The Build Process (how will versions be created for system, user and quality testing)
• List Components and who will build them –  Also state if you have to buy components and how you will acquire them.
• Development tools – also identify licensing needed.
• Team Training and Support – identify training for the development team and what support they will need

You need to break down the activities listed above into pieces of work small enough to assign to one or more resources and estimate the effort and duration of the activity. The level in which you break this down is usually at the Project Manager’s discretion and will vary by project.

In addition to assigning resources and effort, you should describe how the activity will be accomplished. For example, if your major activity was ” Create System Design Document”, you could break this down into lower level activities such as “Data Design”, “Interface Design”, “Transaction Process Design”, etc. For “Interface Design” you could refer to company standards (if they exist), what languages and technologies will be used and what reviews and approvals are needed.

As we go thru each part of the Project Plan in subsequent posts, you will be collecting a list of activities that will ultimately be used to build the Project Schedule.

There are many Project Managers and Stakeholders who refer to the Project Schedule (usually built in Microsoft Project or equivalent) as “The Project Plan”. This is not true. The schedule shows “who, what and when” but does not address “how”. A plan must address “how” or it is not a plan. I will address the Project Schedule in a separate series of posts.

The prerequisite to building a schedule is to identify all of the activities, and in order to do that you need a Project Plan. Activities will also be drawn from the Project Management Plan (refer to prior series of posts for more on this). This overview will list the main topics of the Project Plan and subsequent posts will do a deeper dive into each topic.

Here are the elements of the Project Plan:

• The Development Plan
• The Operations Plan
• The Organizational Change Management Plan
• The Test Plan
• The Migration Plan
• The Pilot Plan
• The Deployment Plan
• The Support Plan (post-implementation)
• The Support Plan (during the project and stabilization)

You will not necessarily need all of these plans for a given project. It is good practice to review each one for every project to see if they apply. Some of these topics will require multiple posts to give them the depth they deserve.