Project Management Central

Please login or join to subscribe to this thread

Practice Areas: Agile, PMO
Project documentation
Network:324



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
Sort By:
Network:450



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.
Network:1194



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.
Network:584



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.
Network:450



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.
Network:271



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.
Network:66797



I would use all three, since some valuable information is not always transfert from one to the next in a clear way.
Network:1176



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.
Network:1648



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.
Network:70



Business Problem/Opportunity Statement --- User Story --- Business Case --- Charter --- SOW

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Do not worry about your difficulties in Mathematics. I can assure you mine are still greater."

- Albert Einstein

ADVERTISEMENT

Sponsors