Thinking of project closure as the final activity or capstone of a project is ignoring what the rest of the organization views as the most critical component: the benefits. When you take a step back and look at a view of the entire project lifecycle – to the point that makes any difference to the business, it is the “keystone” or the central event that project success ultimately relies on.
The challenge is often that stakeholders are dissatisfied with IT’s inability to meet or even provide consistent, accurate estimates. As a result, the business’ trust in IT erodes every time a project is late, lost, or unable to start.
Internally, team morale suffers from changing priorities, canceled 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, i.e. according to plan, it can be difficult to mark or define project closure.
In this webinar we will review how to:
- 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.