CHAPTER 14: THE CREATE PHASE
14.1 Summary
The purpose of the Create phase is to create and develop products and confirm they meet the client’s quality expectations and acceptance criteria. The production of the products within budget, schedule and to the required quality, must be driven by the project manager and requires careful monitoring and control.
Figure 14.1: The Create phase
In summary, the purposes of the Create phase are to:
Allocate the work to be done;
•Carry out the work;
•Check the quality of the work;
•Obtain sign-off for the various products;
•Deliver the completed work;
•Keep an eye on risks and issues;
•Monitor tolerance levels; and
•Report on progress.
14.2 Allocate a work package
Work packages are allocated to a team leader or team member based on the needs of the schedule. Work should not start without the permission and authority of the project manager, otherwise it would be very difficult to keep control.
The recipient of the work package must agree with the targets and constraints before the allocation can be considered complete.
The project manager must control the sequence of work packages according to the logical order in which the products need to be created. For example, we don’t want to start building the house before we have laid the foundations! The project manager must know what those working on the project are doing, and that the schedule correctly reflects the work and progress.
The project manager will:
•Review the schedule to confirm what work needs to be done, and the time, budget and tolerances available for each work package;
•Discuss each work package with the team leader or team member (recipient) that will carry out the work;
•Ensure the recipient understands the controls to be employed and the quality standards to be met;
•Jointly assess with the recipient any risks or problems and modify the work package and action log as necessary;
•Ensure that any required training material for the users is included as part of the work package;
•Gain agreement with the recipient on work package targets and constraints;
•Allocate and authorise the work to be done; and
•Update the schedule with any adjustments made as part of the agreement.
14.3 Implement a work package
The team member or team leader will carry out the work defined in the work package, including:
•Sharing information with any persons or group defined in the work package;
•Organising and carrying out the quality checks defined in the product description(s);
•Updating the product description and records with details of the quality review results;
•Obtaining sign-off from the identified users that the product has passed its quality check; and
•Returning the completed work package to the project manager.
The work must be done within the constraints and tolerances defined in the work package. Any forecast failure to do this must be reported immediately to the project manager as a project issue (see section 14.5).
The work package may affect or be affected by one or more risks. If the risk owner (see section 7.2.4) is the same person as the one undertaking the work package, this is straightforward. Otherwise, there must be communication with whoever the risk owner is.
During implementation of a work package, the project manager will:
•Monitor the execution of the work;
•Confirm that quality inspections are correctly carried out;
•Update the status of tolerances if there has been any use of them; and
•Regularly review the status of open items in the action log.
•The daily log is a useful place to put in reminders to monitor issues and risks, check the quality of the work and any tolerance concerns.
14.4 Receive completed work packages
The delivered product is checked against the requirements of the work package and confirmation is obtained that the planned quality checks have been carried out and that the product has been signed off by the user(s).
The work package should be updated to record the acceptance of the product(s).
The project manager is responsible for recording the completion and return of work packages and updating the schedule with the results of actual time and resource usage.
As products move through their construction phases, a master copy needs to be stored away and version control used to identify the various versions (see appendix A.6 product version control).
14.5 Controlling risks and issues
A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives. An issue can be anything to do with the project, either:
•A request for change;
•A question or concern;
•A suggestion; or
•A report of a failure to achieve something that was planned.
The project manager is responsible for the control of risks and issues, although the actual work may be delegated to a team leader or team member. The action log is used to capture, log and categorise any new risks and issues and monitor the status of those that we already know about.
At any time during the project a problem may occur, a change may be requested, a risk may arise or the answer to a question may be sought. If these are missed, it may mean that the project fails to deliver what is required. There must be a procedure to capture these so that appropriate action, if any, can be taken.
The procedure for controlling risks is described in detail in chapter 7.4, but for the purpose of this chapter we will give a summary here.
For risks:
Enter the risk in the action log.
•Assess the effect of the risk on the schedule and project justification.
•Select the most suitable response and plan its implementation.
•Check the communication requirements to see who should be informed of the risk.
•Existing risks should be monitored via the risk owners and remedial action taken if required.
Again, the procedure for managing issues is described in detail in chapter 7.4, but for the purpose of this chapter we will give a summary here.
For issues:
•Enter the issue in the action log.
•Send acknowledgement to the originator of the issue.
•Assess the type, severity and priority of the issue.
•Assess the impact on the schedule, tolerances and project justification.
•Decide on the action to take – accept, reject or pass to the client for a decision.
If an issue is accepted, the schedule and relevant work package with the work required to implement the issue are updated.
14.6 Create a problem report
Reacting to risks and issues will often have an impact on the schedule, such as the time, cost or quality agreed between the client and project manager. If a deviation outside one or more of the tolerance levels is forecast, a problem report should be sent to the client. The project manager is responsible for raising problem reports.
Part of applying the progress control and change principles is that the project manager will bring to the immediate attention of the client anything that can be forecast to drive the plan beyond the agreed tolerance limits. This allows the client to stay in overall control of the project. (We have to remember here that the client owns the project justification and therefore, is ultimately responsible for the success (or failure) of the project.)
Using a problem report to escalate issues and risks that threaten tolerances should not be seen as a failure. The client will welcome warnings of potential problems far more than being informed of a situation after the disaster has occurred.
On reviewing the action log and identifying any risks or issues that threaten to exceed tolerance limits, the actions needed to raise a problem report are:
•Check the recommended response to the risk or issue for its impact on the schedule and project justification;
•Revise the recommended response if any problems are found in it;
•Describe the situation, options considered and recommended response to the client in a problem report;
•Check for any stakeholders who should also receive a copy of the report; and
•Take the appropriate action in response to the client’s decision, usually an update to the schedule and a new or updated work package. The action taken may require extra monitoring points and perhaps additional reporting on the progress of the actions.
14.7 Report progress
There should be a progress report at the end of the phase (see appendix A.7). The project manager reports on the performance of work so far, including the status of the project, project justification, risks and issues. This is used by the client to decide whether to move to the Close phase. Depending on the length of the Create phase or, for example, where there is a high-risk work package, the client may request extra progress reports during the phase.
This also allows a review of the status of the project justification. If there is a need, the project manager at this time should update the schedule with the Close phase activities for inclusion in the progress report.
14.8 How the principles contribute to the Create phase
The project justification principle is used to monitor progress against the expected benefits. Watch for any impact on the post-project review plan and contribute to the assessment of change requests and off-specifications.
Most of the work on the quality of the products is done in this phase. The quality principle affects the product descriptions and work package details. Every product is subject to a quality review.
The planning principle is used where the project plan needs to be updated, especially if it is updated to include a new or revised product following a successful change request.
As the phase name suggests, this is where the creation work is done. Team members need to take instruction, work with other team members, users and stakeholders, and participate in checking the quality of work done. This requires each team member to understand their own role, the role of other members and where authority lies. The project team principle provides this information and structure.
The risk principle is available throughout the phase where new risks are identified or known risks change and require assessment. This is the main phase where risk owners monitor their given risks.
This may be the only phase big enough to warrant the need for progress reports. The progress control principle covers this and any other communication needs.
The Create phase is where most change requests and off-specifications will appear and is therefore the phase where the change principle will be most used.