|
Recursion Project
1 Methodology 1-1 Guidelines 1-1-1 Purpose
The purpose for this project is to demonstrate the use of the PMI methodology through a comprehensive set of project documents. 1-1-2 Copyright
1-1-3 Table of Contents
1-1-4 Guidelines on the Document Creation Sequence
1-1-5 Glossary to the Components Activity Duration Estimates Activity Duration Estimates should be prepared by the group responsible for executing the work. They are the experts on completing the work and are thus should be the experts on estimating the time required. The estimates are an input into schedule development and are a useful historic reference once the schedule is prepared. Activity List In general, an “Activity List” is a transitory document. Most projects are run with a project scheduling package – such as Microsoft Project, Primavera or others. In those cases, the activity list is simply an input into the creation of the schedule. Once the schedule is created, the activity list is discarded. Change Requests The Scope Management Plan defines the formal process for evaluating, reviewing and then authorizing or rejecting change requests. Change Request Form The purpose for this document is to explain the reason that a Change is recommended. Please provide the requested information with sufficient detail that the Change Control Board can make the correct decision. Change Request Log The purpose for this document is to record the status of the Change Requests that have been processed during the course of this project. Communications Management Plan The purpose for this document is to describe which communications need to be distributed to which groups at what intervals. On small projects it is expedient to combine this document with the Project Team Directory. Where there are privacy concerns, however, the two should not be mixed. Note that this is a critical document that must be maintained. In the event the project manager is absent, the substitute project manager should be able to quickly ascertain the communications requirements from this one document. Distribution Package The final deliverable from this project should be an archive file that can be posted on a web site. This archive should contain the defined policies and working templates. The preliminary distribution will be via a web site. Documents will be uploaded and linked to the site as they are completed. The final distribution will allow users to choose to view or download a single document at a time or to download bundles of documents. The Scope for this work package is to create the user interface. Packaging the documents is covered in other work packages. Formal Acceptance Formal acceptance is achieved when the customer signs a statement of formal acceptance. The initial deliverable will be a template stating the general terms for formal acceptance. There will also be a document that specifically states the terms for formal acceptance on each of the first and second levels of the Work Breakdown Structure. Guidelines The purpose for this document is to explain the methodology used on this project. The goal for this document is to include an explanation for each document and each section heading. The initial release of the Guidelines document will illustrate the layout and include just enough content to prove that the concept will work. The final release of the Guidelines document needs to include explanations for each document and each of the major sections within those documents. When the final release is ready, then the interim will be moved to the Offl ine archive. Lessons Learned The purpose for this document is to record key lessons that have been learned during the course of this project. The intent is to use these lessons to streamline future projects. Many of the items on this log will come from the Issues Log. Filtering, however, should be used to restrict the content of this document to those issues significant learning occurred. Organizational Chart The purpose for this document is to identify and disseminate the reporting structure for this project. This document should be updated if there is a change in the structure of the project team. Organizational Policy on Project Archives The purpose for this document is to explain the project policy on document publication and document retention. The key criteria behind this policy are 1) accessibility to shared information and 2) compliance with legislation regarding document management. Note that this policy is intended to supplement the established corporate policies on document publication and document retention. In the event there is a confl ict between the project policy and the corporate policy, the most restrictive policy shall prevail. Performance Reports (incomplete). Policies Bundle In addition to project templates, one of the key requirements for a transportable methodology is to predefine standard policies and procedures. Product Description The purpose for this document is to describe the product in appropriate detail. This document, more than any other, should implement the PMI concept of “Progressive Elaboration”. The initial release of this document should describe the product adequately for the creation of a Project Charter. By the end of the project, this document should be so detailed that it can support the product release. Product Description for Charter A prerequisite to the Project Charter is a working Product Description. This description may be somewhat vague as long as the meaning is clearly understood by those involved. This description will evolve during the life of the project. Product Description for Release The final Product Description must be precise. This description must support the needs of all stakeholders, including the end users, support staff, marketing and legal. This is the description that must last the life of the product. Project Archives The Project Archives is one or more repositories for document. Today most documents are electronic so the Project Archives may be a file server, a web server or a document management system. The deliverable is the process of setting up the archive and moving the documents into it. Project Archives Online The Project Archives Online will be a web site maintained by the web site administrator. Project Archives Offl ine The Project Archives Offl ine will be a file directory maintained by the project manager. Project Charter The purpose for this document is to provide justification for the allocation of resources to begin formal planning for the project. While some resources are required to even create the Product Description and Project Charter, no other work should proceed until the review board has authorized this project. Note that this will be a static document. Once approved, there should be no further changes to this document. Project Closure (incomplete) Project Network Diagram. The Project Network Diagram is a tool useful in planning and re-planning the Project Schedule. It is generally maintained by the person or persons responsible for the project schedule. It is generally not distributed to the project team because the Project Schedule provides the same information in a more user-friendly format. Project Presentation The purpose for this document is to describe the project. The intended audience is individuals interested in participating in the project on either the peer review or customer review teams. Project Report The purpose for this document is to provide a status update identifying progress and issues. This report is to be updated and distributed weekly to the Project Team. The content of this document consists of a Project Status Summary, the Project Milestones the Project Issues Log. The Project Report Template will define the format to use for the weekly project report distribution. Then, the project manager will use the Project Report Template to create a weekly report outlining the project accomplishments, project issues and project status. Project Schedule The Project Schedule is a consolidation of information including the activity list, the activity sequencing, the activity durations and the role and responsibility assignments. The initial schedule, once approved, will become the baseline for the project schedule. Thereafter, the project schedule should only be updated when a schedule change is properly authorized. Project Team Directory The purpose for this document is to facilitate communication within the team. The directory should list the names, titles and contact information for the entire project team. Distribution of the Project Team Directory must be restricted, however, to protect employee confidentiality. Recursion Product The product to be built during the course of this project is a set of documents. It is expected that there will be about thirty total documents, but that number will be refined during the course of this project. These documents must be made available through an internet portal. Roles and Responsibilities Assignments The purpose for this document is to disseminate a common understanding of the responsibilities for each deliverable. The primary content of this document is the Responsibilities Assignment Matrix (RAM). The RAM consists of a 2x2 matrix listing the roles and the assignments. The junction of a role with an assignment is a cell which contains a designation of the responsibility this role has for this assignment. Roles and Responsibilities Execution Release Once the project team has been formed, the RAM should be updated to refl ect the agreements on scope and responsibilities. Adjustments will continue throughout the life of the project, but the magnitude of those changes should be minimal. Roles and Responsibilities Planning Release During Planning the team may not yet be formed and the full scope may not yet be defined. It is still important to release a RAM as early as possible. Scope Statement The purpose for this document is to analyze the product that is the justification for this project. This document is a transition between the Product Description and the Work Breakdown Structure. The Product Description will evolve, through progressive elaboration toward a detailed description useful to the end user of the product. The Work Breakdown Structure will evolve into the tasks on the project schedule. Projects with a limited scope may combine two or more of those documents into one. Note that this document can be frozen once the WBS is defined because the WBS and the WBS Dictionary will become the primary reference for the product specific information needed by the project team. Schedule Management Plan The purpose for this document is to define the technique to be used to track schedule variance, detect changes and then authorize or reject those changes. The schedule management process must be tightly integrated with the scope management process. Scope Management Plan The purpose for this document is to describe the techniques and procedures to follow to insure that scope changes are detected, reviewed, and then either approved or rejected by the proper authority. Staffing Management Plan The purpose for this document is to define the start and end dates for the project team staff. This document should also outline the staffing approach for this project. Key items to be defined are whether the project will use in-house staff, contractors or off-shore resources and whether the project team will be dedicated or shared resources. Template Bundle The vision for this project is to first complete one set of project documents and then to strip the content from a copy of those documents to produce a distributable set of project templates. After all of the documents have been created each will be copied and stripped of content to create a template for future projects. The bundle will be published on a web site for distribution and reuse. Template Definition for Portrait The original scope of this project underestimated the work required to choose the proper document formatting tool and design a consistent text layout. Now that this work package has been identified, it has been added to the WBS. The scope for this specific deliverable is to create a blank portrait template using the designated format. Template Definition for Landscape The content of some documents is best displayed in landscape mode. The deliverable for this work package is to adjust the 1.2.1 Portrait Template Definition into landscape mode. Work Breakdown Structure The purpose for this document is to apply a structure to the list of Product, Major Components and Deliverables brought over from the Scope Statement. The goals for this process are to insure that all deliverables have been identified and to organize those deliverables into “work packages”. A “work package” is a bundle of tasks that can be assigned to a project team. The WBS should contain a schematic to illustrate the work packages and a WBS Dictionary. The schematic is a logic view of the product – not a physical view. For example, the WBS for a house might include packages like “clear ground”, “install utilities”, “pour foundation”. But, it might also include packages such as “obtain financing”, “choose contractor” and “choose appliances”. The WBS must be maintained through the life of the project because it will be a primary reference tool for the project team. The WBS should also be carried forward through the life of the product since it clearly describes each component of the product. For most projects, it is important to fully define the work packages before work begins. However, on research oriented projects, there are times when the initial WBS may have gaps. This particular project has aspects of a research project because I have not previously followed the PMI methodology on Risk or Procurement. Therefore, the WBS will be initially released without full definitions for each of those work packages. As the research is completed, the scope for each work package will be fully defined in an updated WBS. Before the end of the project, the WBS will be complete. 1-1-6 Glossary for the Sections within the Components Activity Lists This is the key section in the Activity Lists document. In general, an “Activity List” is a transitory document. Most projects are run with a project scheduling package – such as Microsoft Project, Primavera or others. In those cases, the activity list is simply an input into the creation of the schedule. Once the schedule is created, the activity list is discarded. Assumptions This section first appears in the Project Charter. Assumptions are forecasts of factors outside the control of the project team that might or might not happen. Assumptions should be documented, tested, evaluated as risks, but assumed to be true. Benefit-to-Cost Analysis This topic first appears in the Project Charter. The project review board should consider both external constraints, such as legislative mandates, as well as pure business values. The benefi t-to-cost ratio is one of the simplest tools available for comparing projects. More complex projects should consider alternative tools such as Net Present Value or Internal Rate of Return. Business Need This section first appears in the Project Charter. Projects should be reviewed before being executed. The Business Need is vital in evaluating which projects proceed and which do not. For example, a project that is required for legislative compliance may take precedence over a project that has an excellent benefit-to-cost ratio. It is important that the business need be explained clearly so that the project review board can easily determine the validity and importance of this project. Change Approval This is a section in the Change Request Form. This is the location where either the Project Manager or the Change Control Board will record their approval or rejection of the proposed change. Change Request Form This is a section in the Change Request Form. Use this part of the form to describe the change. Include sufficient detail so that the evaluation will be accurate. Change Request Log This is the primary content of the Change Request Log. This table should be updated to record every change request that is processed during the course of the project. Change Results This is a section in the Change Request Form. Use this part of the form to describe the results of the implementation attempt. Was the change successful, or did it fail. Describe exactly what happened. Communication Schedule The Communications Schedule is first identified in the Project Charter. Typically a methodology is accompanied by standard processes and policies. Those standards are reused across projects. Thus, it is generally possible to declare an approach to communications management early in the project. Then, as the project proceeds, the plan must be adapted to the specific needs of this project. Constraints This section first appears in the Project Charter. Constraints are factors that restrict the options available to the project team. Typical constraints are time, scope and budget. Constraints can originate outside the project – such as a legal mandate to implement a change by a specified date. Or, constraints can originate within the project – such as a decision to only use one software package for all of the work even though that precludes more efficient tools for specialized purposes. Copyright This section should appear in every document. Always include a declaration of your rights to this document and describe the rights that others have to this property. Documents, especially electronic documents, will be transmitted and shared, sometimes to people and places you were not expecting. My standard document copyright declaration is included in the Copyright section in this document. A copyright declaration similar to what I use for proprietary work is: Example: “This document and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this document. Please notify the sender immediately if you have received this document by mistake and destroy all copies of this document. If you are not the intended recipient you are notifi ed that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.” Note how this declaration attempts to bar usage even if the document is inadvertently received. For documents that span multiple pages the best location for the copyright declaration is at the top of the document. For very small documents – like status reports, it is acceptable to place the copyright declaration at the end of the document. Deliverables Deliverables are first identified in the Scope Statement. Deliverables are the work results – the components of the product. They are identified in the Scope Statement by progressive elaboration from the Product Description and the Project Charter. They will feed into the Work Breakdown Structure as the initial list of items for the third level in the breakdown. Designation of the Project Manager This section appears in the Project Charter. The goal of the project charter is to formally recognize the existence of the project and to grant resources to the project so that it can proceed. One of the most important outputs from the Project Initiation process is the designation of the Project Manager. Document Retention Document Retention is referenced in the Organizational Policy on Project Archives document. Project Managers must be cognizant of the complex legal requirements for document retention. Most businesses have an established corporate policy on document retention. Many of those policies, however, are only intended to cover documents within the company. Projects tend to distribute documents between companies and often span local, state and national jurisdictions. Thus the project may be subject to far more stringent retention requirements than those described by the corporate policy. Duration Estimate The preliminary time estimate should be included in the Project Charter. This estimate will be revised during execution of the Time Management processes. Exclusions Exclusions should be identified as early as possible. If not already identified in either the Product Description or the Project Charter then they must be formally declared in the Scope Statement. Exclusions are items that might easily be construed to be included. They must be formally excluded so that there is no misunderstanding. Formal Acceptance Template. Periodic Formal Acceptance by the customer is critical to the success of the project. Like the bulkheads in a ship, a periodic signoff sets a boundary between the area of risk and the area of agreement. The Formal Acceptance Template used on this project is based upon the template from the PMI Compendium. Gantt Chart The Gantt Chart is used show the sequence of activities. Optionally it can also be used to show assignments, milestones and schedule variance. It is not a true network diagram, but it is used on this project in place of the network diagram because it is easier to compress to fit onto a standard sized sheet of paper. Glossary to the Components This is a section in the Methodology Guidelines document (this document). The content of this section is a brief explanation of the purpose for each of the project documents. Glossary for the Sections within the Components This is a section in the Methodology Guidelines document (this document). The content of this section is a brief explanation of the content for each section in each of the project documents. Guidelines on the Document Creation Sequence This is a section in the Methodology Guidelines document (this document). The content of this section offers guidance on the sequence to use when creating the planning documents that will be incorporated into the Project Plan. Identified Risks The process of risk identification should begin in the Project Charter. Risks are events that might impact the project either positively or negatively. The Risk Management processes delve into the identifi cation, ranking and evaluation of risks and risk responses. It is best, however, to note risks as soon as they are identified rather than waiting for the Risk Management processes. Issues Log This can either be a section in the Project Report or it can be a stand-alone document. This log gives visibility to issues that have been raised. It should clearly define the issue and state who is responsible for resolution. Also, once resolution is achieve, the log should record how the issue was addressed. After project completion, this is an important component of the Project Archives. Key Goals for Next Week This is a key section in the Project Report. The purpose for this section is to focus the team on critical tasks and remind them of impending deadlines. Lessons Learned Log This is the primary content of the Lessons Learned document. Lessons Learned are “gems” of knowledge that are often acquired at considerable price. The intent behind a lessons learned log is to allow the team and future teams to learn those lessons by reading a concise explanation. The alternative is for each team to continue to go through the same frustrations only to end up inventing the same “wheel” over again. Major Components This section first appears in the Scope Statement. The major components of the project are the second level in the Work Breakdown Structure. The Milestones in the Project Charter should give guidance as to what belongs here. Offl ine Archives The Project Management Information System for this project consists of a PMIS Documents web site, an attached Online Archive and a separate Offl ine Archive. The Offl ine Archive, also known as the Project Archives Offl ine, is a file directory structure on a shared disk drive. Organization Chart The Organization Chart is a diagram that shows the nominal reporting structure for the project team. This chart is first referenced in the Project Charter as a portion of the explanation of the Organizational Structure. It is important that it be formalized and distributed so that the team members can understand their role as part of the team. Organizational Structure This section first appears in the Project Charter. The content of this section should describe the reporting structure to use during the project. Initially the structure may be only a skeleton. During the Human Resources planning processes this structure will be expanded and staff will be assigned to the identified roles. PMIS Archives The Project Management Information System for this project consists of a PMIS Documents web site, an attached Online Archive and a separate Offl ine Archive. The Online Archive, also known as the PMIS Archive or Project Archives, is hosted on the same web site as the PMIS Documents. PMIS Documents The Project Management Information System for this project consists of a PMIS Documents web site, an attached Online Archive and a separate Offl ine Archive. The PMIS Documents section is the distribution point for the project documents. In this case, those documents are also the product. Procurement Forecast This section appears in the Project Charter. It is important to identify items that must be procured as early as possible. Product Description This section first appears in the Product Description document. This section needs to describe the product in sufficient detail that the project can move forward. As noted above, this description will evolve as the product evolves from concept to deliverable. Thus, the amount of detail required to begin a project charter may be fairly brief. While the amount of detail required to support the marketing of a released product is likely to be far more extensive. Too much initial detail will needlessly constrain the project, while too little final detail often results in mismatched expectations. Note that the version of the Product Description that appears in the Project Charter is a static copy of what was defined at the time the Project Charter was submitted to the review board. The Product Description should also serve as a description of the top level in the Work Breakdown Structure. Product Details This section first appears in the Product Description document. This section describes the high level objectives for the project. The content of this section are initially unconstrained. Begin by using this as a brainstorming area to record all of the thoughts that have come together to launch this project. Later, refine this content so that the document can be released to the end user. Project Management Approach The Project Management Approach is first identified in the Project Charter. Typically a methodology is accompanied by standard processes and policies. Those standards are reused across projects. Thus, it is generally possible to declare a Project Management Approach early in the project. Then, depending upon how much fl exibility is authorized, exceptions should be noted as they are identified. Project Management Information System (PMIS) The PMIS is referenced in the Organizational Policy on Project Archives document. A PMIS is a document repository. On many projects the PMIS is a shared portal where documents can be published and archived. It is important to be cognizant of the laws governing document retention both in the jurisdiction of the project team and the customer. Those requirements are quite complex on multi-national projects. Project Milestones Project Milestones are first identified in the Project Charter. Milestones should be clearly identified and linked to a tangible deliverable. Milestones are the most common metric included in Project Reports to upper management. The PMBOK 2000 identifies Project Milestones as an input to Activity Sequencing, but fails to identify which process is responsible for generating them. In my opinion, Milestones evolve through progressive elaboration from the original concepts recorded in the Project Charter. I also believe that milestones should be used to identify the second level in the Work Breakdown Structure. Thus, in my usage, the Milestones should correlate to the Major Components in the Product. Project Network Diagram The Project Network Diagram is a tool useful in planning and re-planning the Project Schedule. This should be the key content in the Project Network Diagram document. On this project, however, the Project Network Diagram has been replaced by a Gantt Chart. Project Status Summary The Project Status Summary is one of the major components of the Project Report. The Project Status Summary should provide a quick, executive level summary of the key accomplishments, risks and issues. This section should also summarize the resolution on issues that were raised in prior reports. This section must be brief because it may be the only “news” the project team reads during a hectic week. Purpose This section should appear in every document. Always include a brief statement of purpose to explain what is in this document. Not only does this remind each author, editor and reader of the scope for the document content, it allows everyone to quickly decide whether or not they are looking at the right document. Quality Expectations This section first appears in the Project Charter. It is important to have clearly defined expectations before entering into detailed planning. Quality requirements will impact the cost of the effort, the time required to complete the effort and may restrict the scope of the project. Resource Requirements This topic is first discussed in the Project Charter. Resource requirements are all encompassing and should include staff, equipment and purchases. For a software project the typical resources are staff, systems and software – but a project based accounting scheme would also include the overhead for benefits, space and utilities. For a construction project the resources typically include wages, materials and upkeep such as equipment maintenance. It is important to be inclusive when preparing the Project Charter so that the benefit-to-cost analysis is fair. In general, however, it is seldom possible to be entirely accurate until Planning has completed. Responsibility Assignment Matrix (RAM) This is the primary section in the Roles and Responsibilities Assignement document. The RAM consists of a 2x2 matrix listing the roles and the assignments. The junction of a role with an assignment is a cell which contains a designation of the responsibility this role has for this assignment. Revision History This section should appear in every document, except one-time documents like Project Reports. It is important that a reader be able to quickly determine what has changed with each document update. The revision history table should contain the date, author and a brief description of the change. More complex change control systems require that each update also include the name of the person who reviewed the change and a description of how this change was authorized for release. I also embed a versioning stamp in the document name. I personally use the change date in the format “yyyymmdd”. I prefer that format because it sorts correctly in a file list and because it is readily apparent how much time has elapsed since the last revision. Revision History and Authorization to Proceed This section is an expansion on the topic “Revision History” described above. In addition to the tabular history of who changed what, it also includes tabular entries to record who authorized the changes. This is important on the formal documents used at stage gates -- specifi- cally, the Project Charter and the Project Plan. Authorization is also a key item to note on Change Requests and Formal Acceptance documents. Scope Management Approach This is the key content in the Scope Management Plan. It describes the guidelines for how to detect, evaluate and then either authorize or reject changes to the project scope. Staffing Plan An initial assessment of staffing, cost and time should be included in the Project Charter. Those initial estimates are necessary when evaluating the project. During Organizational Planning, the staffing requirements will be formalized in the Staffing Management Plan. Table of Contents This section is appropriate for most documents. A Table of Contents (TOC) supplements the purpose statement in allowing a reader to quickly determine the content of the document. I recommend including a TOC in the template whenever the resulting document is expected to be three or more pages in length. I also recommend that each document should conform to the template with few, well justified exceptions. Thus, if the typical document generated from a template warrants a TOC, then even if this project has short documents, the TOC should remain for consistency. Work Breakdown Structure The Work Breakdown Structure is a graphical representation of the components of the product. The goals in creating a WBS is to insure that all of the deliverables have been accounted for and to organize those deliverables so they can be assigned to project teams. For small to mid-sized projects the WBS generally has three levels. The top level corresponds to the Product. The second level corresponds to the Major Components described in the Scope Statement. The third level corresponds to the deliverables from the Scope Statement. Work Breakdown Structure Dictionary The WBS Dictionary is a glossary describing each of the deliverables. 1-1-7 Revision History
|