This is Why Project Teams Fail at Requirements Gathering

Get the Requirements RightIt never fails. And I mean NEVER! Somewhere along the project timeline, you will hear the angry frustration of some high-level user, “That’s not what we wanted!” Often, it’s accompanied by the indignant facial contortions of an “I told you so” attitude.

If you’re lucky, it happens during the review of high-level requirements. As Project Manager, you empower your team to mollify the outraged business person, regroup, redo the requirements collection exercises, and get the project back on track.

If you’re NOT so lucky, this outburst happens during the User Acceptance Testing phase of the project, well after design and coding are completed. As Project Manager, you resist the urge to panic, and you empower your team to become creative in “patching” the problem for now to keep the implementation timeline on track. You then begin the arduous task of planning for the inevitable series of Change Requests that will need to be implemented to satisfy the now vocally unhappy business person. You may eventually satisfy the functional requirements of this user, but you will never escape his constant reminders that he’s paying you twice to get the job done right.

You Developed the Project Requirements By the Book, Yet You Still Failed

The one thing going for you as a seasoned Project Manager is that you have good project documentation, and user approvals of the functional requirements (maybe even by this user). After all, you’re steeped in the technical aspects of project management, and your team did everything by the book:

  • your team developed the requisite Scope Management, Requirements Management and Stakeholder Management Plans as you prepared for the collection of project requirements;
  • you interviewed key stakeholders and Subject Matter Experts (SMEs);
  • you facilitated requirements gathering workshops and even more detailed Joint Application Design (JAD) sessions, and you documented the unique requirements in user stories, structured textual descriptions, and decision tables;
  • you know that ambiguity in writing the requirements can lead to misunderstanding later on, so you ensured that the requirements were clearly and precisely defined;
  • you may have even developed a prototype or a proof of concept to aid in end-user understanding;
  • you prepared a Requirements Traceability Matrix to carry your early analysis all the way through to the project end; and
  • you finalized the requirements document with the client staff on the project and obtained signed approval to move forward with the project.

Fine. The technical, process-oriented aspects of the project are in your favor. So what? You have a disgruntled business person, and a real danger of the project derailing. Yes, you and your team broke out your best technical project management and delivery skills. So where did it go wrong?

By now you understand my basic premise. It is highly unlikely that the failure came in the technical aspects of the requirements collection process – and by “technical aspects” I mean those process-driven, procedural techniques bulleted above.

The Client May Be Wrong, But It’s The Project Manager’s Problem

It is most likely that the failure occurred in not attending to the people aspects of the project. The behavior of your unhappy business person (who may be an SME, an intended end-user, or worst case, a stakeholder), is completely out of line; however (and I say this as a Project Manager myself), I lay the fault for that behavior and the potential disruption to timelines, costs, and end-user usability at the feet of the Project Manager.

That seems harsh. Why would I blame the Project Manager? Because as Project Manager, you have the most to lose – your reputation, your project’s profitability, your team’s morale, your client’s satisfaction.

“But,” you say, “we did everything right! You said so yourself. This disgruntled user even signed off on the requirements that he now doesn’t like.”

Yes, you did everything right. Technically. From a process perspective. Yet you still have a problem. People.

In my experience – and I’ve witnessed this on projects that I have managed as well as ones that others have managed – this behavior is virtually inevitable on any project regardless of size or complexity. So if we know this is inevitable, and if we know its danger to our ability to deliver on time and within budget, then it is incumbent on us to become proficient in the people skills that will help us prevent such issues before they even surface.

It is my observation that this reaction of “That’s not what we wanted!” is more often a defensive, face-saving mechanism. The complainer suddenly realizes that when he sat through those facilitated workshops and JAD sessions, his lack of attention to his own requirements has now come back to haunt him. He thought he had understood what your analysts were asking, but he hadn’t really dug deeper into their questions for fear that he’d look stupid.

Or, and this is potentially more devastating, he didn’t want to give up his old system and processes. His indifference at time of requirements collection was because he was passively resistant. He was never an obstructionist per se, but somehow deep down he thought that it would probably fail and he wouldn’t have to change.

Whatever the reason, he was now caught; and it is easier to blame the project team than to own up to his own failings. After all, if his organization now must pay for Change Requests or agree to a project delay, it isn’t going to fall on him.

Pay Attention to the People Aspects When Gathering Requirements

Here is where the people skills of the Project Manager and team come in. Rather than focus solely on the process aspects of collecting requirements, the team must pay attention to the people aspects of body language, facial expression, tone of voice, curiosity and general interest level of the client participants.

I have frequently witnessed JAD facilitators ask questions, receive responses and document the responses at face value. Yet had they paid attention to the respondent’s hesitation or vocal inflection, they might have sensed a lack of confidence in the answers. A simple restatement of the questions or further probing questions may be all that was required to get the fully fleshed-out responses. Technically speaking, they collected the requirements. Humanly speaking, they missed the full definition of the requirements.

Humans being humans, the facilitators continue thinking that they understood the client’s requirements, while the client representatives continue believing that their requirements have been fully described. Until six months later when the function is being tested, we hear “That’s not what we wanted!” The project team and client staff resort to digging into the documentation. The project team and client staff read the intent of the documented requirements through their own lenses. The project team notes that client “signed off.”

The project team is “right” – technically. But the client is unhappy – humanly.

Occasionally, I have witnessed JAD facilitators ask questions, receive responses (or possibly, non-responses), and document these responses at face value. Yet had they paid attention to the respondent’s vagueness or frequent references to his perfectly good working legacy system, they might have recognized passive resistance in the answers. But instead they document the responses, adhere to project timelines, and finish the JADs with a sigh of relief. A sigh of relief because they got through requirements collection despite the building conflict that they successfully avoided. Technically speaking, they collected the requirements. Humanly speaking, they weren’t even close.

Had they escalated the issue to the Project Manager, he or she could then bring it to the attention of the client management. The issue would have been dealt with in the early stages of the project. Often such resistance comes from lower level end-user staff, whose own management is unaware of any issues. The potential for major project disruption is real and must be dealt with. Simple observation on the part of the facilitator could have quashed the problem at the outset.

Requirements collection is not easy. Skilled analysts who are technically proficient in gathering requirements are a precious commodity. But skilled analysts who focus equally on the people aspects of requirements collection are priceless.

There is never an excuse to hide behind “signed-off” requirements, even if collected in a technically, procedurally correct manner. There is never an excuse to let the people issues slide by.

Pay attention to the body language, facial expression, tone of voice, curiosity, and general interest of your client participants.

And hopefully you’ll avoid that chilling refrain: “That’s not what we wanted!”

Merv Jersak
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.

To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit


52 Project Management Success Tips from Merv Jersak  • 
Copyright ©2020. All rights reserved.