How does one determine which document to use in a particular process group? I mean in the "Initiating Process Group" one can draw up any one of the following documents:
1) Business Case
2) Project Charter
3) Statement of Work
Now how do I determine which one of the above mentioned to use or are they the same thing with merely a different name? I also don't want to "manage the project to death" and end up with too many documents for every single process.
The above mentioned leads me to the next question: In a "weak matrix organization" how do you decide which document is a must and which one can be omitted? I do not want to introduce a project management approach in the organization and end up creating more work and paperwork in the process Saving Changes...
Sort By:
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
You would do the project charter. The business case precedes the charter and a project cannot initiate without an approved business case. The SOW succeeds the project charter during planning when you need to plan the work and create the WBS. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
You can use all of them but based on my personal experience I saw that business case is required and used to approve the investment and project charter is required and used to start the project. It will be useful no matter the type of organization and size. The format is up to you or your defined process. For example I used one page project charter in the past but it contained all needed to stay clear about the project critical success factors. Saving Changes...
Jess De OcampoLean Six Sigma Professional/Project Manager/Consultant/| .Manila, Ncr, Philippines
Our practice to cut on paper work and legwork is we create the project charter. The business case, project description/mission, problem statement etc. are indicated in the project charter.
In one document, the project sponsor/champion and stakeholders can read all pertinent information--business case, rationale for undertaking the project, etc. which makes approval of projects easier.
...
1 reply by Anton Oosthuizen
Jul 25, 2017 12:57 AM
Anton Oosthuizen
...
I have a fundamental problem with this approach. When writing documents, any document, you must consider the audience and write with them in mind. If you write a document to cover the needs of all stakeholders, which are more often quite different, you create a lot of weed that people need to cut through to get to what they want. The probability of losing their support is very high. The unfortunate truth of the matter is that there will always be overlap and the repeating of the same information to different stakeholders but while the gist might be the same the delivery will be different, should be different.
But if it works for your company then don't fix it if it ain't broke.
Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Jul 24, 2017 9:26 PM
Replying to Jess De Ocampo
...
Our practice to cut on paper work and legwork is we create the project charter. The business case, project description/mission, problem statement etc. are indicated in the project charter.
In one document, the project sponsor/champion and stakeholders can read all pertinent information--business case, rationale for undertaking the project, etc. which makes approval of projects easier.
I have a fundamental problem with this approach. When writing documents, any document, you must consider the audience and write with them in mind. If you write a document to cover the needs of all stakeholders, which are more often quite different, you create a lot of weed that people need to cut through to get to what they want. The probability of losing their support is very high. The unfortunate truth of the matter is that there will always be overlap and the repeating of the same information to different stakeholders but while the gist might be the same the delivery will be different, should be different.
But if it works for your company then don't fix it if it ain't broke. Saving Changes...
Tom BjörkholmConsultant| Knowit ConnectivityLinköping, Sweden
If you are working for a larger organisation, the organisation probably have internal rules for what documents you need to write when.
If not try to go with as little documentation as possible. The customer of the project pays you to create a product/service. The customer has not bought project documents. Do the minimum documentation necessary, and for each document ask yourself how this document helps the project produce its product/service.
As Anton points out every document should be written with the reader in mind. What does the reader want to know. Sometimes I have written one document for several types of readers by writing a short chapter for each type of reader, and then adding some reference material in later chapters for the really interested reader (of any type). You have to see what works for you. Anyway write the document for the reader, and not because it is part of a process.
The project charter is a very important document as it describes the authority you have as a project manager/leader. Without that official document to show your authority it is very easy to run into trouble in most organisations. Saving Changes...
I would use all three, since some valuable information is not always transfert from one to the next in a clear way. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Robert, you got some good responses here. Most of the required documentation should be laid out by the organization; with typically a matrix of required documentation based on project size - a small project may only require the most basic of required documentation, however, a larger initiative would require a larger set of formal documentation. If this does not exist, this can be a great process improvement to design and implement as part of your goals. Saving Changes...
Check with your internal PMO. They may have standards on what templates to use, a SDLC, project guidelines including project lifecycle, budget lifecycle and operational handbook. The guideline may also include how to put out contracts and create statements of work to hire consultants or vendor services.
A good rule of thumb for small org is: one page project charter
Medium org: Business case, one page project charter, management plans and what is identifed by PMO and or contract.
Large Org Business case, complete comprehensive project management plan with one or more of the management plans and what is identified by the PMO, and /or contract.
You should use the right fit of tool, templates, methods and technique for right project and customer.
If you are a PMI member, download the latest PMBOK also. Saving Changes...
Mikel SteadmanPMO Leader| Development Dimensions InternationalTroy, Nh, United States
Business Problem/Opportunity Statement --- User Story --- Business Case --- Charter --- SOW Saving Changes...
