Originally published on CIO.com
Traditionally a project is judged complete when it is transitioned into service. Maybe it’s time to re-evaluate this endpoint.
A CIO asked me this recently because his team was expressing an interest in extending their role so that they could assess their project ‘from the other side’.
Traditionally, as a PM you declared “job done” when a project transitioned into service. One PM I know used to have a bottle of Moet in the fridge labelled with the project name and due date and would only pop the cork when the project was handed over to the IT service team. He used to call them handover parties and somehow that champagne would taste sweeter the harder the project had been to complete.
Value used to be measured in terms of hitting the target, deadline, and budget. However, now it’s much more return on investment (ROI) oriented. The value measurement of success has changed and is now more about the benefit delivered by the project, in other words, value that the use of the project brings to the business. The danger is that some of these measures can be ambiguous without rigorous reporting – and who better be part of that than the people who know the project and its business case better than anyone.
So, the last step used to be an evaluation review, a chance to look back over the project to see what worked well (and not so well), document what was learned and what might contribute to future project success. Back in the day, I recall this type of evaluation review would have usually been carried out just by your core project team but over time it evolved to gather feedback from the client, the sponsor, end-users, relevant stakeholders or in some cases customers of the business.
Considering this evolution, it is easy to plot how we got to where we are now.
Many project managers are now involved in a project way past the traditional hand over point to ensure that the project is embedded and delivering value to the business.
As with all progress, there are positives and negative consequences. Glass half full, let’s start with the positives.
1 – Better Ownership
When handover meant handover project teams were often seen as running straight after sign off, as if they were keen to get away from the project as quickly as they could. Being kind, this was probably because they were needed immediately (like yesterday) on the next project. Sometimes though, let’s be honest, you were just glad to see the back of the project – especially if things didn’t go to plan.
In the new era of post-handover project management, you naturally develop a greater feeling of ownership. When you are to be embedded in the project beyond delivery your perspective changes. You are less likely to make a dash for it because you will still live and breathe the outcomes of your project after delivery.
2 – Better Success Metrics
Objective, measurable success metrics have always been key to gauging success but they have historically been limited to things like delivery date and budget. While these are good metrics they only measure success up to point a project is handed over. It’s a bit like having your car MOT’d (an annual vehicle safety test in the UK), driving it hard into the wall of the test centre as you leave and thinking that the certificate still covers you.
Over the years I’ve seen many attempts to measure business alignment and ROI, some more successful than others. While they all mean well, as alluded to earlier, some are too ambiguous, vague and open to misinterpretation to be truly valuable.
Extending the project manager’s involvement timescale allows for better, more relevant success metrics to be harvested. Business returns can be measured in terms of time end users spend completing tasks, amount of system downtime, the number of customer enquiries dealt with per hour, end-user satisfaction, real-time transparency, revenues, market share, etc, etc.
The beauty of these kinds of metrics is that their benefits flow backwards in the process and overtime project teams get better at forecasting cost against intended business value and #scope creep or schedule variances against actual business environments.
3 – Better Initiation.
Everyone is pushing this forward.
Project teams who are more involved in the post-delivery phase are requesting more information about what success will look and feel like to the business. Rather than simply pass the project on they will eventually experience it as a live entity, so it’s in their interest. Meanwhile, businesses enjoying greater and more commercially measurable returns are providing project teams with better initiation briefs. It’s serendipity! The more stakeholders enjoy this “unintended consequence” the more spade work they want to do to achieve it.
So, what about any negatives? And, more positively, what solutions have CIOs found to these challenges?
1 – Talent Shortages
I suppose it’s inevitable. Imagine starting a new football game while key members of your team are still playing in the last one! As a coach, scanning the pitch, you would notice some holes in your line up. So it is with IT talent. Some CIOs report that projects are being delayed to allow IT teams time to manage their projects through delivery and into service. The traditional (ideal) model, where IT Project Managers would sign off one project and be assigned to the next one were intentionally tight. Of course, doing this means a judgement call for the CIO about whether the best interests of the business are served by talent escorting the first project into service or moving immediately onto the next.
Solutions? Some have created smart helpdesk type services whereby end users have quick access to the project team while they start and work on a new project, the thinking being that the project team’s continued involvement is an expensive luxury if the project transitions smoothly and as planned.
Other CIOs have accessed services, teams, tools and individuals from the Project Management as a Service market creating an almost infinite portfolio capacity.
2 – Skills Shortages
It turns out that some of the skills needed post-transition are different to those needed before delivery. Examples …
a) Live projects return different data and usually more of it than projects in “laboratory conditions”. To some, reading live performance metrics is a whole different ball game to reading tame ones like how well a project is progressing against a deadline date. To leverage full use of this fast moving data though, teams have to be able to read it and interpret it – otherwise, what’s the point? A couple of CIOs have introduced training programmes to address this, others have utilised external project talent who can bridge any gaps and bring these skills to the table.
b) A few CIOs have commented that some IT Project Managers lack certain soft skills that are essential for dealing with people, especially people whose working day may have changed beyond recognition due to your project. A project manager friend of mine tells the story of how awkward he felt when a staff member burst into tears because she “just wasn’t getting the new system”. He told me that he realised that pre-delivery most of your work is with things that can be fixed by turning them off and turning them back on again, doing that with people is rather frowned upon by HR so he had to learn new skills. For instance, customer or end-user training requires that you describe things in a different way to how you would to an IT project colleague.
3 – Costs
Following an IT Project into service is beneficial for so many stakeholders. Businesses and end users benefit by having access to the creator of the change that’s being implemented, project teams get valuable insight that can inspire tweaks to a live project or get paid forward into future ones. As with everything though, this resource isn’t free and someone has to pick up the tab for it. Project teams that I know who pioneered this approach tell me that cost was something of an afterthought, they were so passionate about guiding their project into life that they kind of forgot to include it in the budget.
It’s a valuable lesson to be learned. I’ve seen extended Project Manager involvement included in initial budgets (which is great because when things go a little over budget in the pre-delivery phase you have extra money in your purse to borrow from) and I’ve seen post-delivery set up almost as a stand-alone new project with its own budget and timescales. However you budget for it, be sure that you do. Remember Home Alone 2? The glory of Kevin’s achievement of staying alive in New York City and getting all those presents for his family soon vanished when his father opened the room service bill – one of the pioneers of the innovation compared the dressing down he got for unbudgeted post-delivery project work to this movie moment.
In conclusion, all in all, the positives outweigh any challenges. The Project Management as a Service is geared up to help you achieve the gains it can bring so much so that I’m amazed that Post Delivery as a Service isn’t a thing yet. PDaaS! Now there’s a thought…