It continually amazes me how an otherwise perfectly sane human being can design a project that is unimplementable. A colleague of mine gave it the perfect label this week. She calls it the “Ending World Hunger” syndrome. Now don’t get me wrong, I’m all for ending world hunger but there are some of us who are so intractable that it’s world hunger or nothing. When people like these become project managers or, worse, the implementers of project management systems, the consequences can be dire.
People who are out for ‘ending world hunger or bust’ are unwilling to settle interimly for feeding the nation or feeding our county or our town. It’s all or nothing.
Imagine the following two scenarios and you can see the problem quite clearly. In both scenarios, the final goal is to deploy an enterprise-wide mission-critical I/S system.
In scenario 1, the project manager has determined that the only way to successfully deploy the entire corporate system is to do it as a single, corporate sponsored initiative. First an exhaustive design phase must occur where every possible requirement has been elicited from the staff and has been scoped out in the requirements document. In this situation, no work in soliciting vendors or in coding the application will be considered until the entire organization has approved the design plan. Once the design has been approved, the new system will be either purchased or constructed with exacting precision so that it exactly matches the requirements document. Then the system will be deployed to all users simultaneously. It will be used in parallel for a short period with the existing system then all legacy data will be transported to the new system and the old system(s) will be turned off simultaneously across the entire organization.
Now, let’s place what kind of organization we’re talking about. We are not referring here to a 10 person high-tech consulting firm. If we were, it wouldn’t matter what our strategy is. Any time we’d have a conflict, a yell from the president down the hallway to all staff members will fix it. No, what we’re referring to here is an organization large enough that implementing a corporate-wide system is a challenge. It has perhaps hundreds or even thousands of members. It may have multiple sites and even in (gasp!) multiple countries.
There’s a couple of problems with scenario 1 in such an organization and if you’ve ever been part of such a project you’re probably cringing with the memory of it right now.
The first problem is the first point. Getting the whole organization to agree to a design specification. First of all in any decent sized organization, some managers feel an obligation to not give blanket support to corporate initiatives just on principle. Also, in any decent sized organization, the chances that someone in management changes during the decision making process is almost 100%. Many managers feel compelled to question outstanding decisions by their predecessors lest they become responsible for them. If unanimous consent is required before creating the global system can be begin, you’ve got a big problem.
As if that’s not enough, while some people argue over whether or not some particular feature should or should not be included, another issue is getting everyone to agree to do the same thing in the same way. When the requirements document is actually assembled, it’s entirely likely that there will be requirements that conflict. (It’s got to be easy, but it’s got to have many complicated functions. It’s got to be driven by finance and it’s got to be driven by project management etc.)
But wait there’s more. Should a miracle occur and consensus over the design actually occurs, there’s the entire programming or acquisition phase to endure. If the system is being written in-house (always a treat), then there are all the issues that come with a high-pressure, high-tech programming project. Technology, skill availability, design-mismatch to programming results, risk and, the all dreaded scope-creep. But wait! Didn’t’ we say the design was corporate approved – locked down? Sure, but what are the chances that during the programming phase someone in the management team changes? The larger the system, the more likely it will happen. Just think about how often a high-tech project actually ends with the scope it started with. It’s not too common.
If the system is being acquired, the chances that it is not a 100% match for the extensive requirements specification is almost certain. Now, there starts another whole debate over what level of compromise is acceptable to match a commercial system to the requirements.
The kicker to all of this is the worst part. During this entire period of specification, acquisition or programming and, of course, negotiation with everyone who’s got to agree during a long contiguous time, no one gets any value. No one gets the first screen, the first report the first anything out of the all-seeing, all-knowing corporate system because it’s still ‘in-design’.
Now, in scenario 2, the project manager has a similar goal – to deploy a corporate-wide, mission critical I/S system. This project manager however, has decided to go for the easy-wins, the little victories. In this scenario, the project manager starts with smaller departments or divisions, starting with the most likely to succeed. With each deployment, he or she look to see what works and what doesn’t and refines the process for the next group. Before they know it, there’s a small band of users in different departments who are all reasonably satisfied with their new system. The project manager uses the successes to leverage still more. Suddenly the company newsletter is doing a story and now even more departments are calling the project manager asking when they can be put on the new system. The project manager sticks to their guns, working across the company slowly, never exceeding (at least by much) the availability of the implementation skills available. The most difficult department; the least likely to go for the new system is saved to last.
In this scenario the risk is that it is entirely possible that not 100% of all departments adopt the new system in the end. However, it is much more likely that those that do will get a system that works. With both the specification and the implementation process being refined through repeated use, the system will improve. Moreover, as everyone knows who has ever looked at a brand-new system, once it’s in actual use, the users’ perception of what is required will change. This kind of process lets the system be tried without having to wait until the entire company is on board.
The best part about scenario 2 is that the organization starts to get some benefit right away. As each department adopts the new system, the benefits of switching become available to it and by extension to the organization. It’s true that the benefits of the entire organization being on the same system can’t be realized until the last department comes on board but it’s easy to imagine that in scenario 1, that may never happen anyway and, in the meantime, with scenario 2 at least you can have the organization realize some benefit.
Finally, for those of you who are career minded, scenario 2 doesn’t have your start shine quite as bright as scenario 1 but be warned – ‘ending world hunger’ type projects have been known to produce casualties. More than one career has been hung out to dry with a failed corporate-wide initiative.
If you’re considering a corporate wide system, I recommend taking a long look not just at the features you’ll require, but also at how you plan to implement them. Going with a phased-in implementation isn’t quite so dramatic or quite so spectacular but it’s also a lot more likely to deliver value than the big-bang approach. If you’re out to end world hunger, why not start with feeding your local town first.
