Recently, I wrote two posts discussing why IT Projects take a long time: one on the Procurement Process and one about Project Implementations. They were written during a time of three simultaneous projects, and they were therapy for me to exorcise some complaints... and make suggestions for others. From the start, I planned those as two topics – and I thought they'd finish the series.
But this third part was a surprise, and the greatest lesson I learned from those projects.
“It ain’t over till it’s over” - Yogi Berra on baseball, not IT projects.
******************************************************************************Disclaimer: All of the ideas expressed in this article are my personal statements and opinions, and do not reflect the opinions/statements of the City of Urbana.
******************************************************************************
Trick Question: When is a software project over?
Answer: Never.By “over” I mean the software is unchanging (“steady state” or “unpatched” – according to your point of view), and people who use the system are doing the same actions all of the time.
One reason it’s never over is that vendor software will always have updates to apply, test, and roll out. Another reason is that business needs change over time, so even homegrown solutions must evolve. In my time as a City IT Director, the only situation I’ve seen where you can say “it’s over” was when the software company went out of business. (In that case, it IS over, and you better start looking for a new system.)
In life, but especially in IT, there’s nothing but constant change. The most successful approach is to embrace that, and work with it. With software implementations that means tweaking screens, simplifying forms, and continuing to adapt the software to the people. Happily, improving the software also helps the people to adapt to the new system.
Here’s the big lesson I’ve learned from our recent projects: the best time to make these improvements is in the first 6 months after you “go live” (start using the new software).
This is frustrating because there’s a natural desire to step off the gas once the project goes live. Everyone has just slogged through a very difficult process and spent excessive amounts of time preparing for the new software (while still doing their regular jobs…) and they deserve a break. Also, if there were vendor staff who were on-site for the project, this is the point where they start leaving.
So why is the time immediately after “Go Live” the best time? Lots of reasons:
- From daily use, your people will find the inefficiencies they didn’t detect during testing, or will think of data fields and processes they didn't ask for initially. You need to channel that frustration and find improvements, otherwise it will lead to disillusionment.
- It’s natural to cut scope during the project, but now’s the time to revisit items that were trimmed. You’ll have more clarity to prioritize them now; some will become more urgent, and you’ll find that others never need to be done.
- Users haven’t developed new habits yet, so nothing is etched in stone. Soon it will become the new “way we’ve always done it!”
- Your training might have included how to configure the system – this is a good time to apply those skills before you forget them entirely.
- You still may have access to your project team. Even if you don’t, you can develop a relationship with the support team, because the first year’s maintenance is usually built into the price.
The Bad News, with Several Analogies
Question: After the long hard struggle to bring a project to the go-live date, how do you keep the project momentum going for this tweaking phase after go-live?Answer: By refocusing on the original point of the IT project. (It was to help people use technology to do their jobs better, right?) You've come this far, might as well go all the way.
Look, it takes time to get things right, and your first attempt isn’t always going to achieve everything you hoped. Leonardo Da Vinci used to work on his paintings for years, tweaking and improving. (He carried around the Mona Lisa for almost 15 years doing this, to say nothing of his many unfinished paintings.) So take the long view on these projects – it’s an ongoing process. Like flossing, it's hard and you should do it regularly.
Ouch! So we have to keep working on the implementation... forever? Yes, and moving forward, try to keep this attitude in place with upgrades, also. Upgrades fix issues and provide new features, so embrace change and patch often. (Quick tangent: New features might help address some of your pain points, but you can’t take advantage if you don’t know about them! Read the release notes. As someone who’s written release notes in my past career… if they’re good then by reading them you’ve justified the effort that someone put into them (say a quick mental “thank you” to them) and if they’re bad, then give the company feedback - for the sake of all of their customers.)
Here’s one final analogy. Have you ever spent several hours hand-washing a car, then watched your effort dry into dull, streaky smudges? Do you know what you didn’t do? Wax it. Yep, now that you’ve spent all that effort washing your car, you need to go over every inch of the body again, waxing it. But even wiping on the wax isn’t enough – in fact during the time you’re applying the wax, it looks even worse than before! (What the hell were you thinking smearing that stuff on? In the IT analogy: what the hell were you thinking changing the entry screen and breaking it?) But then you start buffing that wax, and with significant effort you produce a luminescent shine. It takes more work, but your car looks awesome!
To quote another American folk hero: