A few months ago, I was approached by one of our department heads about rolling out a new enterprise solution. She had invited a group of managers to a software product demo, and they had been suitably impressed, so she wanted to take advantage of the vendor’s end-of-quarter discount pricing to buy licenses for the entire organization. She was absolutely adamant that everyone who had seen the demo wanted it. I replied, “Everybody wants a fish dinner, until you send them off to dig for worms and bait hooks.”
There’s more to stakeholder analysis than identifying their relative interest and authority, and how much influence they’ll have on the project outcome. You also need to communicate your expectations of their role in the project, and the level of effort required of them and of their teams. Few worthwhile IT projects can be accomplished without significant user involvement. This is especially true when there are wide variations in business rules and practices among the target group, and a variety of heritage applications in use, as there are in this case. In organizations that have “slimmed down” due to the Great Recession, it’s hard to find the bandwidth to take on requirements solicitation interviews, training, user acceptance testing, project status and governance meetings, and all the other myriad tasks in a major software implementation.
To complicate matters even more, the “target group” in this case was spread across multiple functional areas, in over a dozen business units. Potentially, we would be involving over 50 departments, with close to 30,000 employees. And while there was significant cohesion among the departments within a business unit, and “birds of a feather” steering committees involving similar functional departments across business units, there was no precedent for governing standardization of business practices and tools across the enterprise on this scale. These folks had little in common, and no reason to participate in the design of common practices; worse, they had no external pressure to change their current practices, or abandon their familiar applications.
I recommended that we first establish a steering committee with representatives from multiple business units and multiple departments, so we got a more comprehensive “voice of the customer,” and could leverage them as advocates for the new solution. I also suggested that without strong executive support at the highest levels, these folks had little incentive to accept change, let alone actively work for it. Finally, I pointed out that we had no practical experience with the product, and thus no idea of the learning curve for the users, so maybe a pilot implementation was in order before we committed funds to an enterprise deployment.
This week, I was copied on an Email confirming executive approval for a pilot project. We’ll roll out three departments at one business unit. We haven’t finalized the steering committee, but we already have representatives from multiple business units. And once we get them into a conference room together, I’m going to talk to them about digging for worms and baiting hooks.