When was the last time you actually created a Project Management Plan (PM Plan) and not just a schedule? The Project Management Body Of Knowledge 4th Ed. definition;
Project Management Plan [Output/Input]. A formal, approved document that defines how the project is executed, monitored, and controlled. It may be a summary or detailed and may be composed of one or more subsidiary management plans and other planning documents.
Formal usually means written. Approved, should be at least by two or more otherwise it’s not approved. You just become both author and approver.
I’ve posted one example of a plan I created for a major project. Refer to Fig. 1 Project Management Plan example. This was a major corporate initiative and a large complicated project with 150 people onboard at its peak running across several business units and multiple sites in four states across the United States and a budget of over 20 million dollars. I’ve only shown the Table Of Contents to give you an idea what can go into a PM Plan. If you work for a large company they may have a template or form to use. Many of the large companies I’ve worked for had no formal PM Plan procedures. The Project Manager would put together a schedule and that would become the “Plan.” There would be a business feasibility study (most of the time) but not much in the way of an over arching plan or how it fit into the company’s strategy. From the example you can see that I showed from the top down how this project fit into the companies goals and how it fit into the site goals. Overall this PM Plan example was a 57 page document and DID NOT INCLUDE ONE SCHEDULE OR GANTT CHART! The example described key aspects that would be put into the Work Breakdown Structure and schedules but in itself did not contain a schedule.
Key aspects of this plan were communication and organization. Meetings were held every day. Two days of individual team meetings, then core team, next the main site leadership meeting, and finally wrapped up with a corporate meeting with VPs. So it went week after week. It was imperative that we structured the who, what, and when of each of these meetings. The escalation process followed. If a team couldn’t make the decision it went to the core team, next site leadership then up to the VPs if no decision was forth coming.
Organization was also key. With 150 individual employees and contractors it was imperative that everyone knew who was on what subteam and who the contacts were for the many offsite resources. One lesson learned during the project is to make sure you have the NAMES of all individuals that are assigned to your project. In many cases the functional manager assured us we would have support so in the organization chart I added the functional group name, e.g. R&D Engineer or Quality Engineer. When it came time to interface with these individuals it took over one week to determine WHO was assigned and accountable.
Peruse this Table Of Contents and see if there are areas you could/should capture in writing. Are there areas that standout because they were not written down before, then they changed during execution resulting in major negative affects on your project? If you only write down your current understanding of these items and share them with management or other team members you’re bound to generate discussion and feedback which should result in a better plan. Who are you going to talk to for expert advice? Are there outside influences?
Remember not to get bogged down in style or formatting. It’s more important that you think about each of the items in the Table of Contents and even if there is nothing appropriate write “Not Applicable” it will show that at least you gave it consideration.
While this may seem a bit much for smaller projects my question would be “How much are you willing to do to improve your probability of success?”