• Stakeholders are dissatisfied with IT’s inability to meet or even provide consistent, accurate estimates. The business’s trust in IT erodes every time a project is late, lost, or unable to start.
• Team morale suffers from changing priorities, cancelled and delayed projects, and the repeated need to go back and rework (caused by poor quality code, poor requirements, poor design, etc.).
• Even when projects are executed in a satisfactory manner, that is according to plan, it can be difficult to mark or define project closure.

Our Advice

Critical Insight

• Project closure begins with intake. Having a clear understanding of what makes a project complete will demand more careful consideration of requirements during planning.
• Identify clearly measurable benefits. Force your sponsor to think about and document what makes this project successful upfront and define what that data will look like.
• Plan for adoption monitoring. Don’t throw your project over the fence when it’s delivered. Make training and adoption monitoring a part of the project plan.

Impact and Result

• Define project closure during initiation and planning. If you leave closure criteria as an afterthought, you are likely to stumble through it.
• Make project closure a portfolio activity. Crispness around project closure is required for anyone to measure benefits attainment.
• Make project closure practical and tactical. We start current and common problems. We map out processes to find weakness and then identify the closure points that need to be defined.