Starting up a Project (SU)
MP Managing product
13.3 RECEIVE COMPLETED WORK PACKAGES 1 What does the activity do?
• Records the completion and return of approved Work Packages. 13.3.2 Why?
Where work has been recorded as approved to a team or individual, there should be a matching activity to record the return of the com - pleted product and its acceptance (or otherwise).
13.3.3 How?
• Check the delivery against the requirements of the Work Package. • Check that any quality activities have been completed satis -
factorily.
• Check that the recipients have accepted the products. • Ensure that the delivered products have been baselined. • Document any relevant team member appraisal information. • Pass information about completion to update the Stage Plan. 13.3.4 Information needs
See Table 13.3. 13.3.5 In practice
13.3.6 For small projects
The formality of this activity will relate to the formality of the activity Authorize a Work Package. Both will often be informal and brief. 13.4 CAPTURE AND EXAMINE ISSUES AND RISKS
For issues:
13.4.1 What does the activity do?
• Makes a note in the Daily Log of any issues that can be dealt with by the Project Manager informally.
• Captures, log and categorizes new Issue Reports.
• Analyses each new Issue Report and recommends a course of action.
• Reviews each open Issue Report for any changes to its circum - stances or impact and potentially makes a new recommendation. • Reviews all open Issue Reports for any impact on the project risks
or the Business Case. 13.4.2 Why?
At any time during the project a problem may occur, a change may be requested 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. Alternatively the project may run into some other trouble that could
TABLE 13.3
Management Usage Explanation information
Completed Work Input Check delivery. Package
Quality Register Input Check for satisfactory quality results. Stage Plan Update Work Package completion.
Configuration Update Status. Item Records
have been foreseen had the issue been noted at the time it arose. There must be a process to capture these so that they can be presented for the appropriate decision and response.
Having captured all issues, these should be examined for impact. 13.4.3 How?
• Ensure that all possible sources of issues are being monitored. • Enter new issues on the Issue Register.
• Assemble all pertinent information about the issue.
• Carry out impact analysis on the technical effort required to resolve the issue.
• Update the Risk Register if the issue reveals a new risk or a change to a known risk.
• Assess whether the issue or its resolution would impact the Business Case.
• Prepare a recommended course of action.
• Update the Issue Register with the impact analysis result. For risks:
13.4.4 What does the activity do? • Enters the risk in the Risk Register. • Assesses the risk.
13.4.5 Why?
Like an issue, a risk may arise at any time. The situation should be monitored constantly for new risks and for changes in existing risks. 13.4.6 How?
• Ensure that all possible sources of risk are being monitored. • Enter new risks on the Risk Register.
• Perform risk analysis on the risk.
• Assess whether a new risk or its resolution would impact the Stage Plan, Project Plan and/or Business Case.
• Review existing risks for any change. • Plan selected responses.
• Check the Risk Management Strategy and Communication Man - age ment Strategy for any reporting needs.
13.4.7 Information needs
TABLE 13.4
Management Usage Explanation information
Stage Plan Input Assess the impact of new issues or risks. Project Plan Input Assess the impact of new issues or risks. Business Case Input Assess the impact of new issues or risks. Configuration Input Details of the change control procedure
Management and reporting.
Strategy
Communication Input Reporting needs. Management
Strategy
Daily Log Update Add any issues which can be handled informally.
Issue Report Create Issue that needs to be handled formally. Issue Register Update New formal issues.
Risk Register Update New risks.
13.4.8 In practice
The Project Manager may ask a Team Manager or team member to carry out the analysis, depending on the expertise required. It will be necessary to analyse the financial impact as well as the technical impact. It is part of the Project Assurance role of the Executive to review this. Thought should be given to the time required to do this analysis when designing the project management team, or at least the Executive’s Project Assurance role. When producing Stage or Team Plans, an allowance should always be made for the time that the senior
specialist people are likely to spend in performing impact analysis on project issues. Thought should be given to the likely volume of issues. Possible responses to issues or risks are to Take corrective action, seek advice from the Project Board or raise an Exception Report in the activity Escalate issues and risks (see section 13.8), part of the Controlling a Stage process. Before taking any of these actions, the Project Manager should run through the Review stage status activity (see section 13.5) in the Controlling a Stage process in order to understand the full situation.
A check should be made to ensure that the procedure covers not only requests to change the specification but also potential failure to meet the specification; potential deviations from objectives or plans; and questions about aspects of the project which require answers. 13.4.9 For small projects
Requests for change or failures on the part of the supplier still need to be documented as part of the audit trail of the project.
The Project Manager may be able to carry out impact analysis as soon as the Issue Report or risk is presented and get a decision on the action to take. Thus, in practice, it may be possible to combine the capture and examination processes with the taking of corrective action or the escalation of the Issue Report to the Project Board for a decision. 13.5 REVIEW STAGE STATUS
13.5.1 What does the activity do?
• Provides a regular reassessment of the status of the stage. • Triggers new work.
• Triggers corrective action for any problems. • Provides the information for progress reporting. 13.5.2 Why?
It is better to check the status of a stage on a regular basis and take action to avoid potential problems than have problems come as a surprise and then have to react to them.
13.5.3 How?
• Review Checkpoint Reports. • Check the status of quality checks. • Review progress against the Stage Plan.
• Where useful, request a Product Status Account to verify that records and actual progress match.
• Review resource and money expenditure.
• Review the impact of any implemented issues on Stage and Project Plans.
• Assess if the stage and project will remain within tolerances. • Check the continuing validity of the Business Case.
• Check for changes in the status of any risks.
• Check for any changes that are external to the project but that may impact on it.
13.5.4 Information needs
TABLE 13.5
Management Usage Explanation information
Quality Register Input Status of quality work.
Product Status Input Any variation between planned and
Account actual progress.
Issue Register Input Status. Risk Register Input Status.
Checkpoint Reports Input Status of Work Packages. Business Case Input Impact of any issues and risks. Project Plan Input Impact of any issues and risks. Benefits Review Input Any benefits due?
Plan
Stage Plan Update Review status and update from forecast. Lessons Log Update New lessons.
Issue Register Update New or modified issues. Risk Register Update New or modified risks.
13.5.5 In practice
The activity should be viewed as one that is happening continuously throughout a stage, rather than one that is done, for example, every two weeks. Each activity may not need to be daily, but the Project Manager should ensure that there are sufficient monitoring points (and people allocated to do them) to keep a continuous check. This does not mean that there should always be an instant change of plan in reaction to each slight deviation, but rather an extra monitoring point that would produce a forecast of the potential impact if the situation were to get worse, and a tolerance setting at which to trigger remedial work.
A change that affects the Business Case or the risk situation may come at any time. As well as trying to identify such a change as it occurs, it is useful to review the assumptions on which the Business Case and risks are based on a formal and regular basis.
The Project Manager may seek guidance on any issue from the Project Board, and should always do so if there is a threat to the stage or project tolerances.
13.5.6 For small projects
These activities are still required. The Project Manager should make a decision about their frequency according to the project situation and environment.
13.6 REPORT HIGHLIGHTS