“Where?” can seem a strange question, maybe inserted just to get the “W” count up to five. We don’t want people to stop reading our project charter because they came across pages of calculations. If these components are necessary and not in separate documents, include a summary in the charter body and put the details in an appendix. It may reference a separate business case or return on investment analysis. The business case or problem statement is where we describe it. What new revenue will it bring? What problem or legal requirement does it serve? What new opportunities, new products or new customers do we hope it will attract? Projects are expensive and risky endeavors, so we better have a good reason to undertake one. People need to understand why this project is important. Just make sure the what and the why are addressed early on. That is fine follow your organization’s standard, or the preferred sequence of who approves project charters (or failing those, your own preference). Some people put this section before the what. The why of a project is described in a “Problem Statement” or “Business Need” section. It is better to have sponsors or user representatives complain now rather than halfway through the project (or worse, at completion when there is nothing we can do about it) that their anticipated element will not be delivered. So, a list of “out of scope” items is also valuable. When defining what the project will deliver, it is also useful to state what it will not deliver. People need to understand what we are talking about before they can appreciate further details such as schedule and approach. So, in the scope section, we would describe or list the major deliverables or high-level functionality the project should deliver. The “W5+” idea is just a tool to make sure we address the important sections. In your project charter, you will not call the section “What?” It will likely be called “Scope” or something similar. So, let’s get started by reviewing each question… Provided the project charter answers the W5+ questions and provides approval to start the project-all at the appropriate level of rigor-it’s a winner. We can call the what, why, where, when, who questions W5 and add a “+” for the final how question. So, my definition of a project charter is a document that authorizes the project and explains the what, why, where, when, who and how aspects of the project. The style points we lose for a lack of sophistication are made up for by improved comprehension and clarity. I probably miss subtle nuances but have learned that most people appreciate simple, clear documents.
I am a simple person and like simple ideas and definitions. Once we know these things, we can start writing our charter.
These can take teams of experts weeks or months to create.
Large, critical projects will require large comprehensive charters. The project charter for kicking off a safety-critical public works project will be very different than a charter for a small internal project to, say, build a tool to recover disk space used by duplicate files. It will also be driven by factors such as project size, criticality, type, approach, etc. The definition of what makes an acceptable-or great-project charter will vary from organization to organization. First, it is critical to understand that context matters.
0 kommentar(er)
