A CIO asked me this recently because his team were expressing an interest in extending their role so that they could assess their project \u201cfrom the other side.\u201d\nTraditionally, as a project manager you declared \u201cjob done\u201d when a project transitioned into service. One project manager 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.\nValue used to be measured in terms of hitting the target, deadline and budget. However, now it\u2019s 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 \u2013 and who better be part of that than the people who know the project and its business case better than anyone.\nSo, 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.\nConsidering this evolution, it is easy to plot how we got to where we are now.\nMany 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.\nAs with all progress, there are positives and negative consequences. Glass half full, let\u2019s start with the positives:\nPositive\u00a0consequence: Better ownership\nWhen 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\u2019s be honest, you were just glad to see the back of the project \u2013 especially if things didn\u2019t go to plan.\nIn 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.\nPositive\u00a0consequence: Better success metrics\nObjective, 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\u2019s a bit like having your car MOT\u2019d (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.\nOver the years I\u2019ve 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.\nExtending the project manager\u2019s 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, number of customer enquiries dealt with per hour, end-user satisfaction, real-time transparency, revenues, market share, etc, etc.\nThe beauty of these kind 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.\nPositive\u00a0consequence:\u00a0Better initiation\nEveryone is pushing this forward.\nProject 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\u2019s in their interest. Meanwhile, businesses enjoying greater and more commercially measurable returns are providing project teams with better initiation briefs. It\u2019s serendipity! The more stakeholders enjoy this \u201cunintended consequence\u201d the more spade work they want to do to achieve it.\nSo, what about any negatives? And, more positively, what solutions have CIOs found to these challenges?\nNegative consequence: Talent shortages\nI suppose it\u2019s 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 onto 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.\nSolutions? 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\u2019s continued involvement is an expensive luxury if the project transitions smoothly and as planned.\nOther CIOs have accessed services, teams, tools and individuals from the Project Management as a Service market creating an almost infinite portfolio capacity.\nNegative\u00a0consequence:\u00a0Skills shortages\nIt turns out that some of the skills needed post-transition are different to those needed before delivery. For example:\n\nLive projects return different data and usually more of it than projects in \u201claboratory conditions.\u201d 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 \u2013 otherwise, what\u2019s 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.\nA 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 \u201cjust wasn\u2019t getting the new system\u201d. 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.\n\nNegative consequence:\u00a0Costs\nFollowing 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\u2019s 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\u2019t 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.\nIt\u2019s a valuable lesson to be learned. I\u2019ve 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\u2019ve 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\u2019s 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 \u2013 one of the pioneers of the innovation compared the dressing down he got for unbudgeted post-delivery project work to this movie moment.\nIn 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\u2019m amazed that Post Delivery as a Service isn\u2019t a thing yet. PDaaS! Now there\u2019s a thought.