项目概念阶段结束时的检查表(EndofConceptPhaseChecklist)

申请免费试用、咨询电话：400-8352-114

What: A checklist of activities and deliverables that should be completed by the end of the Concept Phase. This checklist can be used during an end-of-phase management review. This is one of a series of end-of-phase checklists, one for each of our representative project phases.

Why: The theme of an end-of-phase management review is to ensure that sufficient work has been completed in the current project phase to allow the project to enter the next phase without an unacceptable increase in project risk. Thus the checklist is not only for what work was done in last phase but also for what foundation has been set for the work that is coming next. Projects that don’t lay a good foundation in risk reduction activities such as planning, requirements management, design and testing can become “overextended” in later project phases, increasing the schedule time, cost, and risk of the project, and decreasing the fitness for use of the project’s result. A checklist that tracks the status of key activities and deliverables in each project phase can help the team and stakeholders decide if a sufficient foundation has been laid in the current project phase to allow the project to continue into the next phase.

How: If you are at the beginning of your project, download this checklist and the other end-of-phase checklists and use them to make the general plan for the entire project. If you are in mid-project, examine the checklists of previous phases to ensure that your project is not already overextended. Try to avoid examining these end-of-phase checklists late in the project phase or on the eve of the end-of-phase project review -- they lose much of their value as a planning tool if they are not used early.

Edit these checklists to remove items that don’t apply to your particular project, and to include additional items that are key gating items in your organization’s development process. You can also adapt these checklists to your organization’s project lifecycle phases -- more on that below. Try to do this editing EARLY in your planning, when you’re not under pressure to complete a particular phase. Then hold the checklist steady both during and at the end of the phase -- resist making changes and removing items in order to have “a better review”.

Don’t be put off by the number of items on these checklists. For example, note that the term “plan” does not necessarily mean a formal document -- it means your team has done some critical thinking in the subject area and has captured the results of that thinking into a plan that specifies activities and deliverables. The plan should be in some written form so that it can be systematically applied to the project over time without complete reliance on human memory. In some organizations, you can substitute “planning” for plan and show the results implicitly in other items like schedules. Or you may have a few paragraphs each for some of these “plans”, captured in one general planning document. In other organizations, you’ll want to show a more formal written plan or other auditable evidence that you’ve done the early critical thinking about the subject area.

Start actively using each checklist EARLY in the project phase to ensure completeness of the activities and deliverables that you are trying to accomplish during the phase.

As part of the end-of-phase review, the checklist should be prepared with either a “YES” or “NO” in the “Done?” column. Items with a “NO” are “punch list” items.

The Punch List
Not all activities and deliverables may be completed at the end of a project phase. The goal of a “gating” end-of-phase management review is NOT to rigidly enforce a “waterfall” development methodology where everything must be completed, approved, and signed off before any activities in the next phase can begin. There should be overlap between phases and as much concurrency as possible without exposing the project to unacceptable risk. The point of the gating review is to examine the state of the current phase’s activities and deliverables and MEASURE THE RISK OF OVEREXTENDING THE PROJECT by moving the “center of effort” of project activities heavily into the next phase at this point in time.

If there is an activity or deliverable that has not been completed by the end-of-project review, the team and stakeholders may make a consensus decision is that there is no severe risk in allowing the project to continue into the next phase as long as the activity or deliverable is COMPLETED IN A TIMELY WAY AND SCHEDULED TO BE COMPLETED BEFORE ITS ABSENCE WOULD RAISE RISK. If this case can be made for the item, then enter a “NO in the “Done?” column and enter the item’s completion date in the “Punch List Date” column. This activity or deliverable is now considered to be on the “punch list”, a to-do list of activities that the project manager recognizes as exceptional -- a carefully controlled overextension of the project. These items must be carefully tracked to closure before the end-of-phase review can be considered complete. The project manager takes an action item from the end-of-phase review to track each item on the punch list and report the closure of each item. One mechanism for doing this is to by amending the review minutes as each punch list item is closed out. Progress on the punch list should be reported regularly and frequently. The review is not considered complete until the punch list has been cleared.

Project Phases
The project phase methodology that we use is a representative one, but by no means the only one or the best one. You don’t have to use our project phases -- you can adapt these checklists to your own development or project life-cycle methodology. For example, product development organizations might split the “Execution” phase into two distinct phases of “design” and “prototype and test”. Organizations with complex manufacturing may want to have two phases for “Delivery”. Other industries may have completely different phases. The point here is that a project lifecycle should have periodic progress reviews where the work to date is examined and the risk of continuing with the project is assessed.

To guide your use of this checklist and its possible adaptation to your own development model, we repeat here our definition of this phase of the project.