When riding your IT project cycle - do you know how or when to get off? The value of closeout
When discussing Stoneseed's Project Management as a Service (PMaaS) solutions with clients I am always intrigued by the way they manage IT projects. In almost every case, the client will walk us through some form of lifecycle, typically composing four stages that can be loosely labelled along the following lines ... initiation, planning, delivery, closure.
The terminology and the number of phases may differ slightly from client to client but, broadly speaking, most follow a similar model.
As this is a cycle, the really interesting part of the discussion for me is how this is applied to a project in real life. Crucially, how does the lifecycle map onto a project timeline? Where does a project start and finish?
In my experience, project organisations are reasonably good at defining the start point, that stage in the cycle where an idea or concept actually becomes a project.
Strangely, where many organisations are not so good is defining the endpoint.
They know how to get on and how to ride their project cycle, but many don’t know how or when to get off. This means that they either ride off into the distance (never-ending projects are becoming more common) or they lose balance and crash in a heap of twisted pedals and bent spokes.
Why?
There are usually a number of reasons that blur the view of project teams at closeout.
1 - Often resources are tight, so the project team have to quickly move onto the next project upon 'completion'.
2 - Maybe the closure phase is seen as less important than the tangible delivery, which is complete by the stage that closeout is beneficial. This can be from both the viewpoint of the project team and also the client organisation. It can be like reviewing a car journey when you've arrived at the destination. What's the point, right? But what if there was another road you could have taken? What if the motorway could have shaved an hour off the journey? What if the scenic route could have provided a more picturesque and inspiring view from your driver's seat.
3 - Attention can go AWOL! Especially after delivering a difficult project! Team members can treat closeout like a footballer might treat a post-match TV interview. That is, something that they have to do but also something that doesn't affect the result (N.B. In IT Project Management this bit of post-match analysis can totally affect the result!!!)
4 - Sometimes, a team fails to plan the closeout phase and is forced to attempt to both plan and execute this phase at the same time which can be like herding cats!
5 - Often, team members begin to leave the team before closure phase is completed due to a lack of understanding of their role in the closeout.
6 - Sometimes, the closeout phase surfaces unresolved issues, unsatisfactory deliverables or uncompleted work but the team has started to disband and so it is left to the project manager and a smaller staff to resolve issues that they themselves may not have had a hand in creating.
7 - Usually, there is a lack of ownership for this phase. It's often not seen as a 'sexy' part of Project Management, so no-one wants their name attached to it! As one PM friend puts it poetically, "My parents run a pub, their name is above the front door as you enter and not above the door to the toilets!"
... by the way, often it is a combination of these reasons that lead to this closeout step being either less effective or discarded altogether.
I am a big advocate of the closure phase, often considering it a crucial part of the actual execution phase. A time where you gather lessons learned, ensure projects are handed into BAU in a structured way, close down budgets, etc. Without this closeout phase, the project team cannot fully move onto the next project, not benefit from experiences on the project that can be used to improve moving forward. As the PMI puts it, "Failure to conduct thorough project closeout could potentially (a) put the organization at a considerable amount of risk, (b) prevent the organization from realizing the anticipated benefits from the deliverables of the project, (c) result in significant losses to the organization, and (d) undermine the project manager and project management team's credibility."
I believe that the closure phase is becoming increasingly even more important.
Historically, the closeout phase was the time where all aspects of the project would be agreed to be concluded to the satisfaction of your client or senior management. After closeout, key team members would leave so this would be a valuable last chance to learn together. The project manager’s role in this closure phase was to ensure that all facets of the project were properly concluded. Also, at the end of a project team members can sometimes lose focus and discipline (after all you've delivered the project) so it would the PM's job to help the team retain its attention for these final (important) activities.
In reality, all too often, the closure phase is considered a tick box exercise which is undertaken at some point long after the cut and thrust of project delivery has become a distant memory. That needs to change. Not just because it is a sensible stage of any project delivery but because I believe that the project timeline is changing – it is getting longer.
In a recent blog I talked about the importance of ‘Marrying IT Strategy and Projects’, we focused on the need to define outcomes and how a business case helps with this alignment. In that article we highlighted the definition of a business case as “justification for pursuing a course of action in an organizational context to meet stated organizational objectives or goals.” the words to focus on, are organisational objectives and goals. In other words, the principal reason for any project is that they help to meet the goals of the organisation, seems sensible enough, doesn’t it?
There is a challenge here though and it is all down to when project benefits are typically realised. Moreover, this tends to be long term. Consider an ERP implementation that is undertaken to improve efficiency and information availability, at what point are these benefits realised and at ....