Every project is driven by a requirement of some sort, the hard part is translating that business requirement into an end product that fully meets that business need.
My back ground is manufacturing, manufacturing tends to be a series of iterative steps that lead you to a product that fulfills the requirement. I try carry the same iterative approach to my project chartering.
Sitting in a meeting listeing to the sponsor tell you, in detail, what they want the project to achieve is easy. I have found time and time again that what the project team hears and starts working towards is not what the sponsor meant.
When the project only delivers part of what they customer wants (and thought they were paying for) there is typically plenty of blame to go around.
By the time the team, sponsor and whoever else is involved has discussed, reviewed, feedback and finally gained clarity as to exactly what the deliverable is and written the charter we have defined the following:-
Business requirements. All detailed requirements should be based on clear business needs. This comes from and executive sponsor, manager or someone with a very clear understanding of the project and the value it will provide to the customers
Scope. In my opinion the most critical part of the charter. It’s not only what will be included in the proposed solution, but also what will not be part of the project. It establishes exactly what the scope and limitations of the deliverable is so the various stakeholders (and the team) have an agreed upon standard against which they can evaluate the final product. Once agreed upon this is the baseline which the change management process starts with.
Context. Any business issues related to the project need to be clarified. Assumptions, priorities and ground rules need to be clearly stated.
Vision. A long-term vision for the new system and the need it will fulfil both when the project is complete, and into the future further along the product lifecycle.
One of the common issues this stage identifies is that the two groups (sponsor and project team) are not speaking the same language. Typically not everyone has a deep technical understanding or intimate knowledge of the process. If the scope contains too much technical language then the business requirements that we are trying to fulfill may become dilute or lost. This is why the business requirements should be part of the top level project document.
This step is all about reducing risk to the project and the project team. Taking a very thorough approach during the charter stage of the project, the PM greatly reduces the risk to the project, the project manager and the stakeholders.
By clearly documenting the project’s vision and scope in writing, and fully clarifying all requirements we create a proposal that will meet the business need, contain costs, and reduce the risk of failure.