Remembering End Users in IT Project Planning

Fact: the more you involve end users in your planning, the more likely they are to support your initiative later.

If you’ve seen one of my presentations, you’ve probably heard me say this a few times. It’s a real problem. My experience has shown that there is a direct correlation between the urgency of a project and the level of involvement of end users. Not that they want to be excluded — that’s just how it ends up. In the interest of moving things forward faster, we cut more people out of the decision-making process, we reduce or limit their visibility (because they might ask questions), and we push past them.

Don’t get me wrong – I’m in full support of people being empowered to make decisions on their own without having to push everything through committee, for people to understand and be comfortable with their roles and accountabilities in the organization. The work environment is a happy place when people know what they need to do, what needs to be done, and they do it. No, I’m talking about the more complex projects that require team input. The building of cross-team processes, platforms, and solutions. The projects that require input from multiple stakeholders. You know, the hard stuff.

When a project timeline gets compressed, the natural reaction is to whittle away the schedule in one of three places, each with its own impacts:

• Requirements — you basically know what you want to build, right? Why spend all that time gathering, sorting, and prioritizing requirements? This is the primary method for end users to share their knowledge of the existing platform, identifying gaps, and sharing details about how the new system or process can help them be more productive. But you know what you’re doing, right?
• Testing — everything seems to be working just fine, and your basic use cases (if you built any use cases in your shortened requirement phase) seem to all pass. Why do you need to involve every key stakeholder team, and basically repeat the steps you’ve already tested? This is another way that end users can get involved, running through their documented and undocumented use cases, putting the new tool or system up against their real-world experience. You know – the experience that comes with owning the content and the systems and the process. But everything seems to look ok without all that, right?
• Training — it’s a nice luxury, but people can learn through use. It’s called "on the job training." Even established platforms require regular training, as technology changes, new features are added, and as employees come and go. Even something as innocuous as an upgrade to a newer version of the same can increase user anxiety and affect productivity. Are your people doing things in the most effective and efficient manner?

Do you see the trend? Each one of these areas impacts end users.

Let me restate my initial point in the inverse: the less you involve end users in your planning (and testing, and training), the less likely they are to support it later. Is end user adoption important to you? If not, please disregard everything.