As of 2017, the Project Management Institute reports that 31% of IT projects do not make their goals, 43% exceed their initial budgets, 49 % were late, and 14% outright fail (1). Inaccurate requirements and unexpected risks can be the root cause of these project breakdowns (2). In order to ensure the success and acceptance of a project, it is critical that the project manager identifies the right stakeholders and gather their project requirements (3). One of the most important stakeholders is the end-user. A project’s success is ultimately decided by the ability of the end-user to use the final product or system. To get a better understanding of the importance of the relationship between the end-user and requirements gathering, I sat down and spoke with the Technical Program Manager of Evergent, Scott Wherity PMP, CMS.
Requirements are critical. You can’t finalize what the budget’s going to be until you’ve got the requirements understood.
Before a project scope can be defined, the proper stakeholders need to be identified and elicited for project requirements. 39% of IT projects ultimately fail because of improper requirements gathering (4). One of the most important stakeholders is the end-user.
Scott Wherity: Requirements are critical. You can’t finalize what the budget’s going to be until you’ve got the requirements understood. Now that doesn’t mean you can’t have a budget, but there’s got to be an understanding that there’s going to be a checkpoint.
Ideally, you should do a charter and a scope statement. The charter is the agreement between the business and the IT. It’s a purchase order almost slash contract on defining who’s doing what. The scope statement is where you’re going to define what’s in and what’s out. Now the scope statement can evolve over time too. You’ll have the right reviews, you’ll review it with the appropriate stakeholders. So there’s the IT stakeholders, the ones that are going to be doing the work. You’ve got the business, their piece of it. There’s going to be others that are going to be impacted by this as well. It’s important that you remember to speak to these people.
Here’s why: because the business knows what they want, the direct business. IT can figure out what it’s going to take, but there are other people impacted and you need to know because otherwise you’re going to find that down the line, oh wait that interface isn’t going to work for them. Or wait, they’re not able to do that on the new platform you’re planning to go on. They can’t support that right now and they may need to do some work on their end.
People have to sign off on the requirements.
The majority of projects fail or are reworked because of missed requirements (5). Once you have collected your initial requirements, how do you know if you collected all the proper user, system and that the business requirements are correct?
Scott Wherity: It’s really simple, make sure you’ve got a well-defined stakeholders list, that you’ve spoken to the right people, and that you have the proper review of them. Then here’s the critical thing, people have to sign off on the requirements. The business has to sign off that yes, this is the fully defined requirements as they understand them. They’re agreeing with the wording and any assumptions and risks that go along with those.
You do the same thing with the IT requirements. All the right people need to sign off on those. If you don’t get those things signed off on, or you start, (and a lot of times people do), you start the requirements without getting that done. It’s got to be understood that you’re going to wind up with CRs and things are going to change.
If people don’t know how to use this fantastic new hammer that you built, it’s not going to get used.
So where does the end-user fit into all of this? Even if the end-user is the lowest person on the organizational chart they are critical to the project because without them there would be no project. The success of a project will have the most impact on their everyday lives. How important is it to take into account the affordances of other systems and products/systems that they are currently interacting with?
Scott Wherity: Keeping the end-user in mind is important because you need to know what training you may need to provide people. Then you can define your training plan and how you’re going to do it. But look, if people don’t know how to use this fantastic new hammer that you built, it’s not going to get used.
Also, you need to make sure of a couple of things. Does your IT staff have the right technology? Is your architect recommending that you go on a new platform that you may not have developers in place to use this? Do your infrastructure group, and your network folks understand how to do that. If they don’t you’ve got to figure out if we are going to bring in a couple of consultants, contractors to help them? Or are we just going to say, you know what, we just need to outsource this to get it done, and we’ll have some of our people re-trained so that they can support this when it’s done? You need to know what knowledge is in place.
Finding an issue during the requirements stage is about a nickel on the dollar versus what it is when you find the issue in the testing stage, in the end-testing stage.
As far as the end-user is concerned, it is also crucial to keep them actively engaged throughout the project after the requirements have been gathered. It is their feedback that can often change the requirements and scope of the project. Feedback can be gathered through usability tests performed through demos and project prototyping.
Scott Wherity: Oh, it’s critical. So they call it the product owner in SCRUM and pretty much in waterfall too. You’ve got to have, the business has got to have someone in place who can make business decisions. Now they may know, well I’ve got to go talk to these people. But you have to have that person, you have to keep them in the loop. You need to have checkpoints regularly with the appropriate people.
You absolutely need to keep the key stakeholders as part of the decision process. You need to have regular statuses with them. A lot of people say will go well that’s overhead. No, it’s not, because you’re alleviating confusion and issues down the thing. Finding an issue during the requirements stage is about a nickel on the dollar versus what it is when you find the issue in the testing stage, in the end-testing stage.
The success of a project will ultimately be determined by the usability of a final product or system by the end-user. It is extremely important to keep the end-user active and engaged in the project from the requirements stage through project close-out. Identifying and understanding all the stakeholders and their initial needs is vital to the success and acceptance of a project. By keeping the end-user and stakeholders involved throughout the process, new user requirements will be uncovered and implemented during the project, ensuring a product that will be used by the end-user.
Some food for thought:
- What other project stakeholders are important to consider when developing scopes and requirements?
- What are good ways to keep end-users engaged throughout the project?
- What other strategies lead to successful projects?
Featured Image: “Proservice Media.” Proservice Media, 14 July 2018, www.proservice.com/wp-content/uploads/2018/07/The-Importance-of-Learning-and-Development-Opportunities.jpg.
(1, 2, 4) Greene, Jessica. “The Top 9 Reasons for IT Project Failure: Is Your Project at Risk? · Spoke.” Spoke, 23 Apr. 2019, www.askspoke.com/blog/it/reasons-for-it-project-failure/.
(3) Schoenhard, Lori. “4 Ways Stakeholders Are Important to a Project.” Proficient Learning, 4 June 2017, proficientlearning.com/4-ways-stakeholders-are-important-to-a-project/.
(5) “How Do We Know When We’ve Captured Enough Requirements at the Right Level of Detail?” How Do We Know When We’ve Captured Enough Requirements at the Right Level of Detail? – ProjectConnections.com,.