16 People-Focused Techniques for Better Requirements Definition

Requirements Gathering is a People-Focused ActivityWe recruit the top graduates from the best technical and business schools. Our IT project staff are steeped in company system development methodologies. Our Project Managers and team leads have achieved PMI certifications – yet our industry still has a dismal track record in delivering computer systems (see This is Why So Many IT Projects Fail: A “People First” Companion to the PMBOK).

Why is that?

Many projects begin their downward spiral at the outset, in the requirements definition phase. Requirements definition is the project phase in which we most deliberately employ the people aspects of project delivery. For more information see my previous article, This is Why Project Teams Fail at Requirements Gathering.

Where does IT typically invest its staff’s time, effort, and training in requirements gathering? Typically, it’s in developing their technical and process-oriented techniques for eliciting requirements. However, in their quest to execute process well, the team pays little attention to the people aspects of this critical activity, and projects often fall short of meeting their objectives.

People-Focused Techniques You Won’t Find in the Textbooks

In my own project experience, I have used many proven processes for eliciting and documenting system requirements (e.g. brainstorming, requirements workshops, interviews, surveys, document analysis, analytical tools, decision-making processes, user stories, prototyping, traceability). However, it wasn’t until I understood that this process is more art than science that my teams became much more successful at developing a solid base of system requirements. When we relied more on the art than just the process, we produced well-documented, well understood sets of requirements that remained largely intact throughout the entire development life cycle.

This art is demonstrated in people-oriented techniques such as the following:

  1. Solicit the brightest and best end-users from the client organization.

    Defining a solid requirements base requires in-depth business knowledge from Subject Matter Experts (SMEs) and representatives from the client organization. Typically, the IT team requires that client staff/end-users be assigned full time for the duration of the project, or at least for the duration of specialized activities.

    For example, best practice requires that end-users involved in defining the business requirements remain on the project to advise the design teams, to prepare user acceptance test cases, to test the system, and to be involved in training and implementation activities.

    Often when I have solicited client staff for full-time project positions, management was willing to lend me their least effective performers. I soon learned to ask for their brightest and best. After all, wouldn’t requirements elicitation achieve better results with input from the client’s most knowledgeable staff?

    How did I know I was getting their brightest and best? I would watch the manager for that telltale grimace, or that uncomfortable shift in the chair – a sure sign that she was offering up a solid contributor.

  2. Prepare. Prepare. Prepare.

    IT project staff typically prepare well. They read related materials and interview key client staff. They organize their notes according to business areas and functions. Yes, they prepare well in a studious, process-oriented manner.

    But in trying to understand the business, do they really understand the business? In my experience, they do not:

        •  it’s not until the business analysts go into the end-user’s work environment that they begin to 
           relate what they gleaned from reading to what they observe first hand;
        •  it’s not until they sit with one business group to see how information from another group is 
           required for their operations do they truly understand what upstream processes must be analyzed;
        •  it’s not until they interview the client’s customers do they understand inefficiencies in the current
           business processes that can be eliminated with the new system; and
        •  for my teams, it was not until they knew the client’s business as well as the client knew it were we
           ready to conduct meaningful requirements gathering activities.

  3. Plan the workshop sessions.

    To the IT project staff, requirements gathering is just a project phase with inputs, processes and outputs. They have checklists, methods and techniques, documentation templates and review and approval processes to help them execute the tasks.

    What IT staff forget is that the client staff loaned to the project have day jobs. Their work experience has no relation to what they are about to experience on a systems project. IT staff forget that end-users don’t understand terms like JAD (Joint Application Design), traceability, decision tables and hundreds of others that we take for granted. They don’t realize that client staff are intimidated as these terms are casually thrown around in conversation.

    It is IT’s responsibility to lead the end-users through every step of the process. In-depth planning of the workshop sessions, dates, times, overlap with other teams’ sessions, expected involvement and contribution, and materials to reference are just a few of the logistics that should be defined. This sets client staff at ease, and prepares them for their upcoming tasks. In my own experience, client staff prepared in this way soon get to a comfort level where they outwork and outpace the IT staff.

  4. Communicate clear instructions and guidelines.

    Client staff are less apprehensive when they understand what is expected of them before they begin. They have been taken out of their day jobs where they are superstars and placed into a foreign environment that they have not previously experienced.

    The IT team should prepare a set of instructions and guidelines that define:

       •  the objectives of the requirements gathering sessions,
       •  how the sessions will be conducted,
       •  the roles and responsibilities of the facilitator and of the end-users,
       •  how information will be recorded and documented, and
       •  the myriad of other such processes. 

    End-users are receptive to any such guidance that will help them excel in their new assignment.

  5. Develop rules of conduct.

    Requirements gathering and definition is a complex process. It can become contentious. There is a natural tension between the client staff identifying their wants and the IT team attempting to manage the analysis to what they believe is within the functional boundary. Days are long and intense, and people get tired. Unexpected events happen.

    Rules of conduct should be developed before the requirements sessions begin. What time do the sessions start and end? When are lunch breaks and other breaks? How will the teams handle disagreements regarding overall functional scope? How are issues escalated and who is the final arbiter? How will tardiness, lack of preparation, unruly behavior, and other such disruptive issues be handled? How does the team work around vacation time, sickness, or “day job” emergencies?

    Thinking through these types of issues and presenting them to the entire team ahead of time goes a long way to preempt potentially more serious issues later on.

  6. Model a requirements workshop.

    What better way to prepare IT and client staff for the requirements workshops than to model exactly how they will be conducted? There is nothing better than a visual to cement the process in one’s mind.

    On one of my more recent projects, we conducted “mock JADs.” Additionally, we invited the IT and client’s management to observe. We modeled the requirements process using one of the functional areas, engaged IT and end-user staff in their actual roles, and coached them through the process. Not only did the entire team understand what their next several weeks would look like, but as an added bonus, management understood what was expected of them when we escalated issues for resolution.

  7. Build rapport.

    Client staff coming onto the project feel intimidated – intimidated by the awesome responsibility entrusted to them, and intimidated by the obvious competence of their IT counterparts.

    It is incumbent on the IT staff to build rapport with the client staff immediately. On projects on which I served, we began the requirements phase by conducting fun, inclusive, team building activities designed specifically to build camaraderie and trust. We included exercises designed to build consensus in decision making. We encouraged staff to voice their opinions if they did not agree with what was being proposed.

  8. Solicit end-user scribes.

    IT should encourage the client organization to include a knowledgeable staff person in the role of a second scribe during requirements gathering. Typically, IT facilitates, IT scribes the notes, and IT drives the end result. There is nothing wrong with this approach; after all, IT is responsible for delivering the system.

    However, even though IT is able to learn the client’s business, they do not always understand the underlying nuances or essential details. While their notes are usually very good, they are not always completely accurate or free of ambiguity.

    The client organization should be invited to add a staff members as scribes to take notes, to add “color commentary” to the notes, and to help resolve discrepancies between their documentation and that of the IT scribes.

    The process demands a scribe to capture requirements, and paying attention to the people aspects of delivery invites the addition of a business-oriented scribe.

  9. Use open-ended questions.

    Why do I call this out as a separate item? Because we IT types don’t do this well! I can’t count the number of times I’ve walked into requirements elicitation sessions only to hear the facilitators recite a litany of yes/no questions that are based on their preparation for the session. The end-users appeared to be in the sessions for the sole purpose of approving what the IT staff had learned.

    Check the box indicating completion. Document the “approved” requirement. Done early.

    To truly ferret out the detailed requirements for a business area, open discussions using open-ended questions are indispensable. Techniques such as brainstorming, round robin solicitation, recounting of real-world examples and repeating back what was stated take longer than yes/no discussions. However, the end result is better defined and documented.

  10. Speak once. Listen twice.

    As my grandfather used to say, we have two ears and one mouth; use them in proportion. What is it about requirements facilitators that they feel they must monopolize the conversation? Yes, they studied the material. Yes, they have an approach to validate what they discovered.

    However, what they have read and studied is far inferior to what end-users with actual work experience can teach them. IT analysts must develop the skill of active listening. Active listening skills bring the IT analysts and the end-user participants to an understanding that the requirement is correctly defined and completely understood by both parties.

  11. Draw pictures!

    I’ve watched IT analysts attempt to explain a functional requirement. When the end-user does not understand the explanation, the analyst attempts to go deeper and talk more. At some point, the end-user thinks she understands or just gives up, and the analyst declares the requirement fully defined.

    One of my biggest pet peeves is the inability of analysts to define a requirement using natural language, which is fraught with ambiguity. Nothing gives me more satisfaction than to pick up a dry-erase marker and draw a conceptual diagram to support the attempted explanation. I visibly see light bulbs go on in the minds of the end-user who just grasped the concept and the IT analyst who just understood his own explanation.

    A picture is worth the clarity it brings to both parties.

  12. Pay attention to non-verbal cues, tone of voice, curiosity, general interest level.

    These characteristics are typically labeled “soft skills” and are given short shrift in favor of “hard” analytical, process-oriented skills. However, these “soft skills” are really essential skills in requirements gathering.

    IT analysts often come across as automatons, interested primarily in task and schedule over consideration and understanding. In other words, requirements gathering becomes a time-boxed exercise to arrive at an end result rather than a thoughtful process to arrive at a deep understanding of the client’s needs.

    The successful analyst develops these “soft skills” such that he, for example:

        •  notices hesitation in an end-user’s response and asks clarifying questions,
        •  observes his audience’s inattentiveness and alters his approach,
        •  perceives facial expressions of agreement or disagreement and responds accordingly,
        •  is overall more observant in his facilitation, and
        •  goes deep to gain better understanding.

  13. Handle difficult situations quickly.

    Requirements gathering is long, intensive, and complex. Despite the camaraderie and inclusiveness among the teams, conflict, or boredom, or restlessness can set in and take away from the quality of the process.

    Additionally, with such proximity over a prolonged period, disruptive behaviors can materialize:

        •  the dominating personality with an opinion regarding everything,
        •  the multi-tasker alternating between participation and social media (see next point), and/or
        •  the wanderer derailing conversations with off-topic conversations and storytelling.

    Whatever the situation, the IT analyst must have the skills to deal with the disruption quickly and respectfully, and move on with the process.

  14. Eliminate technological distractions.

    Walk into any project meeting, status meeting, planning meeting, or in this case, a requirements gathering workshop, and the participants are often observed texting, checking email, and viewing social media on their portable devices. Team members from both IT and the client organization are equally guilty. These actions distract attendees’ full attention from the task at hand.

    Requirements elicitation and documentation is hard work and requires participants to be fully present and attentive. Technology breaks can be scheduled throughout the day to allow participants to check their devices; but otherwise their full participation is required.

  15. Conduct cross-functional requirement sessions.

    On large projects, IT staff often schedule parallel requirements workshops organized by business area. SMEs for that business area are in attendance to ensure that in-depth analysis occurs.

    However, computer systems are integrated across the business areas, and often a decision made for one area will affect another. Cross-functional sessions should be scheduled to review the decisions made in each business area that cross over to other areas. This ensures that the final set of requirements is seamless across the entire solution and gives peace of mind to end-users who are isolated in one requirements workshop while being aware that other areas may be affected.

  16. Facilitate review sessions.

    Often at the conclusion of the requirements gathering activities, the IT provider bundles the requirements into a deliverable and dumps it at the feet of the participating client staff. This is especially true when using waterfall methodologies.

    The client staff are required to review the deliverable, provide specific commentary on requirements that they believe have not been correctly documented, and approve the deliverable after it has been updated. The approved deliverable then becomes the basis for the remainder of the project. Unfortunately, it also becomes the basis for countless change requests.

    If many of the above people-focused techniques are followed, the review process becomes straightforward. Additionally, if the IT staff walk the client staff through the deliverable review and approval process, fewer ambiguous requirements get through.

    The intent of this facilitation is to:

        •  explain the organization of the deliverable,
        •  explain how best to ensure that requirements are captured correctly,
        •  answer questions of ambiguity, and
        •  make adjustments where IT may have misinterpreted certain requirements.

    This facilitated review and approval process continues to build trust among the team members and arrives at agreement and approval in a much more thorough and responsive manner.

    These people-focused techniques are not difficult to learn and implement, and are instrumental in helping to assure greater project success. It’s time for IT to invest in the essential skills that attend to the people aspects of project delivery.

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 www.PeopleFirstProjectManagement.com.

EMAIL merv@PeopleFirstProjectManagement.com // LINKEDIN www.linkedin.com/in/mervjersak

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