Issues Practice

The correct approach for documenting this situation in an Issue Report follows PRINCE2 7 principles for issue management.

The Issue Report should:

1. Clearly describe the issue: The vendor compatibility problem with the existing database architecture should be documented as the issue description. This is a factual statement of what has occurred.

2. Assess the impact: The 4-week delay and associated cost implications must be documented in the impact assessment section. This provides the Project Board with essential information about how this issue affects time, cost, and potentially scope.

3. Present options: The Project Manager should propose multiple solutions, including the vendor's modified module option and alternative approaches. This allows the Project Board to make an informed decision based on various options rather than a single recommendation.

This approach aligns with PRINCE2's 'manage by exception' principle and ensures the Project Board has sufficient information to make decisions when tolerances may be threatened.

The second option is incorrect because it suggests recording this as a risk in the risk register. This is already an issue (it has occurred), not a risk (something that might occur). Issues and risks are managed differently in PRINCE2.

The third option is incorrect because it recommends accepting a specific solution rather than presenting options. The Project Manager should provide analysis and options but allow the Project Board to make the decision, especially when stage tolerances might be impacted.

The fourth option is incorrect because it suggests immediate escalation to the Project Board for an urgent decision. While the Project Board needs to be informed, the Project Manager should first complete the impact assessment and develop options before escalation. The issue should be managed through the proper issue management procedure, which includes thorough analysis before presenting to the Project Board.

The correct approach is to link the three issues together in the Issue Register by creating a parent issue that captures the root cause, then reference this parent issue in each of the three existing entries while maintaining their individual status tracking and closure activities.

This is the best answer because:

1. PRINCE2 7 emphasizes maintaining an accurate audit trail and documentation throughout the project lifecycle. Each issue represents a valid concern that was raised at a specific time and may need individual closure verification.

2. The Issue Register should reflect the true history of how problems emerged and were identified. Keeping the original three issues open preserves this chronology and demonstrates proper issue management evolution.

3. Creating a parent issue allows the Project Manager to address the root cause (insufficient foundation specifications) while maintaining visibility of the individual symptoms. This provides clarity on the underlying problem without losing the detail of how it manifested.

4. Each issue may require different closure activities or acceptance criteria. For example, concrete pouring delays might need sign-off from the construction supervisor, while structural concerns need approval from the structural engineer. Maintaining separate entries allows for appropriate closure governance.

5. Different team members may have already invested effort in investigating their assigned issues. Preserving these entries respects that work and allows proper tracking of resolution efforts.

The other approaches are problematic:

Consolidating into a single entry and closing the originals destroys the audit trail and removes important historical information about how the problem was discovered. It also makes it difficult to track individual closure requirements.

Escalating to the Project Board as an exception is premature and unnecessary. The Project Manager has the authority to manage issues and should only escalate if the combined issue creates an exception (threatens stage or project tolerances). Simply discovering a common root cause doesn't automatically constitute an exception requiring Board decision.

Creating a master issue with sub-components while continuing parallel investigation streams is inefficient and doesn't reflect the actual relationship between the problems. Once the root cause is identified, investigations should be coordinated rather than continued in parallel, which could lead to duplicated effort and inconsistent solutions.

The primary distinction between change budget and change authority lies in their fundamental purposes within project change control.

The change budget is a financial resource - it represents money set aside specifically for implementing approved changes during the project. This is a contingency fund allocated to cover the costs of changes that have been authorized.

The change authority, on the other hand, is about governance and decision-making. It defines the levels of authority and who has the power to approve changes at different thresholds. It establishes the delegation framework that determines which changes can be approved by the Project Manager, which require Project Board approval, and which might need escalation to corporate or programme management.

These are two complementary but distinct concepts: one is about money (change budget), the other is about decision-making power and approval authority (change authority).

Why the other answers are incorrect:

The second option incorrectly describes the change budget as covering 'all project uncertainties' rather than specifically approved changes, and confuses change authority with stage tolerance approval, which is a separate aspect of project control.

The third option reverses part of the definition by describing change authority as a 'cumulative monetary threshold' which conflates it with budget concepts rather than maintaining the clear distinction that change authority is about approval levels and governance structure, not financial thresholds.

The fourth option completely reverses the definitions, stating that change budget defines decision-making levels (which is actually the role of change authority) and that change authority is the financial allocation (which is actually the role of change budget).