Even though many will deny it, anybody who has worked in IT for any length of time will have been part of what started out as a great project, with an amazing brief, and creative team, but which ultimately, for whatever reason, was aborted. I chose the word ‘aborted’ rather than ‘failed’ because I’ve been part of projects that went swimmingly well, and delivered everything on budget and on time, but which for business reasons were not implemented.
At Icreon we have experience in picking up on projects that aren’t quite delivering and getting them over the finish line. That’s not to say it’s easy to do. In some cases it’s easier to ‘can’ a project and start afresh. It’s a difficult call to make either way, and the implications can be tricky to manage.
Below are a few hints and tips for managing the fallout from stopping a project in it’s tracks
Secure the system, code, and/or data
Simple good practice when an organisation has made a sizable investment in any kind of project is to ensure that the investment is secure. It may be that you purchased hardware or software and that you created new data or edited existing corporate data as part of the project. Make sure all this property is locked down tight and secure from any unauthorised interference.
If it’s not specifically your legal responsibility to do so, this is likely at the very least your fiduciary duty. Perhaps the project overall didn’t work, but there may be elements of the work that can be used elsewhere. If it’s your intellectual property, protect it.
You may have hired contractors to work on the projects who either won’t be turning up any more or who are being shifted to other work. Ensure that their access to the project data is revoked. Most people are responsible enough not to do anything rash, but don’t count on it.
This becomes less of an issue if you have source control and regular back-up systems in place.
Learn from mistakes
Everybody says this, but words are easy, action is hard. Emotions are bound to be high right after a project is cancelled. It might be best to wait a while before conducting the autopsy, but not so long that project myths start to entrench and take precedence over the facts.
Take it easy on the IT team
Stopping a large project is bound to send shockwaves across the organisation, but it’s important for the leadership team to lead by example and to avoid singling out the IT team.
It is often said that nobody notices what the IT team does until something goes wrong. This is never truer than when high-visibility projects get shut down. Just remember that the IT people working on that project are human, morale will be at a low ebb. Those closely involved are likely to be emotional if months or years of work has just been halted.
Communicate the plan
It’s unlikely that the underlying business issues and needs that lay behind the stopped project have suddenly gone away. You still need to move your business forward and there is now a project-sized gap in the schedules of some of your staff. Having nothing to do can sap team morale just as much as working on a project that went nowhere.
No one likes uncertainty, in particular after project meltdown. Once the leadership team has a plan that plan needs to be shared transparently with the business to avoid any confusion about where the business priorities lie. If you have superstar staff consider that they may start looking for exciting project opportunities elsewhere.
The leadership team need to take time to focus on the future. There are a number of choices to be made, not the least of which is where investment needs to be made to meet the needs of the business, and how to re-allocate project resources to where they can perform well and deliver tangible benefits.
There are no IT projects
In truth, there are no IT projects. All projects are business projects. Perhaps the IT department happen to be working on some of them, the marketing department on others, the finance department on yet others. Some projects are wildly successful, others not so much. That’s the nature of business, and so must be the nature of IT.
Good projects can turn bad, and bad projects can be salvaged, and many leadership teams know that underlying business problems still need to be solved regardless of if a particular project (in any part of the business) has stumbled. The hard part is actually deciding what’s most important to your bottom line. Is it brooding on the past, or is it charting a course into the future?
This post was originally published on icreon.co.uk
Comments are closed.