IT Project Support - How long after delivery should you be on short dial?
In a blaze of glory, the fantastic piece of software you've been working hard on is introduced to your client organisation. The system goes live without a hitch - you are an IT delivery expert, after all. Each and every requirement is delivered, the project is on-time and within budget. Customer training was well received, and the application is quickly in daily use delivering business value. In short, a job well done – you crack open the champagne and then move on to your next IT Project with the cheers ringing in your ears.
Fast forward six months, it's a different story. The shine has worn off, the customer is unhappy, and the previously stable system is now the most hated application in the department.
What happened? Because this does happen!
In most cases where IT Projects go from hero to zero soon after delivery, it is because of a lack of adequate support.
“Each time a query has to be raised the support desk simply do not know what to do with the application and tickets remained unresolved – they don’t who to call!” This is actual feedback I read on an IT project just five months after delivery. End users were forced to create elaborate workarounds. Confidence was lost.
This is how reputations are ruined.
Organisations support their applications differently and IT project teams can address this by reframing the post-delivery landscape and working on the basics of a support service. So, for how long should you support your project?
I remember once, during onboarding, a former colleague asking new recruits, "When do YOU think our responsibility for an IT Project ends?"
The ink would hardly be dry on their freshly minted certificates and the theory would be fresh in their head so almost all would answer that responsibility ended on, or shortly after, delivery.
My colleague would mimic that sound the Mr Babbage computer emitted on Family Fortunes when a contestant gave a wrong answer.
Some would then consider that responsibility might last into a settling in period, or perhaps until customer or end-user training was completed. Again, my colleague would make that iconic television show sound and then smile.
"It never ends," he'd say, adding, "we are responsible for our IT Projects until the day they are superseded."
His thinking was that as long as the application was live, those responsible for developing it should be available to answer questions about it. To be clear, he wasn't advocating 24-7 support or calls from a client at 10 pm on a Sunday night, but he was adamant that having unleashed a solution onto the world, we should at least be answerable for its future behaviour.
Whether it is the handy person fixing the printer, super users you've trained up or an outsourced support desk, all will eventually have one central question: if I can’t work out what to do, who do I call? Who do you think your IT Project end users should be calling? Ghostbusters?
The next question, after who will help, is usually how quickly will they help me? This can become a nice metric by which to be measured. In my experience, most issues can be resolved really quickly and teams that have processes in place to accommodate support questions can quickly raise their profile and become organisational heroes. As long as it doesn’t derail the daily tasks!
IT Projects are our babies, and while some us feel an ongoing instinct to support them, many IT Project teams shut the door once they have flown the nest. It's understandable because, to be fair, there never seem to be enough hours in the day for the work you have scheduled let alone an old project coming back to haunt you.
However, being there in a support capacity builds great relationships.
The thing is, you never know when you might need the good will that you bank by being the one to call upon in a crisis. Your next project may hit some roadblocks and when you need stakeholders to cut you some slack, they are more likely to do so if they remember how grateful they were that you were there in their hour of need.
The third question, asked by end users, is likely to be ‘who else needs to know that we are in a pickle?’
Who does need to know? Put yourself in your end user’s position. They can't do their job one day or their productivity is reduced because of YOUR IT Project, they won't hide this and hope no-one notices - they'll tell their boss. Now put yourself in the boss's shoes. She oversees a team of end users and their IT issues are denting her department's targets - what does she do? When IT isn't performing it quickly shows up on board level radars.
IT is at the strategic heart of business now and with this increased prominence comes increased responsibility. Many are arguing that the lifecycle of a project, that once spanned from initiation to delivery, now extends into the operational period. It is here, when end users are manifesting your project's business value, that they need your support more than ever.
Finally, here's an exciting thought. One of my project manager friends has identified this as a whole new service offer. "Like offering an extended warranty on a toaster," he told me. Extended warranties always come at a premium and he has managed to negotiate extra budget for his team to provide ongoing support beyond what would have previously been expected of his team. Rather than seeing support as a problem or a distraction from his schedule he has creatively negotiated new budget for the IT Project team.
Extra money! Now that's something worth your support!
I’d love to hear your thoughts on this, please get in touch – how far are you willing and able to support your IT Projects.