Subscribe via RSS Feed

Tag: "software requirements gathering"

It’s 10am and the Requirements Session has Started… Do You Know Where Your Business Team Is?

Requirements-Session-Has-StartedWhen sharing Getting PredictableSM best practices, specifically around requirements definition, a common question that comes from I.T. management,  Business Analysts and Project Managers is:

“How do I get the business to come to the table? How do you get the business folks to commit to the time needed to properly collect requirements for a project?”

 

Most business folks are very busy, but the underlying problem is more than just time management.

Many business users feel it’s a waste of their time. It’s truly annoying to have to tell the “tech folks” requirements. They’re gonna get it wrong anyway.

And you can’t really blame them.

Let’s picture their world:

You’re working 8+ hour days doing your full time business job. You have plenty of regular weekly meetings you go to, some that are a waste of energy.  Now your boss tells you the tech team wants to meet to ask: “How you do your job” or “What features would you like in the new system”.

You show up and as you start sharing your thoughts, they keep suggesting a better way. At times, you hear things like “what you are asking for is very complex – or is undoable”.  A bit frustrating, but you trudge on.

The Requirements Sign-off

Then the business users are asked to read the requirements and sign off.

First off, some of the documents read like a technical manual for a Sears Washer and Dryer explaining how to disassemble the drive motor and replace some fan belt so your washer doesn’t make that whining noise anymore.  The part of the documents that do make sense to you are sort of right – but you’re not sure how much effort to spend to get it 100% perfect.

This might be a little exaggerated, but go ask your business user to read the above paragraph and listen to what they say.  Many will surprise you with their feedback.

Over the next couple of months, the I.T. team asks a few clarifying questions here and there and some of the questions have no resemblance to your original requirement.

When you get the new software, it isn’t what you asked for.  And the technology team is combative. The I.T. team is saying your requirements were wrong and that’s why the system doesn’t work properly.

Surprised?

Hmmm… Why in the world would the business want to experience this?

While  a little exaggerated,  I have to admit that over my career I have heard business users say this.  There is some truth to these remarks and they represent obstacles for our teams.

That said, there  are some simple ways to get the business to check in and truly get passionately involved. Here are some quick ideas to point us in the right direction:

  • First and foremost, Listen.

The joke I share with my technical leads is that “Before we might say ‘no’ to a particular feature, at least listen to their entire request. Then you can say ‘no’”.

And yes – this is intended to point out that all too often, we start compromising a requirement because we know the business better, or their way takes four weeks to do and tweaking the requirement can get it done in one week with an off-the-shelf product. We need to listen to their full need and the “why”.  Then you can be a partner and offer them options.

This brings me to the second suggestion.

  • Give them Options.

Don’t simply tell them the system can’t send the data to all 123 data centers and get responses in under 30 seconds, assimilated in 14 languages and then graphed real time.

Explain to them this one requirement may take two years and 24 people to pull off and that if they would be willing, here are two or three alternatives that may work and would take two months to get completed. Ultimately it’s their budget and their choice on schedule.

They will feel less like something is being “done” to them and more like you are truly trying to help them through this process.

  • Finally, Give them what they asked for and Quickly.

What I mean by this: If they asked for a special screen to do a quick side calculation, and you see they have energy, create a quick mock-up or even a prototype and ask if this is what they had in mind. Make sure you don’t embellish. Give them exactly what they asked for.

If you have a great idea, then show them a second version of the mock-up after you showed them theirs. Let them buy into it.

In an iterative world such as Agile, it is part Agile to quickly turn around a requirement for user feedback.  Even in Waterfall, you can create anything from paper prototypes (see my previous Lo-Fi post) to a wireframe or real code for those scenarios that the user was really passionate about.

Before you know it, you’ll need a bigger conference room for your requirements meetings because all the different business stakeholders will want to come and give you “their” requirements. They won’t trust their colleagues to represent their opinion.

Do you have issues getting the business to come to your requirements sessions? How do you deal with it?

Requirements Processes: Welcoming Base Level Users to Participate

Doors-ImageNow that we’ve established the advantages of software requirements sessions leverage base level users: we have to address  two very important issues: Are these individuals ready to participate in the requirements process from day one? What can we do to prepare them to do their best? Here are some ideas that I’ve  found to be easily implemented and highly effective:

Start With an Expanded Kickoff Session
Many business analysts find it valuable to have a requirements kick-off session for individuals with no previous requirements session experience. This gives them the opportunity  to describe what is expected during the process and get everyone familiar with the terms, concepts and technologies used on the project. For example, if the project is taking an Agile approach, include a description of what Agile. This helps base level resources feel more involved with the project and prevents them from checking out during the requirements sessions when unfamiliar items come up.

Empower for Best Results
Base level resources often have a wealth of knowledge that BAs are eager to capture. However, some base level users find that participating in a new process and working side-by-side with executive  stakeholders is a little unnerving. One way to encourage the base level resource to speak up is to explain that the reason they’re involved in the requirements session is to correct inaccuracies and provide their viewpoint of how things work.

Clarify Obligations
Participation in requirements sessions often requires “homework”. Be straightforward about action items that may be required during and outside of sessions. Make sure that time commitments are confirmed prior to the kickoff meeting. If the BA thinks of questions that need to be answered prior to the next session, he/she should have a process for tracking and obtaining such information.  Some techniques that have proved successful include giving due dates for assigned items and keeping a list of all requested items and their status.

Emphasize the Value of Participation
While participation in requirements sessions involves time commitments, there are tangible benefits. Participation results in more education on the technology used in the solution and enhances the use of the finished product. For example, call center representatives involved in the design of a CRM solution are better equipped to use the technology from day one and train other representatives.

Building the Ideal Requirements Team
An ideal requirements session should include diverse resources who collectively provide the  authority to make business decisions, insight into business strategy, and knowledge of end user needs and business operations.

Using a base level user is a cost efficient  way to broaden the perspective of the business stakeholder group to include operational knowledge and end-user feedback. Plus, base level users involved in the requirements solicitation process get up and running more quickly and experience business value faster.

If you  use base level resources in your requirements process, what advice would you give to others to get the most from their sessions?

Photo Credit: Eduardo Zarate

Uncovering Hidden Software Requirements

 

823004299_42b6abf953_z-232x300Base Level Users in Requirements Gathering Sessions Can Yield Gold

The need is clear for business people to be part of requirements definition – that is, understanding the intent of the system and creating a common definition of success. Once that course is set and specification begins, how can we ensure we’re getting the right details to accomplish those goals?

Today, the idea that a software team can gather requirements without direct participation from the stakeholders who can speak for the user is outdated. Receiving sufficient quality customer input — along with the business stakeholders — makes a direct impact on a software teams’ ability to predictably deliver business value.

I have found that business stakeholders are not necessarily equal, interchangeable resources. For example, consider a requirements session where the stakeholders do not have the authority to make business decisions. Or, a session where the stakeholders lack sufficient knowledge of business processes. And then there’s the case where  the stakeholders have the authority and knowledge of business processes yet the solicited requirements are still incomplete. So what’s wrong with this picture?

Probably what’s missing is the perspective of a resource who has knowledge of business operations and is also an end user of the existing process or the new process being designed. A base level user who knows not only how the system actually works from the ground floor, but also knows about the undocumented bugs — and the work around to get from A to B — that the current system may have.

Adding base level users brings an important perspective to the requirements session and improves the quality of business information and project implementation. This resource is not only cost effective but typically has more availability than the stakeholders who wield the power to make business decisions.

The Benefits of Using Base Level Resources

There is a wide body of knowledge regarding User Centered Design, which emphasizes the value of using end users in the requirements process. After all, these are the people who are using the current solution that is being replaced or will be physically using the new solution on a daily basis.

Users involved in the design of a solution from the beginning understand how that solution works and are better equipped to use the solution after it has been developed. The User Acceptance Testing process is also enhanced when the base level / primary end user is involved in testing, satisfying one of the key goals of User Centered Design.

Hands On Knowledge of Operations

Base level resources are often essential to the requirements process because they have knowledge of ground level businesses operations that other resources are often unaware of.   Jason Prine, owner and  Principal Business Analyst at JPx2 Consulting Inc., describes these resources as the “folks who work in the weeds everyday … and are essential to any successful project.”

It makes a lot of sense: Having the appropriate operational requirements goes a long way in making sure the end product satisfies the needs of the user. This also prevents requirements from addressing only things as they should be rather than how they are.

 

Next week I’ll share some ideas on how to welcome and prepare base level resources into your requirements process.

Does your requirements gathering process routinely get input from base level users? What effect has it had on your team’s ability to quickly deliver business value?

Photo Credit: Angelo Juan Ramos