Subscribe via RSS Feed

Tag: "software requirements"

The Requirements Session Has Started. Do You Know Where the Business People Are?

When it comes to software requirements definition, engage the business … early, often and methodically

ClassroomLast week, I shared the results of a recent survey taken at a IT trade conference on the role of business in driving software requirements. Most of the people taking the survey stated that they consistently struggle in two areas: Connecting with the business and managing requirements throughout the development cycle.  They also admitted that at least part of their requirements process is broken.

This week, I’ll provide some thoughts on how to pinpoint some of these broken processes.

 

About to Start Requirements? Read this First.

During the requirements phase of a project, expectations and confidence run high. However, this is also the phase where lack of best practices begins to undermine success and worst practices rise to the surface.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics.

Before you start the requirements phase of your next project, take an important first step by looking very closely at the “condition” of your people, processes and metrics. In his white paper, “Doing More with Less: Best Practices for Processes, People and Metrics” [PDF], Geneca Vice President and Managing Director, Bob Zimmerman, suggests asking the following questions to draw out areas in need improvement.

How do you work with the business?

  • Do all business stakeholders agree on the goals of the project?
  • Who owns defining requirements? Is this different from who owns “documenting” requirements?
  • How do you know when a particular part of a project is complete? How do you know when the overall project is complete? Does your team have this information and does it align with business objectives?
  • In general, after collecting requirements, are Change Requests introduced during the first 30% of the development lifecycle?

How do you track projects?

  • Do project status reports show progress in terms the business understands or is it in “IT speak” requiring translation for the business?
  • Is project success determined by being on budget? On schedule? Meeting the original business objectives and ROI? Which one?
  • Does your team use one internal project tracking report for status while the external report is different? Or is there a common report showing progress on the project?
  • Do business and IT team members typically have a consistent view on project status and health?

Are project roles and responsibilities clearly defined?

  • Is there a single person and role accountable for technical issues?
  • If you deliver a solution that works but is missing key features required by the business, is there a single individual and role that is accountable?
  • Are your project managers accountable for tracking progress and making project health visible? Are the responsibilities for this role consistent across all projects and project managers?

By answering these questions, you should be able to hone in on the areas of your requirements practices most likely to impact your ability to satisfy business expectations.

For successful requirements definition, the various players need to be involved in ways they might not have been before. If the business is not 100% committed to making this happen, even the most talented development teams cannot predictably give the business what it needs.

Organizations that hold the business stakeholders accountable to define their needs enjoy better results. These teams do a better job eliminating guesswork and rework, supporting change control, improving testing efficiencies and, most importantly, delivering exactly what the business wants.

Changing the Conversation on Software Requirements: Collaboration in the IT Team

motion gears -team forceDelivering Business Value is a Team Sport

Last week, I talked about how to change the conversation of better software requirements from creation of the “perfect” requirements documentation to establishing joint accountability between the business stakeholders and the IT team for the success of the project. This week, I want to talk more about how this approach can carry into the detailed phase of the project.

In July I attended my company’s “Tech Talk”.  My company, a software development company called Geneca, regularly holds Tech Talks to give employees the  opportunity to share technology information. Even though I am no longer particularly technical, I like to attend these sessions in order to keep up on the technologies that my peers and the industry are using.  At the last Tech Talk, Chris Johnson (one of the developers) spoke about a high-productivity web framework for Java development. I know – you’re asking “what does this have to do with better requirements”.

What really excited me about Chris’s talk (since I didn’t really understand all of the coding detail) was when he explained that one of the big advantages of using this technology was that he could partner with a Business Analyst (BA) during the requirements process and actually create web prototypes while the business was explaining what they needed.   The business stakeholders could see how the team was envisioning delivering the solution and give immediate feedback. The developers would also get a head start on the code for delivering the solution.

To me, this was an excellent example of how the entire IT team can work collaboratively to deliver true business value. My co-worker wasn’t holding the BA solely accountable for ensuring that we had the correct requirements.  Rather, he was making the conversation about ensuring everyone was accountable for understanding what the business really needs and for delivering business value. And, by working together, all parties (the business stakeholders, the BA and the developers) can better share a common vision of the solution.

Think Beyond the Requirements Document

I have worked in other environments where the BA would have been threatened by the idea that a developer could create a working prototype during requirements definition. By including the developer (or a PM or a tester) in the requirements process, there might be fear that the BA role would be devalued. But, a good BA needs to understand that the role of requirements definition is not just in the realm of the BA. In fact, ownership of the requirements really belongs with the business stakeholders. The role of the BA is to help communicate the business vision to the rest of the team, by whatever means works best.

Rather than focusing on the requirements document as being central to their existence, the BA needs to find the best vehicles for communicating the business vision to the rest of the team and for ensuring that the team works together to deliver what the business expects. This can be through written requirements, through diagrams, or verbal communication. Or it can be by including other team members – the PM, the developers, QA tester – in the requirements process so that entire team understands the vision and is focused on delivering business value.

When everyone on the team is working collaboratively and holding each other accountable to meet the project’s business objectives, then the project will be a success – regardless of whether the requirements documentation is perfect.

How does your IT team insure that they are delivering business value?

Changing the Conversation on Software Requirements: The Role of Business and IT

What, Truly, Is the Role of a Business Analyst?

Arper-Aston-Office-Chair-IncaseRecently I came across the question “is a written [software] requirements document really necessary?” in a Business Analysis forum. I found the question intriguing and had to look at the discussion around the topic. A lot of the discussion revolved around methodologies (Agile vs. Waterfall) or around requirements techniques (diagrams vs. words). One responder claimed that “the creation of the requirements document is central to BA’s business existence.”

I was bothered by this direction of the conversation. To me, if “the creation of the requirements document is central to their business existence” then the Business Analyst (BA) is not focusing on the right way to improve requirements or to ensure project success. To me, what is central to a BA’s existence on IT projects is to focus on ensuring that the team is providing the agreed to business value for the client. Any documentation is simply one method of communicating the business need and what success looks like to the business stakeholders.

Poor requirements or scope creep are often listed as top reasons why projects fail. We’ve all heard statistics, such as, “more than half of all IT project fail to meet the business requirements”. At a recent webinar hosted by Geneca and Forrester Research, the Forrester analyst pointed out that finding and fixing a software problem after delivery is 100x more expensive than finding and fixing it during the requirements or design phase. Obviously there is a need to ensure that the requirements process is successful.

Think Beyond the Documentation

However, is creating “better” documents going to provide this success? Is more and more documentation going to provide this clarity? Is developing the “perfect” template going to solve the problem with requirements? If the focus is only on improving the requirements by creating better documents or providing more documentation, then I believe that the team is missing the root cause of why the requirements need to be improved.

Most of the BAs that I have worked with are competent and create readable documents. Although they work diligently at capturing all the project requirements, projects can still go awry. The business complains that IT isn’t delivering what they asked for. IT complains that the business doesn’t really know what they want. Business stakeholders “sign off” on detailed requirements documents without really understanding their content. Development teams create software without really understanding what it is that they are delivering.

Perhaps what we need to do is to make the conversation about understanding what needs to happen in order to accomplish the goal of providing true business value. To do this, the business stakeholders need to be accountable for defining what is of value to them – defining what success means. And, all of the business stakeholders for a given project need to be aligned on what success for the project means. If the stakeholders don’t have a common vision of what success for the project means, how can IT be expected to deliver a successful solution?

Create Clear Accountability for the Definition of Success

Likewise, IT cannot tell the business what success is. It is not their job to tell the business what they can and cannot have. The IT team needs to be accountable for listening to the business stakeholders, understanding what success is from the business’ perspective and then communicating what it will take to deliver to that vision. IT can offer alternatives and suggestions on ways to deliver to the business’ vision in a timely, cost-efficient way. But, ultimately the business stakeholders own the decision on which alternative to accept. The entire team – both business and IT members – are then jointly accountable for the success of the project.

In this environment, the role of the BA shifts from just being a creator of documents to being accountable for communicating this common vision to the IT team and helping ensure that they provide a solution that meets the business vision. The requirements documentation becomes just one of many vehicles to help accomplish this goal, not the end goal of the role.

What is the expectation for the BA in your organization? Are you expected to be a documents creator or to take a more active role in ensuring that the right solution for the business is delivered?

Next week, we’ll talk about how to carry the common vision throughout the project in order to deliver a solution that truly delivers business value.

Photo Credit: Incase

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