Welcome to our call today, The Software Requirements Paradox, “Traditional Requirements in an Agile World.“  My name’s Jeff Cohen; I am CEO and co-founder of ProcessExchange.  I’ll be hosting this interview today.

Our interview guests are Michael Hugos, CIO at Large, and Keith Barett, Director of Professional Services at ProcessExchange and requirements expert.  Thank you both for joining us today.

For our audience’s information, a little background on both Michael and Keith:  Michael has been recognized and received four awards since 2003 by CIO Magazine, Information Week, and Computerworld Magazines.  He’s also an author and columnist in the Computerworld and CIO Magazines and an avid writer.  His books, Building the Real Time Enterprise, and CIO Best Practices, Enabling Strategic Value with Information Technology are popular reads in our industry.  CIO Best Practices has recently been published, and I want to congratulate Michael on completing that.

Keith Barett is Director of Professional Services with ProcessExchange, and he spent over the last 15 years a focus of improving requirements, development, and management processes for many Fortune 500 companies and also many mid-market companies.  At Bank of America, Keith led a special team focused on reuse; and that work has been featured in Application Development Trends, Computerworld, and Object Magazine.  He’s also an internationally-recognized speaker on the subject, and I would like to welcome Keith, as well.

So, why don’t we start our conversation out with a very simple and important question.  Hey, guys, what’s the difference between a business requirement and an IT requirement?

You know, I think it really comes down to who you’re… it’s the same requirement.  It’s just two sides of the same coin, and the side you show depends on the audience you are communicating with.  We all agree the place that systems start is with the business folks; so I believe you start your requirements, your system requirements, with the business version of those requirements.  Then, they get translated into the technical side; and for my money, the business version is very graphic in its format because, as we all know, a picture is worth a thousand words; and business people are busy, and they can appreciate the graphics.  They can absorb the content much more quickly, you can get the kind of interaction that you want with them, and then later on when you become more technical, then you can introduce more words because then you need to be more specific.

Sure.  Certainly, two very different vantage points to the same requirement as Mike was leading to.  The business people are simply defining the objective that the business needs to accomplish.  These are typically stated in high-level business-like language; as such, they are not technically detail oriented.  We couldn’t, for example, create a list of business requirements and simply give that to a developer and say now, go build me a system.  That would be equivalent to going to a construction crew and simply having a conversation with them around what you would like to see in your house and then expecting them to go build that.

On the IT side of the fence, they are, obviously, looking for all of the specific detail that goes into what is required for them to build the parts and pieces in this system.  So, we see this big gap between what we typically get from the business person, a very high-level objective of the business, to what the IT person really needs to be able to build that system from, which are very lower-level technical requirements that give them the bites and bits of information that they need.

That’s correct.

Well, certainly you’re describing the key aspect and the role of the business analyst, and that’s to be a translator.  Whether you are going from Japanese to English or any other language, it really boils down to the skill of the analyst and their ability to understand both sides of that language.  They need to be very good at business speak and very good at the technology speak.  I think what we are seeing a struggle with in the industry right now is that, although business analysts may be good with both of those, they’re still depending on text as the primary means of describing what it is business people want.  That’s forcing us to write lists of business objectives and then refine those into more lists of textual user requirements and so forth and so on we go.  The dilemma we are still having with text is that text is very subjective.

Keith, you used the analogy of you were going to have some people work on your house; and that struck a chord with me because I did do that a couple of years ago.  I spent a boatload of money on rehabbing our house, and the experience of working with the architect has actually given me a lot of insight into how a good business analyst works and what good business requirements look like.  That’s why I keep coming back to their visual because the architect, who in some ways is playing a role very similar to the business analyst because that’s the person that sees both sides.  They see me, the user; they see the construction folks who are actually going to develop what we designed; and the architect works in a real graphic format.  They drew pictures of what the rooms would look like.  They drew floor plans.  I could look at those pictures, and I could say I like this; but see this room here, it’s too small, and I want another window on the east wall, or something like that.  It was the pictures that I could respond to.

If they had done the same thing, and they did actually, along with the blueprints came a 200-page printed spec; but if they had asked me to read through that 200-page printed spec and then sign at the end; if they had even started the interaction, if the architect had started the interaction with me, by sitting on the other side of his desk with a notepad and began asking me would you like a door?  Would you like a window?  These are incredible, and these are very, as the Brits say, offputting.  I mean, all of a sudden now, this is an adversary relationship.  All of a sudden, this is if I am being interviewed by a local detective from the police department.  All of a sudden I’m feeling uncomfortable, I feel everything I say will be used against me.  That’s the predicament that business people wind up in.  Then, we produce lists.  Then we ask them to sign it as if they’ve now just made a confession, and now we’ve got them.  So, it’s no wonder that things get so tense.

What I hear you saying, Mike, is the business analyst is often doing an interview.  It’s often one on one, and it’s often creating a wall.  You’re creating an adversarial relationship when you do this one-on-one process; and it’s also, I’ve seen often, more difficult to go back and clarify something from the business.  The business analyst finds himself trying to squeeze a question in, maybe they are ready to get an answer to an e-mail, maybe they’re able to catch someone by the coffee pot and ask a quick question, wherever they can corner them because what I’m seeing happen and what I’m hearing from you is this big interview happens and the business customer says aw, finally, I’m done with that.  I don’t want to deal with that anymore.  I need to get my job done.  Then, when the business analyst needs clarification business user is not open to spending time with the analyst clarifying anymore.

Keith, what are some ideas that you’ve used in order to rectify those kinds of problems?

Now, are you advocating doing that one on one, or do you like the idea of doing that in groups?

I also find that that is a real skill; that is not a soft skill, it’s not just being nice to people, although there is obviously, some of that in there.  It really is drawing out in an hour and a half to two hour JAD session.  You can get more done than a week of one-on-one interviews, and let me use an analogy there.  When you do the one-on-one interviews, it is like interviewing the seven blind men who each touch the elephant.  You interview one guy, and he tells you the elephant is like a snake because he touched the elephant’s trunk.  You interview another person who touched the elephant’s leg, and he said the elephant is like a tree.  You interview another person, no the elephant is like a wall, etc.

The point there is that one-on-one interviews get isolated impressions on what the system should be and what people want, and then the business analyst is on their own to figure out how does that all fit together, whereas you have them all in the JAD session in the same room at the same time.  Then they each still have their own impressions, but you can work with them all right then and there to blend all those impressions together into something coherent; and that is where you get a lot of speed, and that is where you get a lot of buy-in because now you are not individually negotiating with all of them to accept some integrated version.  Now, it all happens right there in real time.

So, what we are talking about is now taking the business analyst and treating them, not treating them, but taking them and having someone in there that’s no longer in a maybe more administrative-looking role but having someone that is a subject matter expert; and you also need someone that’s come from an IT background, as well, if you’re going to be very effective here.  We don’t see that in most customers.  We see customers that have business analysts that come from IT, or they come from the business or that’s where they lean; and that’s where they go to, and they’re constantly writing the requirements in paragraph format.  They’re not really using management tools all that often unless you consider Word and Excel the management tool.  The effectiveness of projects is different.

I’ve heard the word agile a few times.  We’re starting to distill down into the notion, I believe, that the three of us have talked about in the past which is you’ve got traditional requirements management and development efforts and methods today; but to be really successful in this world where business and requirements are constantly changing, you’ve got to change the rules.  You can’t do a six-month project all in one iteration.  You’ve got to do it in multiple iterations; and I think, Mike, this is where the notion of the 30-day Blitz that you and I talked about on our last interview really comes into play.  Maybe you can extrapolate some of the concepts that we’ve talked about so far in this call and help our audience understand how that translates into a 30-day deliverable instead of a six-month deliverable.

Well, I think that we all actually do have a subset of skills.  I say that there are six core techniques that developers need to use, and those techniques are sometimes used more often by the business analysts, sometimes used more often by the developer; but nonetheless, all those six techniques need to be understood by everyone who is doing development and they are:  [1] The JAD Facilitation Technique, [2] Business Process Mapping, whatever technique you may use but a visual business process mapping; then [3] Data Modeling, once you see what the business process is, you can see what the data is that flows through that process, and you can create a logical data model so that again it’s graphic and business people can look at that.  Once you see what the business process is and the information that you are manipulating, you should be able to create the user interface.

I say [4] System Prototyping is composed of two pieces, the user interface and then the technical architecture on the back end because if you know what the user interface is now, you know what the process is and the data, then you ought to be able to start to figure out okay, what is the technical architecture I am going to use.  What is the hardware, the software, the database, the operating system, a package, what kind of, ... those things.

Then, if you know all of that, you ought to be able to create the [5] Object Model.  When I run development projects, I literally tell the programmers nobody gets to code until we create the object model first.  Running and gunning and cranking out code is kind of fun, sometimes, at least for the person doing it, but it never pays off.  It never creates a real asset.  It’s not something that another person can look at and easily pick up.  For agile development, you need that.

The last skill is [6] System Test and Rollout.  Those are the six.  People on the development project should be familiar with all of them and masters of some of them, depending on the role that they will play.  I would say that when you get into a 30-day Blitz, it is tight technique, using those six core techniques.  You know, in football, if you decide to do a Blitz, that means you already know the moves, you know the playbook; it means now you’re going to just move it, move it, move it.  Move quickly.  It doesn’t mean we’re all just running and charging down the field; it means we are now going to go into a mode where it’s actually in a way more disciplined than regular game playing.  Does that make sense?

It’s IT that takes the blame, right.

Keith, tell me something.  We’re talking about a pretty significant change in a lot of enterprise organizations in order to go from a traditional approach to an agile requirements approach.  How do you get there?

Yes.  The concept of reuse is a big concept.  As you’ve led to, I spent about three years at Bank of America focused specifically on the topic of implementing a component-based development approach for the particular department, about 500 people-sized department at Bank of America; and we were given the luxury of doing about a year-long study with four of us where all we did was study and learn about this concept of reuse and how to apply it.  There are a few key best practices we learned.

First and foremost, any effort in the area of reuse, be at the requirements level or the code level, it has to be very purposeful.  It has to be something that the organization really wants to accomplish because they see the benefit of it.  Also, that concept of integrating your people, process, and technology is very crucial.  So, if we want to bring those concepts into the requirements arena, for example, we have to stop thinking about requirements as merely a list of requirements and start thinking about the idea of a requirement asset.  A requirement asset would be something that ties together all of the different things, whether we’ve done it visually or visually plus text.

We need some mechanism that allows us to connect these things so that when the business decides to do the next project and they decide that they want to do withdrawal transactions [a requirement asset from the first project] in the second project, we can go to a repository of requirement assets and begin to say, okay, that’s 80 percent of what I need right there; so let me yank that out and all the things that went into building that requirement asset, the process model, the data models, all of those things that Mike spoke of earlier, we pull those out, and we begin to reuse those.

Creating that repository of reusable requirement assets is a very purposeful thing.  It is something we have to put a focused effort on.  Adding that type of mentality to the business analyst probably should become something that they do outside of a given project because you can’t deter that business analyst from the deadline of that 30-day Blitz or that particular project that they are on.  The organization needs to adopt a mentality that if reuse is important, we have to focus some effort and some resources on accumulating those reuse assets in our repository.

If there is not a PMO, but a smaller group that’s doing it, it sounds like we could have a conversation about things that can be done; and certainly, they can look at reuse products and technology like ProcessExchange has with Req-X in order to do that.

Mike, what do you think about the whole idea of productivity, changing the game of the role of the business analyst, and reuse?

I think the business analyst is the indispensable person.  Again, I wrote a column for Computerworld last month entitled, The Rise of the Business Analyst - Again; and it’s gotten some interest from readers; and what it points out is that many years ago, when I got into the business, we were all talking about how important the business analyst was because that was the person that would translate business requirements into technical capabilities.  Then, somewhere around about the middle ‘80s, even the early ‘80s, the PC hit the scene and upset the whole equation.  The mainframe, even the mini computer began to fade, and then the PC leads into client server, and then suddenly, we’re off to the races, and then the Internet hits, and man, for the last 10 years, we’ve been exploring all the cool things you can do with the Internet.

Now, what is happening is we’re getting used to this technology; and the question now comes back to that age old goal of okay, it’s neat stuff.  Now, how do we make money with it.  Again, I think that’s why all of a sudden the analyst is popping back up again because it is no longer the technology person, it is no longer just the person who delivers this gee whiz stuff; it gets back to that’s great, how do I make money with it?  The analyst is that person that makes it happen.

I don’t think that technology, ... we all know this, technology all by itself is not a moneymaker; it’s effective application.  By breaking up your projects into smaller pieces, focusing on what the business people know they need right away, I think it’s also very unfair to ask people, okay, for the next 12- 24- 36 months, what do you want, what do you need, tell me now, or forever hold your peace, which is what a lot of these requirements-gathering exercises are.  You know, come on.  It puts people on edge and makes them defensive.  They either have no ideas because you freaked them out, or else they give you a boatload of ideas; and then you wonder where scope creep comes from.  Well, where do you think it comes from?

Sure.  You know, even as I sit and listen to us discuss this, it’s also clear that as we’ve seen the evolution of the software development lifecycle and the different phases of that over the past few decades, every phase of the lifecycle has gone through its morphing and evolving process, except the role of the analyst.  Development is very different today than it was 20 or 30 years ago.  The way we test systems today is very different than what it was 20 or 30 years ago.  The way we manage the source code, all the pieces that go into modeling and designing and architecting systems...  all very different today than they were 20 or 30 years ago.  But, you look at the way an analyst is functioning today, and it’s still exactly like it was 20 or 30 years ago.  We’re now saying that this is the next piece of the puzzle and have stuff, morph, and become more up to date with the way the rest of our industry is going, which is better, faster, and cheaper.

I remember, at the bank, we were targeting 90-day deliverables.  This was back in ’97, ’98.  We thought, then, to get to a 90-day deliverable cycle, something of business value every 90 days would be amazing; you know, what a great accomplishment to go from 12 months to 90 days!  But, already now six, seven, eight years later, we’re seeing that even 90 days is getting to be too slow to keep up with the pace of business change; and so, whereas the rest of our technology in this agile movement have done a pretty good job of moving us toward even a 30-day mentality, the business analyst’s role has not kept pace with that.  I think that is where the real shift in our software development lifecycle phase needs to occur now is that the business analyst has got to become more agile in their approach.

I very much agree with that.  That is what Keith pointed out very well.  We’ve got a lot of cool tools now, and programmers really can turn out good code fast.  What’s holding us back?  It’s the spec.  It’s the requirement.  We still gather that in a way that we were doing 30 years ago, and we do it in a way which is just designed to set up an adversarial tension-filled relationship.  So, that’s where your leverage point is.  Fix that problem, and you’re going to get a great acceleration; and I think it really comes down to now, we’ve got some pretty good tools.  The question is how do you use them?

And, I’m an amateur historian.   Let me leave folks with this little analogy.  Did people know that the French actually had many more tanks and bigger and heavier tanks than the Germans?  How come the Germans just absolutely ran just roughshod over them?  It’s because they knew how to use the technology.  The technology was the same; the French even had more of it.  But, the Germans used it better.  That’s what we need to know is there are ways to use existing technology a whole lot better, and the results will be astounding.

So, with that, let me recap some of the high points of our conversation that I heard, and let’s rap up for our audience.  Keys in this conversation I heard were just like in real estate, it’s location, location, location.  In project requirements it’s translation, translation, translation.  We need to do a much better job of being able to communicate and translate requirements from a business vernacular into a technology vernacular and improve the relationship that we have between the business and IT constituents.

Mike brought up the six steps for doing that, and we need to keep in mind that there are some changes that need to take place in most organizations to accommodate a more agile approach and provide a more frequent, working deliverable for the business to show that there is a profitable money-making venture that the organization is actually funding.

We heard Keith talk substantially about turning requirements into requirements assets, creating purposeful reuse, and a plan.  We also talked some about integration of people, process, and technology, making sure that people understand what they are supposed to do and when they are supposed to do it and how they’re supposed to use technology to attain those goals is a very critical component in the ability to be more agile and move quicker.

I would point people to some of the articles that Michael has written.  He specifically mentioned The Rise of the Business Analyst - Again.  I think that is very pertinent to our conversation today.  So, for further information on all of this and for the ability to hear additional interviews we’ve done, please come to process-exchange.com, and attend our Events page.  You can also send us questions to info@process-exchange.com, and I’ll be happy to engage Keith and Mike on your behalf.  We’ll look forward to communicating with you and sharing more ideas in our next CIO Interview.