Lara DollProject Manager, CAPMFort Worth, Tx, United States
Hello everyone,
In regards to major documents for a project, I've seen many different opinions on this and I would like to see what people in the trenches actually use - when they are developed and how they are put into play.
For example, I see some people mentioning a Business Case, and then others don't mention this, but are keen on a Project Charter.
What are the major documents you use? When are they created and put to use?
Thanks for your replies in advance! :) Saving Changes...
Dinah YoungProject Manager / Software Asset Manager| Prince William CountySpringfield, Va, United States
We create a charter for every project. Because our project are of varying size and complexity, we do not always create a business case document. There is a business case section in our charter. But the full document is only created for larger projects that we may need to "sell" to upper management.
Then every project has a project management plan that incorporates the other plans within it. Some of those other plans may be very simple or may not be required. If there is no procurement, we do not need a plan. Just a line saying so.
Scope Management with Requirements/User Stories, Cost Management, Quality Management with test plans, we do pretty well and Procurement Management. We are improving on Risk Management, Human Resource Management, Schedule Management, Stakeholder Management and Communication Management we are working on improving.
If this is a technical project, there will probably be a deployment plan, though we have no template for this.
Finally, we have a project completion document which includes Lessons Learned.
Documenting many of the pieces of Project Management was often seen as a useless endeavor. We are in the process of trying to change this feeling. Saving Changes...
Early development:
- Charter at the beginning to authorize work of a defined scope.
- Business case to justify the project and steer the decisions (including sometimes termination).
- High level work statement (about WBS level 3 to 4) used to better define the scope and develop the SOW
- KPIs like a kiveat/radar plot to strike an estimated performance baseline and use for monitoring change activity
Detailed development after project launched:
- Detailed statement of work broken out at the individual group level. This is for budget and schedule development among other things.
- Integrated schedule generated from the work statement
- Some type of EVM tracking even if not actually CPI and SPI
- Risk register with risk handling plans
- Some type of change management summary. (potentials, in-work, and incorporated)
Execution phase. This is often a "deck" of PowerPoint slides with progress in various areas but it is to maintain visibility of things like cost, schedule, risks, etc. This is a high level roll up of how the detailed plans are doing. There's often both ongoing performance used to manage the activities and major milestone reviews like PDR and CDR reviewed with internal and external stakeholders.
Closure phase:
- Some type of evidence of completion, such as the closure of all verification and certification activities.
- Follow on activities, like if there are bug fix type activities, planned future enhancements, etc.
- Lessons learned
- After action reviews (things we need to go and figure out what went wrong)
I'm sure I'm forgetting some, but all are tailored to the needs of an individual project. Part of the trick is not spending all your time managing a bunch of documents so you still have time to work on actual planning and execution. On really big projects, I'll have teams of PMs with different specialties managing different subject matter.
...
1 reply by Lara Doll
Nov 15, 2018 9:42 AM
Lara Doll
...
Keith, you are the man. I was really needing something like what you provided. Since I was tossed into this right in the middle, (and because I'm new), I didn't know what I needed to draw up as PM. This really bothered me because I always aim to give 110% to whatever job I'm working on... and I couldn't!
Yeah, there is a lot of info out on the net, but it's usually written by folks that have been in PM for a while, and therefore, aren't thinking with the mind of a noob. I've seen mention of Project Charters, Business cases, Project Scope, etc, but nothing has said what order they need to happen and who creates these documents. At first I thought a PM would do it, but the more I searched, the more confused I became.
We are facing another huge project, and the info you provided here helps me understand what needs to happen... IN THE BEGINNING going forward, but also what boxes I need to check in the current project.
Hi Lara,
Documents vary according to complexity and SOPs of the project and organization.
I had worked on Project Charters which comprises of business case, goal, scope, timeline, and team members. After Project Charter, Risk Registers and Lessons Learned are created and updated as the project progresses. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
We have a governance process defined. The governance process is adjusted to the tier classification of our projects (we have tier 1 to tier 5). Governance process determines the deliverables we need to create. On the other side, you have two roles involved: business analyst (she/he is accountable for all related to product/result/service to be created) and project manager (she/he is accountable for all related to the work needed to create the product/result/service as defined, not for defining it). Inside our governance process, there are minimun deliverables to create because we detect that there is a high risk to fail just in case they do not exists. Those are: 1-business case, this is the document where the right people said "yes, we will invest on this". 2-project charter, is "the contract" between all involved people on the initiative. 3-requirements document, remember there are two types of requirements: product requirements (business analyst is accountable for that) and project requirements (project manager is accountable for that). Project requirements are defined from product requirements. 4-Project scope, to clear define "what is included" and "what is not included". 5-Stakeholder acceptance, to assure that the project achieved the objective. 6-Project close document. Saving Changes...
Lara DollProject Manager, CAPMFort Worth, Tx, United States
Nov 14, 2018 5:40 PM
Replying to Keith Novak
...
In a large project like your SW development:
Early development:
- Charter at the beginning to authorize work of a defined scope.
- Business case to justify the project and steer the decisions (including sometimes termination).
- High level work statement (about WBS level 3 to 4) used to better define the scope and develop the SOW
- KPIs like a kiveat/radar plot to strike an estimated performance baseline and use for monitoring change activity
Detailed development after project launched:
- Detailed statement of work broken out at the individual group level. This is for budget and schedule development among other things.
- Integrated schedule generated from the work statement
- Some type of EVM tracking even if not actually CPI and SPI
- Risk register with risk handling plans
- Some type of change management summary. (potentials, in-work, and incorporated)
Execution phase. This is often a "deck" of PowerPoint slides with progress in various areas but it is to maintain visibility of things like cost, schedule, risks, etc. This is a high level roll up of how the detailed plans are doing. There's often both ongoing performance used to manage the activities and major milestone reviews like PDR and CDR reviewed with internal and external stakeholders.
Closure phase:
- Some type of evidence of completion, such as the closure of all verification and certification activities.
- Follow on activities, like if there are bug fix type activities, planned future enhancements, etc.
- Lessons learned
- After action reviews (things we need to go and figure out what went wrong)
I'm sure I'm forgetting some, but all are tailored to the needs of an individual project. Part of the trick is not spending all your time managing a bunch of documents so you still have time to work on actual planning and execution. On really big projects, I'll have teams of PMs with different specialties managing different subject matter.
Keith, you are the man. I was really needing something like what you provided. Since I was tossed into this right in the middle, (and because I'm new), I didn't know what I needed to draw up as PM. This really bothered me because I always aim to give 110% to whatever job I'm working on... and I couldn't!
Yeah, there is a lot of info out on the net, but it's usually written by folks that have been in PM for a while, and therefore, aren't thinking with the mind of a noob. I've seen mention of Project Charters, Business cases, Project Scope, etc, but nothing has said what order they need to happen and who creates these documents. At first I thought a PM would do it, but the more I searched, the more confused I became.
We are facing another huge project, and the info you provided here helps me understand what needs to happen... IN THE BEGINNING going forward, but also what boxes I need to check in the current project.
Thanks a lot. :)
...
1 reply by Keith Novak
Nov 15, 2018 10:30 PM
Keith Novak
...
Glad I could help and welcome to the fun world of project management where you sometimes just get tossed into the middle of stuff. I was completely dropped into my first big PM job too so I know the feeling. :-)
Keith, you are the man. I was really needing something like what you provided. Since I was tossed into this right in the middle, (and because I'm new), I didn't know what I needed to draw up as PM. This really bothered me because I always aim to give 110% to whatever job I'm working on... and I couldn't!
Yeah, there is a lot of info out on the net, but it's usually written by folks that have been in PM for a while, and therefore, aren't thinking with the mind of a noob. I've seen mention of Project Charters, Business cases, Project Scope, etc, but nothing has said what order they need to happen and who creates these documents. At first I thought a PM would do it, but the more I searched, the more confused I became.
We are facing another huge project, and the info you provided here helps me understand what needs to happen... IN THE BEGINNING going forward, but also what boxes I need to check in the current project.
Thanks a lot. :)
Glad I could help and welcome to the fun world of project management where you sometimes just get tossed into the middle of stuff. I was completely dropped into my first big PM job too so I know the feeling. :-) Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
PMBOK says that the Charter Authorizes a Project Manager to commit funds and resources to the initiative and Business case is an input into it.
I have worked in organizations where we had a Business Proposal (could vary from a short form BP to a full fledged multi-page document)where we justified why we needed the project and also put the organization structure in there, including the PM. it also mentions the high level scope, high level time lines , high level business benefits et al .
In Simple terms
Someone needs to justify to whoever is paying for the project (Sponsor)
1) why you are undertaking the project
2) what is the scope of your project
3) when will you deliver the project
4) how you will deliver the project
5) who is going to govern the status (is there a steering committee?).
The sponsor needs to sign off and authorize you to start working on the project.
This document may already be created before you are made the Project Manager or you may be asked to create it .
The document may be called a Project Charter (Must be really high level) or a Business case (could be high level or detailed) or a Business Proposal (again detailed or high level). It really depends on what the Project Management Office (PMO) if you have one , has stipulated. They may even have templates on how they are expecting the Business Cases/Charters/Project Initiation Document/Business Proposal to be documented.
Please do not get stuck in the Jargon . Just ask the simple question "What do you expect me to produce? "
If they don't have a template, create one, call it any of the above and then get the sponsor to sign off. Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
To answer the second question as to what documents are produced , here is a list that I have seen and been responsible for in my projects
Business Proposal Business Requirements Specification (in Agile world these are User stories in a Tool like JIRA) Project Management Plan Solution Architecture Document Detailed Design Document System Test Plan System Tests (May be executed in an electronic system like Quality Monitor) System Test Report Requirements Traceability Matrix (Tracing Requirements all the way from Analysis to design to testing) System Support Plan / Handover document Project Closure Report
During the Project execution Project Status Report (Monthly , to the steering committee) Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
And now with your new found knowledge, you can begin to set the guidelines for your organization, and champion a formal process going forward. Great opportunity!
...
1 reply by Lara Doll
Nov 16, 2018 9:06 AM
Lara Doll
...
Very true, Andrew. Thanks for pointing that out! You'd think I would have thought of that by now, but 'doh!' I'm the guinea pig AND the trailblazer!
"People are always blaming their circumstances for what they are. I don't believe in circumstances. The people who get on in the world are the people who get up and look for the circumstances they want and, if they can't find them, make them."
