4squareviews

In the last post, I discussed the tools and techniques used, in particular that of product analysis, which takes the requirements and translates them into meaning deliverables (i.e., the scope) that are needed to deliver the final product that fulfill those requirements.   Those deliverables are what get put into the Project Scope Statement, the major output of this process.    The process also creates updates to some of the project documents.

The PMBOK® Guide makes an important point in that some elements of the project charter seem, at first glance, to be the same as those in the project scope statement, but those elements which are similar are at a high or more general level of detail in the project charter, whereas those in the project scope statement are a greater level of detail.   I will note those distinctions below…

5.3.3  Define Scope:  Outputs

Here are the elements of the project scope description.

1. Product scope description–a narrative description of the characteristics of the product, service, or result of the project.   At the high level of the project charter, this product description is sometimes referred to as the “statement of work”, essentially the “seed idea” of the project.   But in the project scope statement it is elaborated further.
2. Deliverables–a deliverable is defined as “any unique and verifiable product, service, or result that is required to be produced to complete a process, phase, or project.   These deliverables are the “building blocks” of the project that when completed create the final deliverable which is then validated by the customer in the 5.5 Validate Scope process.   The equivalent category in the project charter are the high-level requirements–these are exactly what are translated as a result of this process into the deliverables that go into the Project Scope Statement.
3. Acceptance criteria–the set of conditions that is required to be met before deliverables are accepted.
4. Project exclusions–In July 1963 “The Plain Dealer” of Cleveland, Ohio published an article titled “Why Are Elephants?” with several cartoons and jokes on the theme of elephants.   The following quip described a common sense approach to creating a sculpture:
   

   “How do you make a statue of an elephant? Get the biggest granite block you can find and chip away everything that doesn’t look like an elephant.”

   This was obviously meant to be humorous because you can imagine the bewildered art student hearing that sage advice and finding it not very helpful at all.   However, when you are creating the project equivalent of a huge elephant, sometimes it is helpful at the beginning of the project to state explicitly what is not going to be in the scope.   This helps prevent unnecessary changes because you can point to this exclusion when someone decides to try to add that particular scope during the course of the project.   Now you can include exclusions in the project charter as part of the larger category of boundaries, which are requirements which are going to be in the scope, but can also include those features or characteristics which are not going to be in the scope.   This can be because they are envisioned to be part of a future project if the current project is successful, or because the excluded features are explicitly not wanted by the sponsor.    Putting such exclusions in the project charter as part of the boundaries can be pretty persuasive to those suggesting adding those features to the scope, because now rather than having to argue with the project manager to include them, they now have to talk to the project sponsor!

5.3.3.2  Project Documents Updates

• Assumptions log–sometimes the Define Scope process of turning requirements into deliverables uncovers additional assumptions or constraints that were not previously apparent when the project scope was at the more abstract level of requirements.
• Requirements documentation–sometimes the review of the requirements may result in adding requirements, or changing the requirements themselves, and these changes or additions are added to the requirements documentation, which can include the requirements traceability matrix.
• Stakeholder register–when new information about the stakeholders comes to light during their participation in this process, particularly their views about the various requirements they care about, it is recorded in the stakeholder register.   It should be listed there whether they are to be consulted regarding a decision involving the requirements, or whether they should be informed afterwards regarding a decision involving those requirements.

Filed under: Uncategorized |