Please login or join to subscribe to this thread
According to most methods a Vision/Scope document is created before the project starts. Therefore it is more-or-less equivalent to a Project Charter.
See my blog post here: How to Create a Pre-Project Document
Sometimes it's easy to get tied up in the definitions fo the documents. I try to settle these by making an assumption of what I am going to usethe document for, and then get these assumptions OK'd before proceeding.
In a structured environment, using a method, this will already be settled. I suspect you're working in a non structured environment and this makes the water muddier.
A Project Charter or Vision/Scoping are overlapping documents (some might argue that they are the same). Without a Vision or scope, it's hard to develop a Charter, I might have thought....
I have to agree with Rob. There is a lot of overlap and grey areas with all these terms.
I teach people that project charters grant authority. They are the document that grants authority to the PM. They name the PM, they are issued by someone high enough to authorize the project, and they make clear that the PM has authority on the project. See my alexsbrown.com web site for more articles on charters.
A vision & scope statement could be part of the charter, or it might be a separate document. A good charter ought to have some statement about vision and scope, but it will probably be vague. At the very start, when a PM is appointed, the scope will probably be vague. As the project progresses, the vision and scope statements may change and get more specific. Sometimes a PM is appointed before there is a clear vision. In this case, the scope and vision statements in the charter would be very vague, and the scope of the PM's authority would be uncertain.
I hope these definitions help. They are based around the PMI PMBOK and PMI Glossary definitions.
Let me elaborate more:
The Vision and scope was used to get approval on the user requirements, architecture, design and the cost to the business unit that the IT service was being provided for. This customer approved V & S was then used to develop the service and implement the same for the business unit.
But a project management philosophy did not exist. I was brought onboard to bring about project management processes and make SDLC fit in.
When looking at the detail that existed in the vision & scope, I likened it to requirements gathering and the design and solution that best fit the user needs and the cost for the solution.
So if I were to use PMI process methodology, all of the vision & scope activities aligned more with the planning activities of PMBOK and requirements & design activities of a SDLC. I might be wrong in my perception and hence the question.
The Charter combines an initial scope with it, yes, it authorizes the project manager & the project. But for an enterprise with no structure, I combined it to include all of the initiation activities namely, id project stakeholders, objectives, goals, justification, financial benefit, Scope, CSFs, deliverables, milestones, assumptions, constraints, risks, dependencies, project selection data that used an opportunity and risk scoring model, financial & resource info.
My argument is that since vision is detailed out in terms of scope & design, it should be used after a charter is approved. But my collegue's argument is how do we know it's a project without us having an approval from the business unit for the service that we will be providing? My counter argument is, once a business unit indicates a need through a request, it needs some preliminary analysis which will result in a charter and approval by our steering committee, before the customer is informed of the solution & the cost. If it did not end up in a contract, then the project should be closed.
So any help in clearing this out for me and making the process more obvious to me is greatly appreciated.
Thanks in advance to all.
I agree with your perspective. If the scope and vision is detailed, then there should be some document authorizing the PM before the scope and vision is complete. Of course, the sponsor or purchaser needs to sign off on the proposal, but someone need to authorize the team to even prepare the proposal.
One note on PMI and the PMBOK Guide -- it is not a methodology, just a guide. You can create a methodology that is aligned with PMI standards, but they really do not provide a methodology. Mostly PMI provides a common vocabulary, so we can speak a common language.
Your company might use "vision", "charter" and other words differently than the way PMI or we do. To me, that does not matter. The key is that they have appropriate controls, so the work gets done, and so the company has proper controls.
I work with different companies, and none of them use the PMI jargon 100% of the time. I only use it when I am at PMI conferences, as a way to talk to other PMs from other industries. You might want to draw a map between what your company says and does and the PMI terms, but do not worry too much about the exact terms.
Actually, although I love the topic of "charters" and wrote a lot about them, I have never seen anyone except PMI call them "charters"! They all use different words - Statement of Work, Contract, Opportunity Document.
"Although I love the topic of "charters" and wrote a lot about them, I have never seen anyone except PMI call them "charters"! "
Same here. We have a lot of customers that have no experience with software development projects. We need to present them with very simple to understand terms and titles, or it will scare them off. That why we simply call our project charters "Project Plans". Our customers understand the word "project" and they understand the word "plan". But these documents contain all the standard stuff, like vision, scope, stakeholders, constraints, etc.
My current employer uses the term "Project Charter" for at least one pre-project document. Essentially it's a high-level business case document that sets out the vague preliminaries for go-ahead. The term "charter" does cause some confusion with the business side as IT also has an internal document called a "charter." I greatly prefer "Project Plan" as mentioned below. Another point about such documents is that they should remain alive throughout the project. Update them. Revisit them. Has something changed from the original conception? Does this change affect schedule or resourcing? A charter, plan, vision, scope, whatever you call it ultimately serves as a preliminary baseline for a project.
Here's a pretty good link to a description of a Vision and Scope Document:
Vision & Scope Document definition
In terms of PMI's PMBOK, I would map this document to what is referred to as Preliminary Project Scope Statement which occurs after the development of the Project Charter. The charter according to the PMBOK is one of the inputs to the prelim scope statement.
That is not to say that you have to follow that particular order, as I am in a project right now where I found a need to develop a V&S document that feed into the Project Charter.
The V&S document gave me the necessary agreement on scope amongst my stakeholders which helped tremendously in developing and getting approval for the charter.
As others suggested, use these frameworks and documents as necessary to get your project moving along, and don't get so concerned as to complying with what the proper notion of being a charter or vision and scope statement is and where it fits in a particular framework.
Don Kim, PMP
Most of the time, the difference between "V&S" and a Project Charter depends on an organization. In my present organization, we call it a "business case document" which contains the vision, reason for doing this project and consequences of not doing it etc., It is essentially a justification document to the management to consider doing that project. The project charter would incorporate this business case in addition to assumptions, constraints, risks, stakeholders etc., IMHO, I would say that the "V&S" (or the business case) is a subset of a Project Charter.
I agree with Magesh - every company seems to do it a little differently. PMI provides a standard - a starting point, if you will. As to the original question:
"What is the major difference between a Vision & Scope Statement and a Project Charter.
According to me, a 'V&S' is similar to a scope statement and should be used for requirements gathering and capturing the solution for the requirements, but according to another it is similar to a project proposal and hence should be developed before even considering a Project Charter. "
..there are definite similarities. For me, the term "progressive elaboration" comes to mind. Someone, somewhere, has a vision for a project. Over time, the scope of the vision is broadened and documented. Eventually a project is initiated and a charter may or may not be created that identifies what the project manager is empowered to do and what the general objective of the project is.
The PM then begins working with the sponsor to understand the vision for the project and then (in my case, at least) begins working with IT and the business to detail out the scope of the project. The scope of the project may or may not change over the course of the project, either due to scope creep or change management.
It could be argued that the vision and scope are not complete until the project is complete, but that would not be completely accurate. At any given point in time, the sponsor will (hopefully) be able to identify the vision and scope of the project, even if it changes each time you ask.
Vision and scope statements provide the documentation for what the sponsor wants, and they can be included in the charter which, ideally, identifies who is empowered to do what, at a high level, on a project. It has been my experience that preliminary documents, such as vision and scope, get incorporated into later documents in a project, such as the project management plan, and are subject to change. On the rare occasions when I have had a charter on a project, it has not changed even when the vision and scope have. I was still chartered to accomplish the objectives of the project, even though the objectives may have changed.
Please login or join to reply