Please login or join to subscribe to this thread
It does seem strange on the surface, but when dealing with structured information such as plans, documents, requirements, and processes, there tends to be much more formality at the higher overarching levels than down in the detail levels. It really comes down to how much detail you can and should prescribe, vs. giving people the flexibility to adapt their work to the situation.
There are lots of examples of this in any real world project. EVM may be prescribed at the method to manage cost and schedule. At the project level, there may be formal ways the data is collected and presented. At the working level, it may be up to the groups to break their work out into tasks with an assigned value.
Another good example is whenever expert judgement is required. Consider a project where safety is a major priority. At the top level, there may be a requirement that the project will not include any unsafe features. There may be a lot of formal guidance as to what that means to individual teams. At some point however, subject matter experts may need to use their best experience based judgement to determine whether or not something is safe. They might provide formal approval, but their thought process is all their own.
There is an old saying that translates to "No plan survives first contact with the enemy." As much as we try to plan and work out all the contingencies, at some point the formal direction no longer fits the immediate need, and the people on the front lines need to adapt as necessary to the situation at hand.
Keith makes a good point about level of detail. You can have formal approval on what you are going to accomplish and your approach to doing so, without getting into the details of how the work will be performed. Part of your plan could be what you will do to identify the work to be done.
Consider the Risk Management Plan. At the beginning of a project, this is about how risks will be managed. Risk identification, analysis, and resolution come later. The Scope Management plan is similar - the rules for how scope will be managed, and changed when needed. You don't know the risks or how scope will change over the course of the project, but you need plans to address them.
Does this help?
Project Management Plan has to be formal, but all its components need not be. A sub-plan may be informal if the stakeholders agree to and don't have a particular interest in documenting or referring to it. All formalized plans are modified formally, through the Change Control process.
As they say, "Man plans, and God laughs"
The Project Management Plan is the overall main document any stakeholder may refer to in order to understand the steps required for a successful execution of the project. Depending on the needs of the Project, it "may be summary level or detailed" (PMBOK Guide 6th, pg 83). It may include, as sub-components, what you refer to as contributing plans, e.g Schedule, Cost, Risk Management Plans.
The reason the subsidiary plans may be formal or informal goes back to the needs of the Project. A project with a budget of $5,000,000.00 has a different 'planning resolution' required than one for $5,000.00. For example, the Schedule Plan for the higher budget plan will probably include many milestones and may even need recoveries/re-evaluations by the stakeholders based on the progress. It may have to be formalized. However, a Schedule Plan for the lower budget Project may only have one or two milestones and the stakeholders may not even refer to it until the Project is closed (most of the time, not even then). It can be formalized, but the overhead required to keep it formalized (Change Review, Communications, Revision Control) may not justify its benefit. I believe this is what Keith is referring to as 'level of detail'.
The Project Management Plan needs to be formal, because there must be at least one document that reflects the Project. The remaining depend on the Stakeholder and Project requirements. Formality, to my understanding, just refers to how 'official' the plan is, and by result, how accurately it can be relied upon to reflect the Project.
God may laugh, but there are critical insights that result from the creation of a plan. It is essential to understand what the Cost or Schedule of a Project has to be, even if its informal. With the increased requirement of Agility, a lot of components of plans are purposefully kept flexible to allow for adjustments during execution. Therefore, for example, a plan to manage Risk must be there to address risks as they appear through the execution, as Aaron mentioned.
The second part of your question refers to the updating of the plan. To be clear this is for the Project Management Plan, and any sub-components that are formalized. Formal updates are only done after the Plan(s) have been Baselined, and is done through the formal Integrated Change Control process, and this will also be defined in the Plan.
If I misunderstood your question, let me know.
Please login or join to reply