Read and subscribe to Stoneseed's Latest Blogs
Read and subscribe to Stoneseed's Latest Blogs
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.
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 what point can they realistically be measured? The answer often is at 'some point' long after the project is ‘officially’ considered complete. It is only when new technology becomes embedded (which takes time) that the true benefits are seen within the organisation.
I believe therefore that, as strategy and project delivery become more aligned, the focus on benefits and their realisation (both short and long-term) will remain with the project team. The natural consequence of this is an extending of the delivery and/or closure phases. Project teams will own the benefits realisation and, as this will not become clear until 'some point' after implementation, the time that a project team needs to be available to work on a project is stretched along the timeline, adding further pressure to over utilised resources.
This is where Project Management as a Service comes in.
Transition into service is the part of the process where project managers report the greatest 'value leak' - to return to that football analogy from earlier it's like setting up the perfect goal only for the striker to squander the chance by blasting the ball over the bar! You probably have tight governance throughout the project life cycle, but how well you finish your project? It is key to leveraging maximum business value! How well defined are your processes that move your project into BAU? Is your service delivery capability geared up to maintain the project deliverables? Through Service Delivery Assessments we are often surprised at how otherwise clued up clients are leaving this to chance - even the most capable project teams often find there is huge value in 'buying in' delivery management services.
The solution to literally every issue we have discussed here (and many others that we didn't have space to cover) can be found when you work with the right PMaaS partner. As project timelines become more stretched it is increasingly important that project teams find innovative ways to resource them. As projects become more complex and business case aligned, and as realisation of benefits becomes more of a future event it has never been more important to define endpoints and measure success in terms of actual business gains - no matter how long after delivery they come to fruition.