“It takes less time to do something right than to explain why it was done wrong.” –Henry Wadsworth Longfellow

 Project teams build software, systems and products for people to use or consume.  So why is it that many project teams don’t seem to like to engage the actual users when coming up with the requirements for the systems and products they are tasked with building?  I don’t get it!  Then again, perhaps neither do many project teams.

In the Standish Group’s 2014 “CHAOS Report”, they published the results of a survey of IT executive management and their opinions of why projects succeed, fail and face schedule, budget and/or quality challenges.  Two of the top three reasons for project success?  User involvement and clear statements of requirements.  Oh, and by the way, the TOP TWO reasons for cancelled and challenged projects were incomplete requirements and lack of user input/involvement.

Big surprise, huh?  Look back on the projects you have worked on in the past; specifically the ones that were over budget or late or didn’t deliver what was expected or were outright cancelled.  How many of those projects suffered because the stakeholders were not involved or if they were, their involvement was minimal?  Probably quite a few, if not all.  From my experience, I have found that there is a direct correlation between user (stakeholder) involvement and clear statements of requirements.  If you don’t have one (stakeholder involvement), I, for one, think you cannot hope to have the other (clear requirements).  That is the opinion of my company, ArgonDigital, as well.

We are so adamant about the importance of stakeholders to requirement definition success that we include it as a key topic in all of our training curricula.  However, when this topic comes up, we often have our student professionals lament that they do involve their stakeholders during the requirement definition process and yet they still get hammered with change requests later in the project.  Per a plurality of our students, the three most common reasons stakeholders give for raising change requests are what was delivered in the software, system, product was: (1) not needed, or (2) not what the stakeholder had in mind, or (3) missing some key piece of functionality.  So, to the question we inevitably get asked…exactly what can the BA, the project manager, the systems engineer, the elicitor of requirements, do to ensure that requirements gleaned from the stakeholders are truly needed and that the requirements are correct and complete?

Well, first off, you can never ensure anything as it relates to people and requirements.  However, there are a number of things you can do help your stakeholders articulate what they need in the software, system or product.  Then, once defined, there are steps you can take to validate the requirements with your stakeholders to confirm need, completeness and correctness.

Let’s start with the stakeholders given their criticality to project success.  First and foremost, identify your stakeholders and understand what they want, need, care about.  You do this by performing a…

Stakeholder Identification and Analysis

This activity allows you to identify all the needed stakeholders and confirm that they are the right stakeholders from whom to elicit and validate the requirements.  To identify the needed stakeholders, think V I P:

V – These stakeholders have a vested interest in the outcome of the project – good or bad.

I – These stakeholders are influential from a schedule, budget, resource, sponsorship or advocacy perspective.

P – These stakeholders will participate in defining requirements for one or more lifecycle stages of the product (e.g., training, testing, development, installation, maintenance, manufacturing, etc.).

Once you have identified your stakeholders, you then perform a Stakeholder Analysis.  This analysis allows you to:

– determine if you have included all the right stakeholders (and if not, make any needed changes or additions),

– identify the stakeholders that have the most influence, the most power…these are the ones you want to make sure that their interests are addressed (and thus minimize the risk of rework because you didn’t deliver to a key stakeholder’s expectation),

– develop a plan of action to turn the less supportive stakeholders into advocates (and minimize the risk that your project is negatively impacted from a schedule, budget or resource perspective because there is a stakeholder that is opposed to the project), and

– develop a strategy for communicating with the various stakeholder groups (and hence manage expectations).

If you identify all your stakeholders, perform the stakeholder analysis, and develop and execute a plan for stakeholder engagement and constant communication throughout the entire project’s duration, then you have put your project on the path to success from a people and expectations management perspective.

Now let’s look at the requirements definition side, where, after analyzing your stakeholders, you…

Choose the Right Elicitation Technique

Again, I ask you to think back on your prior projects.  Have you ever encountered the situation where you asked your stakeholder what he/she needed the system or product to do and all you got in response was silence?  Personally, and unfortunately, I have found this to be a pretty common occurrence when I asked my stakeholders for their requirements and admittedly, I have experienced my share of rather awkward silences.  That said, I honestly do not think it is a matter of the stakeholder intentionally shutting me out or not wanting to tell me his/her requirements.  Rather, I think it is either the stakeholder does not know how to articulate what is needed, or the stakeholder assumes I know everything he/she knows and it does not occur to him/her to tell me all that is needed or wanted.

To be successful in getting requirements from our stakeholders, it is helpful to know the various elicitation techniques that are effective for getting requirements from individuals and which techniques work best for the different personality types with which we will be interacting.

There are any number of techniques for eliciting requirements: interviewing, workshops, prototyping, questionnaires, surveys, focus groups, brainstorming, storyboards, operational concepts, observation, diagramming, etc.  My recommendation is to evaluate your stakeholders and select the elicitation method(s) that you think would be most effective in drawing out their requirements.  For example, if a stakeholder is not prone to speak up in a group setting, I may choose an interview, questionnaire or survey approach.  On the other hand, if I have a group of stakeholders that work effectively in a collaborative environment, I may pursue a workshop approach.

Irrespective of the approach you select, please make sure that your stakeholder is comfortable with the elicitation approach you are using.  What I am saying is this – if during your discussions with the stakeholder, things seem muted or agreements are easily reached with little fuss, then you might want to take a moment and ask (poll) the stakeholder to make sure he/she is comfortable with the pace and output of your conversation.  Through polling, you learn early on if your stakeholder is uncomfortable, and if so, you can then make an adjustment to your elicitation approach.  By making needed course corrections on the fly as you are working with your stakeholders, you will minimize the risk of potentially changing requirements down the road.  However, if you do not make needed course corrections in your elicitation approach, you risk having to revisit everything agreed to earlier because the stakeholder was not comfortable with the process, pace, decisions, or just did not feel comfortable speaking up and voicing his/her concerns.

So, we have elicited the requirements from the stakeholders, but how do we know we a complete set of requirements?  Well, one way to guard against incomplete requirements is to…

Consider Off-Nominal Situations

When eliciting requirements, we tend to focus only on nominal situations; for example, how the system or product is to be operated, manufactured, tested, installed, maintained, stored, transported, etc.  When you limit your focus to nominal situations, you risk incomplete requirements relative to availability, operability, reliability, interoperability, scalability, safety, security, environment, to name a few.  To avoid incomplete requirements, make sure that during your discussions with your stakeholders, you address potential off-nominal situations (e.g., what the system/product needs to do when encountering hazards, misuse, extremes, expected problems, error conditions, faults, and the like).

Want another reason to consider off-nominal situations when defining requirements?  Think rework and bottom line.  Barry Boehm and Victor Basili found that “80% of the avoidable rework comes from 20% of defects.”  They go on to state that “Two major sources of avoidable rework are hastily-specified requirements and nominal-case design and development (where late accommodation of off-nominal (emphasis mine) requirements causes major architecture, design, and code breakage).”  (See Boehm, B. and V. Basili, “Software Defect Reduction Top 10 List,” IEEE Computer, January 2001.).

So if you want to minimize the risk of incomplete requirements, make sure you address both nominal and off-nominal situations when eliciting requirements from your stakeholders.

Thus far we have discussed (1) identifying and engaging our stakeholders, (2) eliciting their requirements, and (3) guiding the discussions to encompass both nominal and off-nominal situations so that we have a complete picture of what is needed.  Now to the issue of making sure we have clear requirements that are, in fact, correct, complete and can receive buy-in and agreement from the stakeholders.  You can achieve this goal through the…

Conduct of Requirement Reviews to Validate the Requirements

If you want to guard against baselining a set of requirements that are vague, incomplete, incorrect, or subject to change down the road, then validate the requirements with your stakeholders and peers.

First to some questions you may have with regard to “requirement validation”:

– What is meant by the term validation as it relates to requirements? Requirement validation is a process whereby you review requirements with the appropriate stakeholder to make sure the requirement is needed, unambiguous, feasible, correct and complete.

– When does one do requirement validation? You validate your requirements with the appropriate stakeholder(s) continuously as the requirements are written and then at the key-milestone review or gate (e.g., System Requirement Review (SRR)) when you validate the requirements and obtain approval for baseline and control prior to proceeding to the next stage in the project (e.g., design).

– How is requirement validation performed? For continuous validation, you can follow an informal process like peer reviews, one-on-one meetings with your stakeholders, and brown-bag lunch sessions with the relevant stakeholder group.  Alternatively, you can validate your requirements by following a more formal process called “Inspections” where a small group of “peers” will review the requirements for defects and opportunities for improvement.  Regardless of the approach you choose, make sure that you:

– validate (confirm) that what the stakeholder is asking for is what they NEED, not what they want (e.g., “I want a dashboard” versus “I need real-time access to shipping data”

– eliminate ambiguities

– identify those requirements that can be interpreted more than one way and resolve

– identify errors and omissions and take the appropriate actions to resolve

If you validate the requirements continuously with your stakeholders and find and fix the problems you detect early on, your System Requirement Review (SRR) (or whatever level of requirement review you are conducting) will go much smoother and probably much faster.

As for the SRR…this is “hopefully” a one-time formal effort where all stakeholders will review the requirements to make sure that they are valid as a complete set and ready for baseline and control.  This is also the time when you will be getting sign-off from all the stakeholders indicating their agreement with the requirements.  Sign-off does not mean that requirements will not change…they probably will.  But not because the requirements are bad or missing something but because maybe the business changes, or because of the competition, or new technologies, standards, regulations and the like.  You just don’t want change because the requirements were poorly written or incorrect, incomplete or missing.

To run an effective and productive SRR, I recommend you put the following measures in place:

– Invite all relevant (think V (Vested Interest), I (Influential) and P (Participating)) stakeholders to the SRR.

– Review the Vision and Scope of the product/project to ensure that all those reviewing the requirements are working from the same understanding of what the project hopes to achieve, the assumptions, the drivers and constraints, and other components of the Scope.

– Make sure that all reviewers know what is expected of them and discuss the standards and templates the stakeholders will be using during the course of the review.

– Give your stakeholders ample time to conduct their review of the requirements (you do not want problems with the requirements missed because the reviewers were rushed).

– Advise the stakeholders that “silence does not equal consent”, that feedback is needed, even if it is affirmation that all is correct, and that sign-off will be requested, once the concerns/issues are dispositioned.

– Make sure that you respond to all stakeholder review comments and advise them as to how their issues/concerns are dispositioned.

If you have the right people to conduct the review, and the problems identified in the review are addressed in a timely manner, including the updating of any requirements, then you will have the basis with which to decide, with confidence, if the requirements are clear and complete enough to go into design.  That’s the point of the review – to find, fix, agree and approve…not to check a box indicating that a review has been conducted.

Wrap-up

From my 25 years of experience in managing large development projects (and validated by the Standish Groups’ survey findings) successful projects are predicated on two things – active stakeholder involvement and clear statements of requirements.  You have one, you improve your chances that you will have the other.  So, make sure that you identify your stakeholders and engage them during requirement elicitation, analysis, documentation, validation and sign-off.  But do not stop at requirements sign-off…continue your stakeholder engagement throughout the duration of the project so that the expectations set in the Requirements phase remain the same expectations when you get to Verification and System Validation.