 |
| Photo Credit: Reuters/Robert Pratta |
“Going Live” is the culmination of an IT project – the moment when people start using the new IT tool instead of their prior process. (It’s the culmination, but not the END of the project… see part three of this series). Going Live is what you worked all those months to achieve - yet it feels less like sweet relief and more like a final exam that you might not be ready for.
We’ve recently Gone Live on two major projects and this piece contains some reflections both from these projects and from my prior career, when I spent 20 years working on government software implementations from the vendor side.
*********************************************************************
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.
*********************************************************************
Stepping Out onto a Glass Floor
Going Live can be a knee-buckling experience, which is why I chose the image above. You’ve supposedly built the infrastructure to support yourself, but when you look down you see nothing but a plummet. How do you know you built the infrastructure strong enough? (*ahem*… testing) There’s always trepidation that you haven’t considered every angle and that you’ll have that hyper-drive moment when you flip the switch, but it sputters and fails.
In government, the desire to avoid problems causes many Go Live dates to be pushed back. This is yet another reason why government IT projects take a long time – the point of this whole series of blogs. As Part Two of this series discussed, the Iron Triangle of project management dictates that you can have only 2 out of 3 of the following: cheap, good, and fast. As that piece explained: in government quality is essential because our systems impact life safety - and we don’t have the luxury of second attempts. Ultimately, our choices come down to cost vs. time – and in most cases budgets are fixed, so timelines are usually what gives way. (Note #1 – notes at the bottom.)
However, pushing back a deadline has problems, too. One is that you’re extending the drain on the project team’s time and energy. Maybe those people were planning to work on something else next, or they need some well-deserved downtime after a grueling project. Another cost is financial; delays could cause you to maintain two systems simultaneously. (We recently had to pay for an extra month of duplicate phone service due to a delay in our transfer of phone numbers.) There’s also a chance that your users lose confidence in the new system, just based on the perception that a moved deadline means there are problems.
The Zone of Frustration
In fact, there are MANY ways for a Go Live to have problems, and I’d like to emphasize that it’s normal for there to be issues. You need to be comfortable with the fact that problems will occur, and you need to plan for a post-implementation phase when you triage and address them.
You should also set expectations with your user community (and their management!) about the impact of the new system. The key is this: immediately after Go Live there will be a difficult time while people get used to the new process and issues shake out and get resolved. Early in my career, a project manager drew this picture, and I’ve been using it ever since. (I don’t know if he made it up, but I always give him credit. Thank you, Abdul!)
In this picture, the blue dashed line represents the productivity of the users before the new system. It doesn’t matter how high or low the line is, the key is that it’s horizontal… people were working at a steady level of effectiveness.
Notice that immediately after Go Live, productivity is LOWER than before. That reflects the awkward initial period – it’s suddenly harder for people to do their jobs. However, the line has an upwards slope because people will learn the new system, issues will be resolved, and some of the functionality you postponed during the project will be built. (Note #2) At some point, productivity moves past the old level – hopefully far beyond it – before it plateaus as the new system becomes normal practice.
That initial period when productivity is lower forms a Zone of Frustration. During this time, it’s harder for people to do their jobs and they’re not seeing the benefits of change. This can be a difficult time if expectations are not set properly. (Actually, it’s difficult even if they ARE set!) The key is the slope of the line. You want to avoid the slow increase, which only lengthens the phase and increases frustration. It’s even possible for projects to stall at this late phase, and be shelved as a wasted effort. Your goal should be to collaborate with your users to steepen the slope, working through this phase quickly.
Rollout Strategies: Big Bang or Early Adopters?
When planning a project, a key question is how you’ll Go Live. My two recent projects used different strategies for different reasons, so I’ll use those to differentiate.
A “Big Bang” Go Live means everyone switches to the new system at the same time. Our phone changeover was like that because we didn’t want to have an awkward mix of phone numbers on two separate systems. One problem with a Big Bang is that delays hold up everyone. We had that challenge: for one of our three accounts the prior telecom company had been bought and sold several times, so no one at the current company had the original account numbers and PINs we needed to transfer lines! This means that we had to hold up the switch for about four weeks, incurring that month of duplicate costs mentioned earlier.
Big Bang rollouts are appropriate, and often necessary, for infrastructure like phones and building security systems, but can be unnecessarily traumatic due to the hard cut-over. Support after Go Live is harder, also, because all users need assistance at the same time.
The alternative to a Big Bang is a phased rollout, where groups of early adopters get the new solution first and help you shake out issues and improve your training and documentation for later groups. Because rollout is phased, the project team must spend more time overall on post-Go Live support, but the rollout is smoother for those who follow the early adopters. Besides phasing a rollout to groups of people, you can also roll out features in waves to the same set of users.
Our other big recent project was timesheet software, and we did a phased rollout in both ways: groups of people and system features. One group of early adopters were employees with simple 40-hour workweeks, who quickly began to use the new system for basic timesheet entry and approval. Later, we introduced that set of employees to other features, like Leave Requests. Meanwhile, we worked on Police and Fire employees with complex timesheet scenarios. They required more testing (lots of rule configurations…) and we also introduced features to them gradually: starting with scheduling before we moved to capturing actual hours worked and leave requests.
Although a phased rollout will generally be more successful, it does have its costs. Phased rollouts require more overall effort: early adopters need help since the solution is not yet mature, plus you’ll need to put in effort later to support everyone else. It also drags out timelines, so you’re spending more time in the difficult pre/post Go Live period.
A final risk of the phased rollout manifested itself for us with the timesheet software: because phasing creates a series of Go Live dates, you lack a crisp deadline. We continued to find issues during our early adopter testing, so we kept pushing back the dates of later phases. Depending on the vendor contract, this could cause cost overruns. (Fortunately, our project had a fixed-price implementation!)
In our case, pushing back the Go Live date sent a message to our users that we had problems. That was true, but the important point is that we found them during testing. (Note #3) Remember: there will always be problems – the question is when you find them! Worse for us was that early frustrations caused some of our users to simply quit using the new system during the testing period. This was possible because the new timesheets were only for verification - and didn’t impact actual paychecks. (Note #4)
Ultimately, this required a “burn the boats” moment. We chose a date (June 5 was the start of a biweekly pay period and a 27-day FLSA cycle – something that happens only once every 14 months) and decided we’d just deal with issues as they came up. (Note #5)
Final Thoughts - a Personal Note
Going live on two difficult projects helped me understand something about myself: a specific trigger that really frustrates me. I’d like to warn you about this in case you work with me or in case it’s something you need to prepare yourself for.
At the point of Go Live, even though the project team has spent months (or years) pouring their efforts into creating the best process possible, when the users interact with the new system all they’ll see are the flaws: features that they’re missing or extra steps the new system requires. You might hear a few compliments, but most people will be quiet if they’re happy and complain if they’re not. In other words: if you want a Go Live party, you better throw one yourselves!
Something I've learned about myself is that I’m personally sensitive to system criticism, even though I had no hand in programming the application. (I DID have a hand in selecting it, however.) I’d like to think it’s because I simply want to do a good job, but part of it is that I’m associating with the new system too much. Those are old habits I developed back when I worked for a software company - and especially when I was the Product Manager.
Although I still cling to that mindset, now I can at least distance myself one step from the solution and say, “We did the best procurement and implementation possible… and this is what we have" - and then begin the process of improving it.
Notes
Note #1: Something I wrote about in Part Two of this series (Note #2 here) was the striking difference between the Vendor side of a contract and the Client side. When I worked for a vendor, we treated Go Live dates as sacred – even if we needed a “Death March” to get there. This perspective comes from the contract, which can have penalties and possible legal action if the vendor doesn’t live up to their responsibilities. From the client side, life is different. It’s a lot easier for the client organization to suggest extending the deadline, and in government it seems to be the default response because spending more money or having a bad result are both worse outcomes than the delay.
Note #2: Please see Part Three of this series on the importance of this post-Go Live phase! It’s critical that you continue to improve the system and the surrounding process (procedures, training, documentation, etc.) based on user feedback. Not only does it improve the system, but it also shows your users that you care about their input. Since they’re the ones using it in real life, they’ll have the best ideas.
Note #3: I began my IT career as a system tester, and I’ve maintained a faith in testing ever since. With today’s off-the-shelf systems, you’re testing the configuration more than you’re testing the programmed software itself. Every problem you find (and fix) during testing is a victory; it’s a problem that you’ve avoided in production. Our testing process for the timesheets was something I’ve never tried before: we were trying to test our full timesheet/payroll process with completely parallel entries in the new and old systems. For employees with simple timekeeping this wasn’t a burden, and we soon had them using ONLY the new system. The problems we had were our Police and Fire workers with complex needs… asking them to do both methods for several months wound up creating such a burden that people lost enthusiasm and stopped doing both. (See Note #4)
Note #4: And this leads back to the topic of momentum, which I wrote about in my last two entries in this series. Part four of this series addressed creating momentum and part five pondered guiding it.
Note #5: Notice that I’m writing this post AFTER we went live, and even though I’d written parts of this blog before June 5, I didn’t begin to write about the timesheet Go Live until after that date. IT people might be logical, but we’re still superstitious! That’s why we keep an old wooden blackboard eraser in our IT section, just in case anyone needs to knock it after making a statement like “that server’s doing great!”