Most large software projects come with interested parties or “stakeholders.” Each stakeholder wants something slightly different out of the project:
- Executives want a system that increases revenues, decreases costs (or both), and – incidentally – makes them look good.
- Department heads want a system that enables their teams to work more efficiently (and, incidentally, makes them look good).
- Project leaders want a well-defined project that runs smoothly, is completed on time and within budget – and incidentally – makes them look good.
- Development team members want a project that presents an interesting challenge with no surprises (and, incidentally, makes them look good).
- End users want a system with a gentle learning curve that works with them, not against them. (End users are less concerned with whether it makes them look good.)
It’s the end users that all too often end up with the least say in the whole process. The ironic thing is they are – in almost all cases – the most important piece of the puzzle. AndPlus understands this.
We insist on giving end users a prominent place at the table for any project we undertake. Here’s why:
When a new client contacts us to discuss a custom software project idea, the initial inquiry usually comes from a department manager, IT lead, or a senior leader. These people have the big-picture vision, decision-making power, and at least some control over the budget.
When we discuss our development process and how we involve the end users, we sometimes get push-back. They don’t want the end users involved because:
- “I already know what I want, so there’s no need to involve the users.”
- “I have a project manager [or another leader] who can represent the end users on this project.”
- “They’re too busy with their day jobs to get them involved in a project like this.”
We know from experience that involving the end users in a major software project has many benefits. Leaving them out introduces significant risks.
Ignore End Users at Your Peril
Why is including end users as stakeholders in a software project so important?
- They know more than you. If you manage a department of end users, you may think you know their tools and processes, but you don’t. Only the ones performing tasks day in and day out know how it’s really done (and it’s often not exactly what the standard operating procedures say.) They also know their pain points much better than you do.
- They want to be involved. Most people like to be involved in good projects that promise to make their lives easier, especially well-run projects with definite, achievable timelines. No one likes a never-ending project. The caveat is that their involvement needs to be meaningful. They want to be listened to, their opinions valued, and they should have a say in the decision-making. Simply inviting them to meetings isn’t enough.
- They want ownership. End users are the ones that will be using the new software, so their opinions should matter the most. If they don’t get what they need because they were left out, they will declare the project a failure. Then they will blame the project leadership (and rightly so). This lack of ownership leads to low morale and resistance to using new tools.
How to Get the Users Involved
The notion that you can’t spare your end users for a weeks-long software project is not without merit. Often, the users most valuable as stakeholders on a software project are also the most knowledgeable, go-to, high-performing employees. They’re the ones keeping your department running. How do you compensate for lost productivity by taking them away from their day-to-day duties?
In most cases, you don’t need to take them away from their regular jobs full-time. On average, they might be needed for project activities half of the time, or even less. More involvement will be needed in the early stages when requirements are being determined and the product roadmap is being defined.
During the actual development sprints, end users are likely to be needed only during sprint planning sessions, demonstrations, and sprint reviews. Altogether these might average a few hours per week.
A major software project is a significant investment, and end users might be needed full-time for a couple of weeks or more. Many organizations include temporary help in their major software project budgets.
Yes, it can be a pain to recruit and hire sufficiently competent temp help for a few weeks. But it will be worth the trouble if you end up with a better system.
How AndPlus Leverages End Users
Knowing what we know about the value of end users in a software project, we insist on their involvement early and keep them involved in some capacity throughout the project. Here are some of the areas where we need end-user involvement:
1. Defining user roles and journeys
We need the end users to tell us who they are, what they do, how they work, and their pain points. We want to know about their physical environments and their current tools’ shortcomings.
2. Gathering and vetting requirements
We spend a large chunk of time with end users determining what the system requirements are. We make sure they are complete, correct, and consistent.
3. Defining the minimum viable product (MVP) and product roadmap
From the requirements’ specification, we team with end users to find the absolute minimum feature set that will constitute version 1. Opinions can vary widely on what the MVP looks like, and we work hard to get buy-in from everyone while keeping that initial version manageable. We also need user input to define what features to add later, and in what order. That is the product roadmap.
Now the user experience (UX) designers get involved and begin designing the user interface. Users are needed to review and provide feedback on the prototypes. This feedback is immensely valuable. It helps keep us on track to providing a software solution that is both useful and usable.
5. Sprint planning
Before each sprint, we gather with the users and other stakeholders to prioritize backlog items that will be included in the sprint. We want to make sure we are working on the things that will be of most value.
At the end of each sprint, we have a release candidate demonstrate to the stakeholders. We rely on the feedback from the most important people in the room: the end users; the ones using the software when the project is finished.
Clearly, the success of a major software project depends on the involvement of the people that will use the final product. Ignoring them or leaving them out of the process is a recipe for disaster.