Tools and Documentation

The correct answer is to establish verification criteria for issue closure that confirms the underlying problem is sustainably resolved before changing status.

This is the best practice because it addresses the root cause of Jennifer's problem. The issue was prematurely closed when a temporary fix (hiring a contractor) was implemented, but there was no verification that the solution would be sustainable. By establishing clear closure criteria that require confirmation of a lasting resolution, project managers can prevent issues from being marked as resolved when only temporary measures have been taken.

The other options are less effective for the following reasons:

Creating a separate tracking document for resolved issues adds administrative overhead and complexity. This approach treats the symptom (needing to track recurrences) rather than the cause (premature closure). Good issue management should prevent premature closure in the first place, not just monitor for failures afterward.

Requiring stakeholder sign-off on all issue resolutions creates unnecessary bureaucracy and could significantly slow down issue management. Not every issue warrants stakeholder involvement in closure decisions, and this approach shifts responsibility away from the project manager without addressing the core problem of inadequate resolution verification.

Implementing a mandatory ten-day waiting period is an arbitrary timeframe that doesn't address whether a resolution is actually sustainable. Some issues may be genuinely resolved in one day, while others might need longer verification periods. A blanket waiting period doesn't account for the nature of different issues and could delay legitimate closures while still not catching problems that emerge after the waiting period ends.

In a Cumulative Flow Diagram (CFD), the vertical distance between the top band (Backlog) and the bottom band (Deployed) represents the total Work-in-Progress (WIP) in the system at any given point in time.

The scenario describes:
- Items entering the Backlog at a consistent rate (steady input)
- Development and Testing bands with parallel edges and steady thickness (stable processing in those stages)
- Deployed band maintaining a constant upward slope (consistent completion rate)
- BUT the total vertical distance is growing each week

This growing vertical distance is the key indicator. Even though the Deployed band shows a constant slope (meaning items ARE being completed), the fact that the overall distance is expanding means that work is accumulating in the system. The arrival rate exceeds the departure rate, causing WIP to build up.

The second option is incorrect because a balanced arrival and departure rate would result in constant vertical distance over time, not a growing one. If input equals output, WIP remains stable.

The third option is incorrect because the pattern described shows systemic accumulation, not a temporary constraint in testing. The parallel edges in Development and Testing actually suggest those stages are stable, not experiencing resource issues.

The fourth option is incorrect because if deployment were simply taking longer while maintaining the same throughput, the Deployed band's slope would be unchanged (which it is), but this wouldn't explain the growing total WIP. The issue is about input exceeding output capacity, not about deployment rigor.

The primary function of a change log in project documentation is to provide a chronological record of all modifications requested and their disposition throughout the project lifecycle.

A change log serves as a historical tracking document that captures:
- What changes were requested
- When they were requested
- Who requested them
- The current status of each change (pending, approved, rejected, implemented)
- The final disposition of each change request

This chronological documentation creates transparency and accountability throughout the project, allowing team members and stakeholders to understand the evolution of the project and trace decisions made over time.

The other answers describe functions that may be related to change management but are not the primary purpose of a change log:

One option describes a decision-making tool that ranks modifications by business value and resource requirements. While change management processes do evaluate these factors, this is the function of a change evaluation or impact analysis process, not the change log itself. The change log records decisions, it doesn't make them.

Another option focuses on version control for deliverables and technical specifications. While version control is important, it is typically handled by separate version control systems or configuration management tools. The change log tracks change requests, not detailed version histories of documents.

The final option emphasizes budget reallocations and cost adjustments. While a change log may reference financial impacts, maintaining a comprehensive audit trail of budget information is primarily the function of financial tracking systems or cost management logs, not the change log's core purpose.