Last Friday, we managed to get the problem project out the door.
18 hours early.
The formal go-live came and went with little fanfare.
The first weekend was reasonably quiet. 4000 new users. 40 help desk calls. Only 2 calls having to do with the system not working correctly. The other 38 were of the "how do I" variety or concerned other systems interfaced with the new application. All reasonably small problems.
The Director posited that the uneventfulness of the implementation was a result of the very painful meetings.
I noticed that the last 2 weeks before the go-live people stopped arguing about whose responsibility it was to do something and just did it. People were even volunteering to do stuff (rather than being volunteered), often prefacing their offer with "I can't believe I'm saying this..."
I'd like to think that fear of failure caused the sudden increase in accountability. Of course, I wouldn't be surprised if the Main Muck had a couple of "Come-to-Jesus" meetings either.
If nothing else, the painful meetings may have made all of the individual parties scared to death that the whole thing was going to fall apart.
I don't think, however, that the meetings were the reason for the success of the project.
I think the success of the project was the result of implementing a system that actually WORKED the way it was supposed to.
If you are going to implement something
- Implement something that solves a real problem.
- That provides tangible benefits to the end user
- And, ideally, is reasonably straightforward to use.
The decision-making for what tool to use to solve a problem was the key here. The University implemented a tool that solved 3 very real problems (a very old, outdated mail system, lack of storage space for the end-user, the need to retire some servers). Furthermore, the system implemented is a commercial version of some freeware web tools that many members of the community already use and like. (And no, I am not going to share the name of the project.)
The resulting agony was more a result of having to interface the new tool with systems that did not work so well, establishing minor process changes to incorporate the strengths of the new tool and how best to communicate those changes.
All things implementation projects have to address whether a tool works or not.
But when a tool works, you can spend more time on those items that help ROI and insure continued use rather than on getting the *$*#*@*%@$$ tool working.
And it makes my job much, much easier.