Subscribe via RSS Feed

Tag: "software requirements definition"

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.


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?

You Guys Start, We’ll Figure This Out Later

Ready Set GoWe’ve all experienced a project that is kicked off just a bit sooner than maybe it should. You know this because you hear those infamous words:

“You Guys Start,
We’ll Figure This Out Later.”

Consider this simple phrase a warning sign that your project is in danger before you even start. The business team is still trying to figure out what they need. Yeah, they know their problem is clear but the solution is anything but.

So what’s behind this all too familiar call for help?
Lack of Alignment.

What the business is really saying:

“You Guys Start and We’ll Get Aligned. Right Now We Can’t Agree.”

This lack of alignment is almost always due to the business stakeholders’ struggling to determine and agree on what “success” is. This can apply to a product implementation, customer software development or even a change in business processes.

Some disagreements can be on the large scale:

Should our first release of tax planning software only focus on Federal tax strategies or must it support State tax planning too? If it should, which State? All 50? Isn’t that going to take forever?

Should we develop a full suite of open source Office type products including a word processor, spreadsheet, Powerpoint like tool? Or should we simply focus on our core offering, the presentation tools?

Some disagreements appear less strategic:

Does the solution have to support our customers in four countries and be localized in six languages? Or can the first release simply support our current client base?

Should our solution include a Spellchecker for the medical terms that we will collect in our survey tool?

“You Guys Start, We’ll Figure This Out Later” = Less Than Successful Project

In spite of this warning, the project needs to start. So we begin our planning and whenever possible, hedge our design to accommodate change. But, in the end, how likely is it that we deliver what they, the un-aligned business stakeholders, fuzzily define as success?

More often than not, they never get aligned. And if a new business person gets involved, who knows what their view of success is. At the end of the day, we are responsible for a potential “less than successful project”. Hmmm – they may even call it a failure!

And this shouldn’t surprise us! In fact, if you hear the words “You guys start…”, that should be a predictive flag that you may be setup for failure.

The message is clear: The Business needs to own the risk of having an I.T. team start without alignment among the Business. And the Business along with I.T., needs to jointly own and collaborate on how I.T. will re-plan once the business has completed their work by finally agreeing on what is project “success”.

What About Agile?

When I share these ideas with colleagues, I typically get two reactions. The first includes smirks and smiles saying: “Yep – we’ve heard that and you are right, it is painful.”

The second reaction comes as a challenge: “Wait – isn’t that what Iterative development is all about? The business can plan and change direction with every iteration?”

The assumption is that Iterative methodologies such as Scrum or Agile, can be an effective way to solve nonalignment situations. They break up a project into small durations (iterations) that focus on specific feature sets. An iteration may be as small as a week, but may be defined as large as four weeks. (You’d be surprised at how much energy this last point generates.)

This is often considered a safe/natural solution because at the beginning of each iteration, the business will look at the list of everything they want and define the target features they would like the team to work on for the next iteration(s). This re-planning allows the business to change its mind and adapt based on feedback and potentially changing business conditions.

An Iterative process doesn’t resolve alignment issues!

But we still have a problem here: The Business Stakeholder who kicks off each iteration is now accountable to determine what “success” is for that iteration. If they aren’t aligned with the original/other stakeholders, then they are actually steering the ship off-course. And there is NO visibility. The rest of the stakeholders may not even know what decisions and tradeoffs have been made within an iteration planning meeting.

But wait Bob! When we do an Agile project, we always have all stakeholders in the loop about which features were completed and what will be planned for the next iteration!

And to that I say: You are not the norm! So congrats!

When most organizations embrace Agile, they are focused on the core I.T. team, planning and execution. They don’t have a model for how this changes the behavior of the business stakeholders in their planning and management of initiatives.

True, we tell the business folks we want them in the room with us, giving us quick feedback, etc. But what we often don’t do is explain to them that this level of feedback requires them to constantly re-baseline what features are “in and out” based on their goals and budgets. There is no formal process for shifting this ownership over to the business.

So what’s the point?

The fact is that more often than not, a project will be started after hearing: “You Guys Start, We’ll Figure This Out Later”. It is the nature of business and politics. In fact, as I illustrated above, our iterative processes can almost “enable” a lack of alignment.

It’s important for us to set goals for the business to do regular “alignment-check-in”. We need to make sure the business owns and is accountable for understanding what they are asking for, and what changes have been made.

We should strive to eliminate the surprises at the end of a project where a business stakeholder asks:

  • Where did this feature come from? or
  • Why is this functionality missing?

Even if we followed the requirements to the letter.

So what do you think? Do you disagree? If you agree, who do you think should be accountable for managing this within your team? Within the business?

What Abbott & Costello Can Teach Us About Software Requirements

Whos-On-FirstGrowing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube.  Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in  the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we  can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether  “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link.  I recently came across another short video that is a modern day technical version of “Who’s on First”.  I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

The Vaccine Approach to a Software Development Project: Quality Assurance as a Value Added Partner

Syringe-1Last week, I talked about the risks that go hand-in-hand with the Bandaid approach to software quality assurance.  With the vaccine approach, software quality assurance is not seen as overhead or a bottleneck. Instead, it is a value added partner that brings transparency and visibility in software development predictability.

Significantly different than the Band-Aid approach, in the vaccine approach the software quality assurance team is dedicated, full-time participants within software development teams.  They are co-located and work collaboratively with both the business and developers.  Acceptance criteria is defined in collaboration with the business and integrated with requirements.  This provides significant advantage over the “Band-Aid” approach to testing, both within projects and across the enterprise application portfolio.

The Vaccine approach to software quality assurance provides more than operational benefits. It strengthens both the delivery team and the quality assurance function overall.  Being embedded with and dedicated to a development team, software quality assurance people are immersed in the business problem as well as the solution while it is being developed.  Being fluent in the application, a tester is more likely to recognize the difference between an application failure and an environmental or situational blocker, and better prepared to correct the situation.  As a result, they are less likely to raise false defect reports that create “noise” that masks the state of application quality and impairs team efficiency by wasting other people’s time in disposition.

This approach also protects quality assurance leaders.  When able to work only part-time in any given project, software quality assurance can do little more than produce testing artifacts and perform tactical execution. Working in full collaboration with a project development team, however, allows the software quality assurance team to gain deep business knowledge.  A quality assurance team that is immersed in the problem domain is in good position to be IT knowledge workers.  This makes them better business problem solvers, and stronger participants in IT solution delivery overall.

Engaged Participant vs. Disengaged Auditor

The intended deliverable of any IT project is a technically sound, functionally fit business solution.  This is achieved through the engaged participation of all IT disciplines, including infrastructure, requirement, development, and quality assurance.  By only playing the role of auditor, the quality assurance team is a disengaged member of the solution team that certifies an application as production-ready.  Alternatively, by collaborating from the early stages of the software development lifecycle, and executing quality assurance continuously throughout, the software quality assurance team works as a value-added partner that directly contributes to an increased understanding and gradual evolution of a business solution.  Ultimately, this approach increases both the value of software quality assurance and the return on IT investments.

What steps can your team take to move from a bandaid approach to a more holistic approach to software quality assurance and testing?

Photo Credit: Andres Rueda

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

If Quality Assurance is intended to be a vaccine to projects, then why is it so often being used as a Band-Aid?

BandAid-1In our daily life, we take preventative measures such as flu vaccines early in a season to avoid, eliminate, and/or to reduce chances to get sick. This is similar to QA being part of a software development project early on in order to reduce defects and minimize project duration and cost. Unlike a conventional testing approach–which merely reacts to whatever has been designed or developed and frequently is perceived as interfering with development)–QA’s role early in the Software Development Cycle helps improve predictability and makes development faster, and less aggravating.

During my career, I have seen QA teams that are “shared resources” supporting many projects simultaneously rather than dedicated to specific projects.  Huge armies of QA teams execute defined test cases/scripts to test and certify an application once development is complete.  Because QA team members lack application familiarity and test only at the end of the development lifecycle, they require significant execution support. Often, the feedback they provide is late in coming and often inaccurate.

The Value of the Vaccine Approach

Compare this to a vaccine approach where the QA team is dedicated for the duration of the software development project and testers are co-located with the business and development team.  Because they collaborate with the development team on formulating acceptance criteria and engage in testing continuously through development, they can spot the commonly-overlooked showstopper problem. Now, QA feedback is considered as timely and relevant and a value added partner in delivery. This increases the efficiency of the software development process and the effectiveness of solutions produced.

We all have our examples of exciting projects turned into nightmares. Creeping deadlines, tsunamis of defects, applications that fail to deploy or performance bottlenecks that just cannot be found. Unfortunately, these kinds of situations always occur at times when they are least welcome – right before the project deadline, during the holiday season or when you had planned that nice weekend getaway. Most of these nightmares can be eliminated if QA is considered a vaccine for the project lifecycle rather than a Band-Aid fix.

The Risks of the Band-Aid Approach

There are many operational risks with Band-Aid approach.  It assumes that the test cases are of high quality, and that feedback is timely and actionable.  These are unwarranted assumptions.  Like any IT artifact, test cases may be ambiguous or confusing to testers (of poor technical construction) or they don’t test what needs to be tested (of poor functional construction). Since QA leads are shared across several applications, there are chances for error in writing test cases.  Being part-time on every project, the QA team is forced to work independently from the development team.  Test cases/scripts are often written to abstract specifications in the early stages, before software is ready to be tested, and executed in much later stages of a project once development is complete.  They are not written in conjunction with the development of the software, or in full collaboration with development.  Also, the development team is often not made aware of specific QA and UAT acceptance criteria, nor does it receive testing feedback, until very late stages of a project.

There is financial risk as well.  This approach emphasizes unit-cost efficiency of test execution over a holistic approach to quality assurance.  On a test-cases-that-can-be-executed-per-person basis this model looks attractive, but to be cost-effective, there must be low overhead of execution.  The greater the effort required to stage testing activity (e.g., with test data or instructions to carryout testing), or to interpret the results of testing performed, the greater cost of execution.

What approach does your IT organization have to QA?

Next week, I will take a closer look at the benefits of a more holistic, Vaccine approach to QA and testing.

Photo Credit: Guerrilla Futures | Jason Tester

Everything I Know About Software Development I Learned from Elephants

The Swiss Army Knife of the Animal Kingdom

Elephant-2Last week, I talked about the importance of introducing the elephants in the room.  So now that we have the elephant in the room, let’s examine it and see what we can learn from elephant behavior and how we can apply it to software development. The irony of the “elephant in the room” metaphor is that it suggests that elephants are these large, bulky creatures that are imposing and not dynamic. In fact, elephants are one of the most versatile mammals on this planet. The elephant’s trunk is used to tear up food, so the elephant can digest it. It is a hand that can grasp objects, a means of drinking without having to bend over, and a way of  spraying mud on themselves to protect their skin from the sun. It is even used as a tool for  social interactions, to enhance their highly developed sense of smell, and to defend themselves from predators.

To deliver software predictably, we need to become dynamic, adaptable creatures as well. As the speed of technology gets faster and faster, we’re going to have to give up the idea of just doing one or two things really, really well. We’ll have to be like the elephants’ trunk. We have to know the foundation of coding, but not be married to any single language. We’ll need to understand the best practices of project management, but be flexible in our methodology and apply the best methodology to the best practice. We will need to master requirements facilitation, but have many different tools to gather requirements and to custom fit the requirements process to the appropriate projects.


Even We Can Become Extinct

If we are rigid and only do things one way, technology will pass us by and we’ll become extinct. However, if we are adaptable with our tools, practices, and methodologies, we’ll continue to evolve to meet the demands of business using the best that current technology has to offer.

In the past, the slower speed of technology may have meant that a method and tool would be useful for many years. In the fast pace of technology today, it is never the case that we can say that any idea, method, or tool works every time. We need to be constantly transforming ourselves, our ideas, methods and  tools to confront new challenges.

We may come to find more and more that projects are changed or canceled once we have gained momentum. Perhaps what made business sense when we started the project no longer makes sense due to new technology which has changed the marketplace. Rather than letting this disturb our equilibrium, we should begin to develop habits that allow us to shift rapidly and be adaptable to such change. Those in technology who can rapidly adapt will excel in tomorrow’s marketplace.

Being flexible and adaptable isn’t easy. It requires us to constantly let go of things that we know as true. Something may have worked for us before, but it may not work now. Or perhaps we have a perfect tool in mind for the job, but our client has a tool they like more. We have to let go of what has worked in the past for what it will take to accomplish the challenge before us.


And Maybe Dumbo Wasn’t That Far Off Base

One last thing we can learn from elephants is to use our big ears. Disney’s portrayal of Dumbo, the elephant with ears big as wings, wasn’t that far off base: Elephants have huge ears and an exceptional power of hearing.

As a predictable partner, we also need to always be using our ears. Not just to listen to what our clients are saying, but to really understand the meaning of what they are saying.

We can do this by maintaining a curiosity with our clients and what unique strengths and issues they have. Listening is a good first step, but when we are curious about our clients’ strengths and issues, then we have motivation to not just hear, but to understand.

Also, using our ears helps ensure that we are speaking the same language. It ensures that we are talking apples to apples and oranges to oranges. Our active listening helps our clients to know that they are being heard.

So next time you pop in the Disney classic about the elephant with the big ears, take note. Just like the underdog elephant who learned to fly, we can also use our ears to help us find success  with our teams and clients.

Software Requirements: Are The Business People With You?

The Role of the Business in Driving Software Requirements Definition

Many of us believe that the single hardest part of building a software system is deciding precisely what the business needs. No other part of a project has as much impact on the final outcome as requirements definition. Yet, the requirements process often ends up as the area most lacking in best practices.

I recently participated in a survey of IT executives at a Chicago trade conference. Some of the results of the survey were what I expected and some were surprising. But either way, the results are very relevant for teams looking for perspective on their own development practices. This week, I’ll report some of the basic findings of the survey.


Most of the executives in the survey recognized the importance of accurate requirements and admitted to routinely struggling in two areas: Connecting with the business and managing requirements throughout the development cycle.

Key Survey Findings

  • 94% of respondents acknowledged that the quality of requirements is a leading factor in the success of their software projects.
  • Over 70% acknowledged that there is room for improvement in their requirements practices.
  • 75% agreed that better articulation of business and IT roles/responsibilities in requirements gathering would go a long way toward improving project outcomes.
  • While most admitted that the business has at least some input with requirements definition, requirements are often unclear.
  • Over 80% of respondents indicated that they do not learn about missed requirements until too late in the project development cycle.
  • Only about half of the respondents felt that business and IT teams have a consistent view on project status.
  • Over one third of respondents stated that progress is not consistently tracked in business milestones, resulting in rework and missed deadlines.


It’s Unanimous: Business Involvement Has a Big lmpact

It is not uncommon for business stakeholders to “throw their requirements over the fence” and expect to come back later to a successful working system. In practice, however, this approach leads to rework, project delays, cost overruns, and other disappointments.

Although the degree of business involvement varied within the survey, respondents overwhelming agreed that when the business is directly held accountable for clearly defining their needs, project outcomes improve. Respondents also mentioned the need for better articulation of business and IT roles and responsibilities in the requirements process.


Business Milestones: Now You See them. Now You Don’t.

Another big area of concern for survey respondents was managing requirements throughout the project.  Most agreed that project metrics must define progress and value in terms the business understands and appreciates. Approximately 50% reported that business and IT teams in their organizations share a consistent view of project status.


Another important benefit of using common metrics is more awareness of when requirements are due. All too frequently, IT learns about missed requirements too late in the development cycle.

In the case of the survey, all agreed that it is critical to find out as early as possible whether key requirements are missing. However, most respondents indicated that they become aware of missed requirements during User Acceptance Testing (UAT) or after deployment.

What level of commitment do the business stakeholders have in requirements definition in your organization and how does this impact project outcomes?

Next week, I’ll write about some of the steps you can take to pinpoint the areas of your organization most likely to interfere with your ability to satisfy business expectations.

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