e-Talk Radio: Davis, Alan, 8 March 2001

TEXT TRANSCRIPT: 8 March 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.


ANNOUNCER: Welcome to Quality Plus! e-Talk with Carol Dekkers, brought to you by StickyMinds.com, the online resource for building better software. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now, let's join your host, Carol Dekkers.

CAROL: Welcome to Quality Plus! e-Talk with Carol Dekkers. I am Carol Dekkers, and I would like to welcome you to show number 10. It is March 8, 2001, and I am excited about our guest today. We are going to be talking about requirements management in Internet time, which is an exciting type of topic. I'd like to welcome our guest, Dr. Alan Davis. Welcome, Alan, to the show.

ALAN: Hi, Carol, glad to be here.

CAROL: Glad you're here. Before I introduce Alan, I'd like to tell you...extend the offer that I've extended for the past several weeks about a calendar that equates and ties together function point analysis, which is one of the things that I do for a living, .... software and tied into measurement programs. We've developed a calendar that has the CMMI, the capability maturity model integration model, tied together with function point analysis and together with a 12-month calendar for 2001. So, if anyone is interested in that, I offer you, if you'd like to send me your mailing address please, you can send it to: [email protected]. And I will give out the toll-free number: 1-866-277-5369.

I'd like to introduce our guest today. I am very pleased to introduce to you the president of Omni Vista Incorporated, a Colorado corporation dedicated to helping companies to prevent software disasters. Alan was a member of the Board of Directors at ............. which was acquired by Rational Software in February of 1997. He is a non-managing general partner and investment advisor for Catalyst Information Technology Development Fund, LLC, a venture capital fund investing in software start-ups in the Rocky Mountain region. He has consulted for many corporations over the past 20 years, including a lot of notables that you'd recognize: Boeing, British Telecom, ....... Design Systems, Cigna Insurance, Federal Expression, Flight Dynamics, MCI, McDonald's, IBM, Sharpe, I can go on and on. Previously, he was the vice president of Engineering Services at BTT, a Virginia-based software start-up that went public in 1995. He has been the Editor-In-Chief emeritus of IAAA Software and serving as Editor-In-Chief from 1994 to 1998. He continues to be an Editor for the Journal of Systems Software from 1987 to present. He is Editor for the Communications of the ACM from 1981 to 1991. He has been the author of several books, including Software Requirements, Objects, Functions and States, which the First Edition came out in 1990, the Second Edition in 1993. He has written The best-selling 201 Principles of Software Development, which came out by McGraw-Hill in 1995, and he's been the founder of the IAAA International Conferences Requirements Engineering. I can't think of anyone more qualified or eminent in the industry of requirements management than Dr. Alan Davis. So, I'd like to welcome you to the show, and thank you for taking time out of your busy day, Alan.

ALAN: Thanks, Carol. No problem.

CAROL: To get started, I think for some of our guests that are listening who were in the test management, quality assurance of any area - First of all, I'd like to welcome you to our listening audience, no matter how you're listening, whether it's in a few weeks from now on downloadable transcript or whether it's live over the Internet today, welcome.

Alan, what would you say requirements management really is, anyway?

ALAN: Requirements management is a term used in the software systems development world to basically capture the idea, to begin to write down what it is you want to build before we actually build it. This is something that is done in every single discipline; for example, before you build a bridge, you decide what the bridge is going to do, and you write down those specifications. In the case of software quality management, you must write down your requirements before you write the software to make sure that everybody has the same understanding of what it is you're building.

CAROL: And, and that sounds pretty commonsense to me that it should be fairly easy, that if you've got something that you want that you can just write it down, but something tells me that there is a little bit more to it than that.

ALAN: Actually, I think you're right, Carol. It should be really, really simple. And I think that we tend to fall to two schools of thought on this. Right now in practice, there are large numbers of people who simply don't believe in writing requirements down at all. Their philosophy is, "We'll build it and we'll change it, and eventually we'll be able to produce the product that customers want." And that is a very, very highly risky proposition if you don't write requirements down first. The other school are the people who have gone overboard thinking that requirements management should be done to a level where you squeeze out every single bit of risk you might have. And these people spend enormous amounts of energy writing and documenting and reviewing their requirements, and they end up doing an overkill.

CAROL: Right.

ALAN: And so I agree with you that it is almost a no-brainer to do it, yet, in practice, we seem to keep missing the point.

CAROL: Now, is that something that's specific to software? Do you think it is because software is amorphous or it's too new - We've heard a lot on this show, and in past shows, about the problem of requirements in that a lot of the problems that we have with maintaining software, with dealing with the software, you know, having the abends and that type of thing, could have been solved if there was more planning put in up front. So, it seems like it an elusive situation in some cases.

ALAN: Yeah. I think that in software it is somewhat unique. One of the reasons is because people still have this belief that software is easy to change, so "If I get it wrong the first time, I can always change it later."

CAROL: Right.

ALAN: That's one issue. The other issue is, if you look at our record in the software industry, we are considerably worse than most industries that are building to build systems that meet customer needs. We have around a 29% success record, according to the Standish Group...meaning that only 29% of the systems we build actually end up getting to a customer and solving a real problem. And if you contrast that with the latest data I have seen, which is from .............., that showed industry, all industries, where we are doing new product development, it is somewhere around 50% success.

CAROL: Wow.

ALAN: And so in software, we really are a lot worse than other industries. And I think that if we did a better job of requirements, we would have a higher probability up front of being something more like having a record more like the other industries than the dismal record we have currently.

CAROL: So, it's important to have requirements, to document your requirements, to document the assumptions. And it sounds like that could be really time consuming. If you have a company where you've got, you know, you're really constrained, if you look at a lot of the dot-coms today that are absolutely constrained by time-to-market considerations. And the time to market, I've talked to a number of, especially telephony companies, and when I do my classes on measurement, one of the people in one of the classes says how it is very nice to have goal question metrics; it's very nice to get the requirements down if you have the luxury. They said, "If we wait. If we are a Sprint or an MCI and we wait to get our requirements right, MCI or our competition will have the first feature out first, and even if it doesn't work right, well, they had it first and they are going to gain market share." What do you have to say for those companies that really are under Internet time constraints?

ALAN: Good question. I don't think the right answer is, if you're under the Internet time, you should not do requirements. I think if anything when you're constrained by Internet time with giving time to market, you have no choice but to make sure you do it right the first time. If you end up being close, I agree with the argument you just put forth. You're close, but you're early, you will capture market share. But if you entirely miss your market need, you will not be better off being early to market. In our company, we have around a four-month development lifecycle, in an industry which probably normally expects to have a 12-month life cycle. And where we spend a full 25% of our time doing requirements management, because from our point of view, even though we're a relatively small company and were taught strict time to market considerations, we can't afford to miss the market both from a time point of view and a functionality point of view.

CAROL: Now, is there is a balance that between the time to market that you have to get something out and it has to be kind of just good enough quality. Is there a balance between that and missing the mark? In other words, if I put something out that is, you know, kind of sort of okay and I miss the mark because it's not what people require, but I'm first to market.

ALAN: Yes.

CAROL: Will I still get the market share?

ALAN: It depends on a lot of factors. How far off do you want a mark and how poor quality you are, in all my thoughts about software, I have always considered quality to be an invariant. I don't believe you can accept lower quality in response for high functionality or having something out on market, and in the long term, poor quality will cause you to lose that market share very rapidly.

CAROL: Unless there is a monopoly situation, which is the case with most of the operating systems I use and most of the software I use. Somehow, I keep getting that abort, restart, ignore that seems to come up no matter what, and I don't have an option of going to somebody else.

ALAN: Yes. Do you really want to go there?

CAROL: No, we're not going there. What do you recommend for organizations that are really constrained by Internet time?

ALAN: Okay. First of all, let's look at the three aspects of requirements management that are essential for any company who is doing Internet time or not. And they are: Elicitation, to make sure you understand your market needs.

CAROL: Okay.

ALAN: It's triage - that's the second item. That's to make sure that what you have decided to build is something that can be built given your schedule and time constraints. And here you have to face reality and basically look at a subset of the full requirements, you've got market needs, to decide which ones really need to be built. And the third aspect of requirements management is specification, where actually writing down electronically or on a piece of paper, maybe on the back of an envelope if necessary, what it is you're actually going to build or of the external behavior that the system is going to be, so that developers can move ahead and build that system rapidly without constantly asking questions.

CAROL: Okay.

ALAN: Those are the three things.

CAROL: What...

ALAN: Now, traditionally...

CAROL: Maybe you could take me through that. Pretend that I'm a system developer and I am in one of your classes, and I have my own ideas about how I should do requirements and usually they're on the back of a napkin and then I start coding. What would you tell me?

ALAN: I have no problem with people documenting requirements on the back of an envelope, if the envelope is not then thrown away.

CAROL: Right.

ALAN: Now, it depends whether the envelope is acceptable or not has to do with what your environment is. If you're in a situation where you're building a custom system for a client, you actually cannot get away with just an envelope, because you need the customer and the development organization to sign off, acknowledging that there is a common understanding of those requirements.

CAROL: Right.

ALAN: And the back of an envelope probably won't suffice. So, you probably need at least a list of requirements in electronic form, for example, a spreadsheet, or a database, or a requirements management tool of some kind. If you are doing a, say a dot-com type site, an E-commerce site, a B to C site, and you have to get out there extremely rapidly. You don't have a particular market that you actually can find customers and talk to them. I would not object to a detailed list on the back of an envelope; it might just work.

CAROL: Right.

ALAN: It might be the right level of detail for that kind of business. But in general when you try to get to a marketplace, let's say you're building a product that's going to be commercialized and spread en masse around, then I think you need to do something more than the back of an envelope, and after the break, we will elaborate on what that actually is.

CAROL: Good. And we'll be back with more of Dr. Alan Davis after these short messages. Welcome back, I'm Carol Dekkers, and we've been talking to Dr. Alan Davis about software requirements management in Internet time. If you're working for a dot-com or you're working for any company that's under a lot of market constraints today, you need to still document your requirements for software, but there are some tricks and tips that maybe you don't have to be as rigorous as you are with some of the military-type or the large Department of Defense-type applications. So, Alan, before we went to break you were talking about this Internet time, what types of things we should be doing, and let me let you finish your thoughts there.

ALAN: Thanks, Carol. Just before the break I had mentioned there were three aspects of requirements management, let's talk about each one, and how you can diminish the effort without hurting your risk, or damaging your risks, too much when doing things in Internet time. In the category of elicitation, I would argue that no matter how pressured you are to build things fast you have to understand your market. An elicitation is nothing other than learning what your marketplace needs, and if you don't have a handle on what your marketplace needs, how can you possibly build a system that's going to be right. You could be absolutely lucky, and if you want to base a business on luck I would consider that be a highly dangerous route, especially for your investors.

CAROL: Yes.

ALAN: So, I would think at a minimum you want to do a market analysis. You want at least to do some interviews with some candidate customers. I happen to love brainstorming. So, I'd bring in a half a dozen people in the room who are experts in the marketplace and do some brainstorming for a half a day at an absolute minimum, just to understand what that marketplace does. When I was at Requisite, this is like seven or eight years ago we started...we did not want to talk to individual customers who had not yet produced our product. We basically brought in Ed Yourdon and myself as consultants in the requirements management space to act as surrogate customers. That is something you can do if you don't have access to immediate customers in this spot, find someone who knows the customer base.

CAROL: Right.

ALAN: That is an absolute must. You cannot get away with it...you can't get away with not doing it. You can do a triage - again I think it is absolutely essential to use a triage, even with time pressure. After all, what you're actually saying is, "I have a time constraint, I have to get this thing out in two weeks, two months, or two years, whatever it is. What can I do realistically within that time limit?" So, if you don't go through that process, what you're going to end up being is late for market.

CAROL: Right.

ALAN: What you should do in triage when you're in time constraint, is pick your schedule first. And then hack requirements into your baseline, accept requirements one at a time up until that's to a point where your risk of missing your schedule is too much for you to tolerate.

CAROL: And would set priorities there? You don't just randomly say, "Okay, this one is going to fit, this one is going to fit."

ALAN: Yeah. Absolutely, you're right, Carol. What you want to do when you collect the requirements during elicitation is entertain every requirement at least in two ways. The first way is, what its relative priority is in impact on the market.

CAROL: Right.

ALAN: The second one is, you must annotate your requirements in terms of how much effort you think is required, just a ballpark estimate of how much effort is required to satisfy the requirement. And with these two numbers, you can now start picking requirements from the high priority list and placing them in your baseline. Now, initially when you have no requirements agreed to, you have 100% chance of making this schedule.

CAROL: Right.

ALAN: As you add the high priority requirements, you'll see your probability of making a schedule going lower and lower, and eventually you'll either run out of high priority requirements, in which case you put some medium priority requirements into the baseline, or you may never even get to all of your high priority requirements before you get to the point where you're at risk of missing your schedule becomes intolerable. So, those two annotations and the balancing of the requirements against meeting the schedule, again, I don't know how to...I can't imagine working on Internet time without that.

CAROL: And we're talking about kind of the worst case. When you don't have solid users, when you're really trying to aim for a moving target, which is, you know, "What are the features that the marketplace is going to grab? What can we put in a Web site?" And I think that one of the things that we've seen is extreme programming come up when you've got a lot of requirements changing rapidly, that they can easily follow this type of thing, and I think they support a lot of the concepts that you're bringing forward, which is, "Let's grab something small. Let's grab the highest priority. Let's work on those." Rather than building this whole huge monolithic two-year set of requirements documents.

ALAN: Yes. I absolutely agree that the only way to build systems properly this day is to manage your requirements against your given schedule. And if your time to market says you must build things very, very quickly, and the only way of doing that is to build systems incrementally. The small increment initially, then a larger increment, then another larger increment, etc. It's the only way to do it. There are two advantages to that. One of them is you get to market fast. The other one is you get feedback from the customer base before you have to make commitments to the next generation.

CAROL: Right.

ALAN: Which gets you a higher probability of actually meeting their needs in the long term.

CAROL: Now, what do you think is the right amount of effort to spend on requirements? I have been in a lot of the, you know, the newer shops, the older shops, and I have never once, and I have yet to be in an XP shop, which I'm looking forward to going into, but I've never seen users get up on a Monday morning and say, "Yes, today is the day that we get to do those jazz sessions or those focus groups, or ...... systems is going to listen to us." How do you get the user involvement? How do you get them to be involved productively, and what is the right amount of time that someone should spend on doing requirements?

ALAN: First of all, I have had different experiences than you. I find people very excited about doing that. Because they want to make sure they build the right system. So, from a development point of view, they want to make sure they build the right system and from a customer point of view they want to be involved because they want to influence the development organization to build the thing that they want.

CAROL: Right...

ALAN: Than what someone else wants. So I see lots of enthusiasm in my world. As far as time goes, NASA has done a study that was published about five or six years ago that showed that, they had some studies, some projects, where they used...they spent almost no time doing requirements management and other ones they did up to 20-25% of their time spent on requirements. And they found that their overall project cost overrun, when they spent almost no time doing requirements, was up around 80% to 90%. So, almost a double of what they expected the cost to be. When they spent about 20% to 25% of their time on requirements management, it brought down the overall cost overrun for the product down to around 20% to 25%.

CAROL: So, doing the...

ALAN: Those are some very large projects. In the smaller companies, I have found about the same kind of ratio, around 20% to 25% is the right amount of time to spend.

CAROL: Interesting.

ALAN: I'll elaborate on that after the break.

CAROL: And we will. Please join us after these short messages from our sponsors and StickyMinds.com. And if you're just joining us, we're in show number ten. I'm Carol Dekkers and my guest this week is Dr. Alan Davis, who is president of Omni Vista Incorporated, which is a Colorado corporation dedicated to helping companies prevent software disaster. I'd like to give out the toll-free number if anyone is interested in calling us. The number is 866-277-5369, and we absolutely will not cut you off, we will not be rude to you on the phone. If you've got questions for Dr. Davis on requirements management in Internet time, if you're challenged with some of the things we're saying, or challenged with things in your own work environment, please give us a call. We'd love to hear from you.

We've been talking about requirements management in Internet time, and what's the right amount of time you should spend on software requirements. Alan, right before we went to break, you were talking about the NASA study and how much time and the fact that if you spend 20-25% of your time on requirements, that you actually will hit your deadline much better. And I can see how that can happen. One of the things I think that traditional developers are taught in school is that nothing is worth anything unless you've written a line of code. And the TSP and PSP that the Software Engineering Institute has come out with really addresses that, that we should be planning more and spending time up front. Now, I think you've said that there's a balance, that the 20-25%, is that of overall anticipated project effort that you'd spend 20-25%, or what exactly do you mean by that?

ALAN: Let me answer that question too, as one of them is the NASA study and then what my suggestion is.

CAROL: Okay.

ALAN: The NASA study is an after the fact. It wasn't that they planned on each project to spend 20% of the whole time on the project. It was after the fact they went back and looked to see how much time they did spend on planning. They found the optimal to be around 20 to 25%. My recommendation is to spend between 20 to 25%, not because of the NASA study, but because that in my experience over 25 years doing this, when you spend less time than that, you'll have a much higher risk of being in the 71% of projects that fail, which is something that I don't like being involved with.

CAROL: Right.

ALAN: And when you spend much more time than 25%, you end up likely being late on your delivery by you spending too much time planning.

CAROL: Right.

ALAN: So, I found the sweet spot to be somewhere around 20-25%.

CAROL: And we want to avoid...

ALAN: And this is of time, not of resources. Usually, your requirements effort is burning dollars at a slower rate than development, and a slower rate than testing. So, it's probably more like 6% to 7% of your total development resources, maybe a little more than that, but it's 20% to 25% of the schedule.

CAROL: Oh, okay. That makes sense. So, you wouldn't have everybody on your project team, whoever is going to be involved in coding and everything else, sitting in this massive room with every user that potentially might ever touch the system, for days on end.

ALAN: No, I would not. First of all, you probably won't have those people on board yet. If they are on board, they are working on other projects, using their expertise. You certainly want to have a few representatives from the development team on that requirements brainstorming session or requirements triage session, but not...you don't want to have the entire team there.

CAROL: Right. Now, some programmers and Steve McConnell really said this in his book on After the Gold Rush, I think it's called After the Gold Rush. He said that a lot of programmers really skip the requirements stage, and they really say, "Let's get a system into the hands of the user so that they can see what they want and what they don't want." And really the best way of programming is to code and fix. Now, he says that's the dominant way that people are programming today. What do you think about that?

ALAN: Excellent point. Let me first tell you that I agree with the position that he is taking, which is that it's good to have something in the hands of the customer as soon as possible. I differ with him on his...well, actually, I agree with him on his observation that's how we should do things today.

CAROL: Right.

ALAN: I differ in the recommendation, however.

CAROL: Oh, he didn't recommend that. What he said is that programmers feel that you should get it into the hands of the users, or customers, fast because they don't know what they need.

ALAN: Okay.

CAROL: So, he was actually saying what programmers in our society are feeling.

ALAN: Are actually feeling...

CAROL: Yes.

ALAN: Okay. Yes, so, I'm in 100% agreement with him then.

CAROL: Okay.

ALAN: Yes, that's what we are doing. I've actually had...it's similar to half of the people who are doing, and then the other half of people are spending too much time planning.

CAROL: Okay.

ALAN: That being the caricature of the CMM 4 and 5 company.

CAROL: Right.

ALAN: That does not mean that every CMM 4 and 5 is spending too much time planning and too much process. It's the caricature that the company is one of those. Now, my recommendation to those coders who think they should simply throw together something and get it into the hands of the customer, I happen to like that as part of the requirements process. I like the innertube prototyping cycles as part of prototyping, but I am so driven by getting, like putting quality into a real product, I don't want to put quality into my fast generations. And that's why I prefer to do the quick prototyping during requirements, and I make sure everybody knows this is only a prototype and will not become the product; it will not evolve into the product and one way of me doing that is that I rarely give a customer an actual working system. I will draw them a picture on a flip chart, or if I actually have both a working prototype, I won't show the customer the screen shots on paper, not on the computer, so the customer is never tempted to believe that there is a real product there.

CAROL: Right. Yeah, that makes sense. Because otherwise they will get...I've seen situations where people have delivered a prototype and the users have liked it so much that three years later they are still using the prototype.

ALAN: Yeah. I have delivered prototypes to customers to show them what their vision would be, and they say, "I'll buy 100 copies of it tomorrow, what's the price?" Now, because you're in a terrible ethical dilemma, you want to make money for your company, but you also want to give quality to your customers.

CAROL: And, and then you end up in the Dilbert Society essentially.

ALAN: Absolutely. And, of course, your pointy-haired boss, still following your Dilbert analogy, encourages you to deliver the product.

CAROL: Well, definitely, definitely. There was a movie actually out where somebody did that. They had shelves of systems sitting in front of people and they were buying up hundreds of them, and I can't remember the movie or anything else about it, but I just remember that part of it, which really sounded like, you know, empty requirements.

ALAN: Right. And at this very moment listening in on the Internet, on this station live, are a bunch of my employees. And they're probably thinking right now, "Oh, didn't you hint a couple of weeks ago, Davis, that you wanted to ship out a product a little bit earlier with a few bugs in it?" So, they're probably laughing right now. You have to blend all of this philosophy with also the realities of business once in awhile.

CAROL; And, so, you need to document your requirements, you need to get something down; would you agree...I know that a lot of times I have had people say that requirements engineering, building software, is really nothing like building a house. But, I often liken it to the fact that, I know in the county that I live in, we certainly would not be able to get a building permit if I kind of drew something out and said, "You know, I'm really not sure what I want in this area of the house, but hey, we will figure that out later," and just kind of drew an airy fairy-type thing. That if I don't have a solid, at least some sort of idea of a solid floor plan, and some idea of how this is going to fit into the owner's environment, I don't get a building permit. And yet in software, we can go ahead and pour foundation and put pipes in wherever we want, and isn't really requirements management about putting the floor plan into place?

ALAN: Absolutely. And the amount of money we are talking about in the case of a software company is often a lot larger than what I am going to be spending on a house. So, investors...

CAROL: Yeah.

ALAN: ...are investing 5-10 million dollars in your company, I can't imagine why anyone would want to invest that kind of money if the company didn't have requirements.

CAROL; Well, we have people around here who are a part of different entertainment industry things who are building houses that are 5-10 million dollars, but that's a different story.

ALAN: Right. And they certainly would not tolerate spending the money, or committing the money, before seeing a floor plan.

CAROL: Oh, no, if they came up to something and saw a foundation poured, I think there would be major trouble.

ALAN: Right. Yes.

CAROL: Well, go on.

ALAN: You also hinted here in your last question about the relationship between design and requirements.

CAROL: Uh hum.

ALAN": The floor plan of a house is really the architecture...the architectural equivalent, there would be architectural design of the software. And so what you're actually bringing up now is another issue, which is, "Shouldn't you have an architecture?" Shouldn't you need an architecture before you commit large amounts of money toward development. And I think that's true also. That would fall very nicely into a talk like this on designing in Internet time.

CAROL: Right.

ALAN: As opposed to requirements in Internet time. Now, the case of designing in Internet time, I agree with you, before you commit to large sums of money to build your product, you must have a design, the floor plan of the house, so to speak.

CAROL: Right.

ALAN: If you want to get back to the requirements analogy, and would you even need the requirements for the house before you want to commit to building it, and I say, obviously, yes. You want to know what the house is going to look like, how many rooms it's gonna have, even re-plan of the floor plan. And we will talk some more after the break.

CAROL: Yes, we will. And we'll sum up and come back more with Dr. Alan Davis. And we've been having a wonderful hour here talking to Dr. Alan Davis about requirements management in Internet time, and our time is almost up. I can't believe it. We have talked about some of the things that we should be doing, the fact that we can't ignore requirements, that they're very important. One thing that you mentioned earlier that I think is...that some people may have picked up on and some might not have; you mentioned earlier about letting the schedule drive your requirements.

ALAN: Um hum.

CAROL: Rather than the other way around. And I can see some people probably squirming in their seats and saying, "Ooh, that's not the way TSP or PSP or some of these new things tell us we should do, and CMM doesn't say that." Do you want to elaborate a little bit more on that?

ALAN: Yes, absolutely. I think it is a very new idea. I've not seen it written about anywhere, but I see companies over and over again getting into a dilemma where marketing defines the market window, and they're basing it on their experiences and their intuitions, and their knowledge of the marketplace, and they say, "We need to have the product out in nine months." And then they list these 200 requirements, let's say 100 requirements. And then everybody tries to figure out how are we going to cram these 100 requirements into the deadline. The fact is, that the deadline tends to be very, very firm. The requirements are very pliable. They're giving any one number of requirements in many ways of solving that requirement, some of which are very simple ways that would just capture the marketplace easily, some are providing the customers with exactly what they want. So, there is full spectrum there, plus given all the requirements not all of them are absolutely essential. It seems so natural to me to take that deadline, which is absolutely firm, and figure out which requirements can be done realistically in that schedule. If you contrast that with what most people are doing, what the development organization does is they take the requirements that are given to them by marketing or from the customers and they put it through a tool and out pops a date, March 1, 2002.

CAROL: Right.

ALAN: And then they say, "Okay, March 1, 2002." And marketing says, "What? I can't wait that long, I need it in nine months." And now we have a fight on our hands. So, they are fighting rather than working together to try to solve the problem. I would much rather see us pick a date and then have development and marketing together figure out which are the right requirements to build, so that the schedule can be met.

CAROL: Right.

ALAN: And that way marketing can make a decision, should we have all 100 requirements satisfied and be 3 months late into the market, or should we aim for 75 of the requirements and get it done on schedule. And that's a marketing decision, not a development decision.

CAROL: Well, and, you're talking about a cooperative thing. I think a lot of times what I've seen, and this may conflict with what you've seen, sometimes marketing feels that their only power is in dictating a date, and so they pick one out of the air and it's somebody's birthday, who knows; it's a date that they choose and they're gonna stick by that no matter what. And the system developers dig their heels in. And I think you're absolutely right, that it's kind of a fight that emerges, and rather than working together on a solution, it's a fight over the date.

ALAN: That's correct. And I think the key is to be able to rearrange the contents, they're looking at a puzzle, as the team versus the puzzle, rather than two teams fighting each other.

CAROL: Right.

ALAN: I agree. The fact of the matter is, development and marketing are both practicing exactly the same levels of black magic in their duties. So, development accuses marketing of making up a date, marketing accuses development of making up a date. The fact...

CAROL: Right.

ALAN: ...is they're both simply applying their experiences to come up with the best date they can come up with. Does marketing know they need it in nine months? Not absolutely. But based on their experiences, their education, and their talking to customers, they believe the best date is nine months from now.

CAROL: Right.

ALAN: You know, when development says they can do it in one year, do they know they can do it in one year? Absolutely not. It's their combination of experience, talking to the developers, and what they've done before, and what they have learned before, that says, "It's about a year."

CAROL: Right.

ALAN: So, the idea of any one calling the other one non-professional, for example, is absolutely nonsense, because both are practicing exactly the same amount of black art. And as soon as the two groups...the sooner the two groups realize that the other groups are following the same thing they're doing, the more we'll get respect...the sooner we will get some respect between the two organizations.

CAROL: Right.

ALAN: And I've been on both sides of that particular fence, I understand how both sides work.

CAROL: And it all comes down to communication, which is easier said than actually down.

ALAN: It's communication and respect.

CAROL: Right. Now, in recommending to companies, what would be your highest level of advice for the listeners, we have a whole myriad of listeners, we have people who, you know, have the luxury of being able to do requirements, we've got the people who are absolutely pressed by Internet time, we've got people who have to deliver tomorrow with anything that moves, we've got the dot-coms. Just taking a look across the industry, what do you think people should start doing today?

ALAN: If you're not writing requirements down, I recommend you write them. At a minimum, just make a list of them, a bulleted list in Microsoft Word, that's better than not having them at all. So, first advice is, make sure you write them down - That's gonna be the disagreements between the customers and developers after the product is built-- misunderstandings will go away. It will increase your productivity of developers, they can get away with asking fewer questions during development. And then they have to go through the requirements to find out what the answer is.

CAROL: Right.

ALAN: Another reason for writing the list down is you really don't want your C++ hacker making decisions that are critical to the acceptability of the product to the customer. You want a person who is an expert in the market and in the customer domain to make that decision, not the C++ programmer. So, write 'em down. The next piece of advice, make sure you understand your market and the size of your market. The third piece of advice is make sure, absolutely, that you have done triage, that you understand the relationship between schedule, budget and requirements, and make sure they are all three in complete agreement before you undertake your project.

CAROL: Timely advice. And we'll be back to sum up with Alan Davis after these short and final messages. If you've been listening to us, I'm Carol Dekkers and my guest this week has been Dr. Alan Davis, who is President of Omni Vista, Inc. We've been talking about requirements management in Internet time, and why it is important to document, elicit, and get requirements down no matter how much time or how little time you actually have. I'd like to say thank you very much to Alan for spending the last hour with us, really spilling his guts and sharing his wisdom. So, thank you for being part of our show.

ALAN: You're welcome and thank you for the opportunity to be here.

CAROL: This has been great. Every now and then we get a guest that I could talk to for five hours, and actually, every single guest on the series has been that way. So, it's been great. We have the transcripts. We're now getting our...thanks to our StickyMinds.com, www.stickyminds.com, our sponsor, who we thank for sponsoring our show. They have created on their Web site, if you click on the e-Talk icon at the very top, you can go into the page that is actually dedicated to the Quality Plus e-Talk with Carol Dekkers Radio Show. And if you look at the schedule, you will see anything that is underlined in terms of the schedule on the right, that those are links to downloadable transcripts where we have actually the transcripts from past shows, and we are working on getting them all up for you. And all of the shows that we had in the past season as well as streaming audio. So, if you've missed any shows or if your friends have missed any shows, and you want them to be able to hear what you've heard today, in a couple weeks you can go out there. Right now, we have Howard Rubin, Johanna Rothman, Esther Derby, Ed Yourdon, and a number of other shows. So, if you've missed those in the past, go out to StickyMinds.com, take a look for yourself. Next weeks' show we have Jim Highsmith, who is with Information Architects, and he is one of the authors of Adaptive Software Development: Lightweight Methods for the New Millennium. And he's going to be talking about lightweight methods; what's new in the environment, what should we be looking for as far as methodologies in developing software. He has also recently become part of something that is quite exciting called the Manifesto for Agile Software Development. And in the Manifesto it says, "We are uncovering better ways of developing software by doing it and helping others do it, and we value individual's interactions." And the people that have joined in this are Ward Cunningham, Martin Fowler, Alistair Cockburn, Kent Beck, James Grenning, Jim Highsmith, Andrew Hunt, and a lot of the people that are associated typically with extreme programming in the newer development methods. So, I'd like to ask you to join us and be part of our listening audience next week with Jim Highsmith. The week after we will have Stan McGee and Peter Voldner, who will talk to us in layperson's terms about ISO standards. How can you choose process standards that will work with your organizations in non-technical terms. So, I'm quite excited to have Stan McGee and Peter Voldner coming on our show with us.

Now, we're looking for a new home starting on April 4. We may be at a new location, but you'll still be able to pick up our program by going to www.qualityplustech.com or by going out to www.stickyminds.com. And I'd like to promote some training that my company is having. We are going to be having Function Point Analysis for Web-based Software, Function Point Validation, Function Point Basics, and our newest course which is offered in conjunction with the Department of Defense, Practical Software Measurement. Those are going to be offered in MacLean, Virginia; Chicago, Illinois; and Seattle, Washington, over April, May and June. So, go off onto our Web site, take a look at the public training, and you'll see the dates and registration forms to sign up.

Alan, this has been wonderful. I'd like to give you the opportunity to give out your Web site and a 30-second, "What would you like to leave our audience with?"

ALAN: Okay. Thanks, Carol. First, it was a pleasure working with you this hour.

CAROL: Thank you.

ALAN: Our Web site, where you can learn more about requirements management in Internet time, and about tools and services available from my company is: www.omni-vista.com. And my final words to the people out there are these: Make sure you write your requirements down, make sure you learn what your customer's needs are, and make sure you pick the right set of requirements that enable you to actually meet your schedules and your budgets, and be more successful in the future.

CAROL: Thank you very much. We appreciate your time. And I appreciate all of you who are listening. Tell your friends we'd like to build our listening audience. And, until next week when we e-Talk some more, this is Carol Dekkers signing off. Have a wonderful week.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.