Let's say you're tasked with:
- getting a diverse set of units within an organization
- that need to agree on a common site template
- and then migrate into that template
- using a CMS they don't have confidence in yet
How do you start? Unfortunately, there really isn't a simple 1-2-3 process, but a multi-headed approach something like the following might work:
- Listen. Of course, the team you represent (the implementors/technical team) and the other teams (the users/clients/stakeholders) will have different concerns/frustrations. You and your team desperately want to move them into the system. The users/clients feel this is their big chance to get the features they want before they lose negotiation leverage once they're in the system. Also, no one wants to be the first to move in and be the very bleeding edge. That said, it is helpful to take the time (a lot of time) for you to listen to what the stakeholders want, and for you to articulate your team's constraints / viewpoint (don't just roll over when someone says something is a problem that isn't for example).
- Prioritize. Chances are it won't be in the least bit possible to get everyone's wish list complete before they'll move in. That means prioritizing. If you're dealing with a diverse team, this may mean voting.
- Deliver on small things as promised. Whatever you prioritize, deliver on what you promise. Even if you only can deliver what the users feel is a ridiculously small deliverable. At least you prove that you can deliver on something when you promise it.
- Peer pressure. This surely seems silly to someone in a small institution or at a very top-down institution. But in a very heterogeneous institution, this one really can work. We started tracking how many sites and what percentage of sites each unit had migrated, and we published this to all the units. One unit decided to start migrating, and then other units saw their metrics were lower. This competition helped move people in.
- Setting a deadline. In our case, higher-level management suddenly declared what appeared to be an outrageous deadline for a particular set of units to be in the system (I was shocked). This really helped with the prioritization process, since now there was a goal we were all working toward.
- Get to know the vocal players. If you're someone who wants to get things done, then chances are, although you play different roles, you're going to have a lot of commonality with these folks that are vocal about the new system. These are often the ones who also know how the other stakeholders feel about things, so are good to get to know anyway.
- Obviously, be positive. No one will move into the system if you aren't openly positive (of course, without being false or not appreciating the problems).
Of course, this means a lot of time: sitting in front of people's computers with them showing their problems, long consensus-building meetings with mind-numbing details (like long discussions on whether "News" should go above "Publications" in the left navigation), lots of taking the heat when things go wrong, documenting, shuttling between teams to see what is possible, testing, and lots more. That said, the types of approaches listed above may work for moving forward large systems involving lots of teams.
