ABOUT THE WEBINAR
Requirements Planning adds incredible value to the requirements process. More than simply creating another “work breakdown structure” document, this is an opportunity to address risks proactively and gain better stakeholder participation. This session demonstrates how every component of a requirements plan adds value.
Learning Objectives:
1. Illustrate the pitfalls of traditional approaches to Requirements Planning
2. Deliver guidelines for making Requirements Planning a value-add activity
3. Know what material must be present in a high quality requirements planning document
FEATURED SPEAKER
Keith Ellis
VP, Marketing & Strategic Alliances
IAG Consulting
Keith Ellis is the Vice President, Marketing at IAG Consulting where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith's former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG's Business Analysis Benchmark - the definitive source of data on the impact of business requirements on technology projects.
DURATION: 60 minute presentation and interactive question and answer session.
FEATURED SPONSOR: IAG Consulting
Webinar Transcript:
5 Things You Must Know About Requirements Planning
Host: Hello, everyone. My name is Adrian Marchis and I’m the publisher and editor of ModernAnalyst.com the premiere online community for business analysts. I would like to welcome you to today’s webinar titled, “5 Things You Must Know About Requirements Planning.” Today’s featured speaker is Keith Ellis. He’s back. He’s vice president of marketing, strategic alliances for IAG Consulting. Welcome, Keith, again, to another great session. The webinar will last approximately 60 minutes including a Q&A session at the end. So make sure to submit your questions in advance using the questions feature of the webinar software. I would also like to say thank you to IAG for sponsoring this event. And at this time I will turn over to Keith to get us started.
Keith Ellis: Thanks, Adrian. And I appreciate everybody who is going to join us today. I think Adrian you’re tallying what 900-- what’s the number?
Host: We’re now up to 960.
Keith Ellis: Nine hundred sixty people joining us today. So it should be a nice warm cozy event with just a few of our closest friends here. So look today we want to get down into the details of things you need to know about requirements planning. And really, today’s session is a very deep dive. You could say it’s also a deep dive into getting stakeholders on board with doing great requirements practices and keeping them engaged. That’s what this is all about. How do you get people engaged? How do you keep them engaged and how do you continue to move that process forward? There’s no other stage in requirements, really, that is so salesy as this stage and it’s a place where analysts can truly strut their stuff. It’s a place where project managers can truly strut their stuff and showcase the value you bring to the organization and the abilities that you have to move your organization forward to accomplish their goals and objectives. Now, what I want to do is give you a little bit of kind of preamble stuff. There’s PDU and CDU information for this webinar always on the last slide. And you can go pick that up as soon as we get there, take a screen shot of it. Also if you’re interested in the slides, make sure you request them of myself or Adrian, we will turnaround and send you those links, okay, so that you can have the slide deck. Adrian is, I believe, recording this for today and you’ll get that on the Modern Analyst site or if you got to the IAG site you can pick it up there. Either one of those places you can pick it up. And you can get access to that if you want to send a friend or whatever it is that you want to do. And also finally, this is as interactive as you want to make it. So I know we’ve got 900-whatever it is people that are participating today. You know what, ask your questions. Get them into the Q&A area see how quickly I can go through those and make it a test if you want to, okay, but I will try to keep up with everybody. If I don’t get a chance to answer your question during the session then make sure-- I will make sure I get back to you before the- before-- typically before the weekend. And Henri if you could just send an e-mail to either myself or Adrian. And the e-mail address is on the bottom of the screen, right now. It will also be on the bottom of the last screen, and just make that slide request. I do want to open up a poll just to get a sense of where people are coming from, if you don’t mind, just give me a sense of where you’re coming from. Do you guys do today requirements planning? Do you do requirements discovery management plans today? Give me a quick review of that, okay. Give me a sense of where you guys are coming from? The poll’s not showing. Hang on. There we go. Hopefully the poll is now showing.
Host: No, I think you closed it.
Keith Ellis: Okay. So for whatever reason the poll is not showing. But it looks like I’ve got about half people kind of coming in saying yes some people saying no. Let me see if I can get this going, again. You know, what we might have lost our poll. That’s okay guys. What I can do is just kind of speak a little bit to both sides in terms of it sounds-- it looked like I got about half the people saying yes, a number of people saying no on the way through. So let’s continue on and not worry so much about the poll. For whatever reason, it didn’t execute the way it was supposed to today. What are we going to go and talk about today? We’re going to talk about leveraging requirements as a value-add activity. And if you treat requirements planning as just another document to build, frankly you’ve failed. It’s a challenge. That’s not really the value-add. The value-add is in locking consensus on what constitutes great requirements. That’s the process. And what’s the process going to be on this project? And what is the commitment of the business in supporting the initiative. That’s where the value-add is all about. So how do you get that to work for you in your organization today, that’s what we want to focus in on. We want to talk about building and keeping stakeholder commitment. A lot of you said no in your Q&A area. And so if you said no, let me ask you something, for those of you who said no, are you having trouble keeping stakeholders engaged in your requirements process? How many of you who do have trouble keeping stakeholders engaged are doing requirements planning? And I’ll bet it’s pretty close, you know, to zero. So if you’re doing requirements planning well you will tend to keep your stakeholders much, much, much more engaged, okay. It’s really part and parcel to the same kind of thing. As Henri is basically yeah, you know, what there’s a lot of change management in there as well, those are many, many kinds of things you’ve got to do but it starts with setting expectations, keeping those commitments and building that commitment to a particular plan of action. And I want to talk about the inputs and actions, okay, not templates. I’m going to share with you a template. By, the way, I’m going to show you what one of these things look like but those are not really rocket science I could do that in one slide, five-minute webinar we’re up and done. What I want to do is show you the inputs and the actions. How do you go about doing this and executing it well, okay? The template itself, again, very, very simple. I’m going to show you one, but it’s the inputs and the actions that are the tough stuff of requirements planning, all right. Now, about IAG because people, you know, this is-- people need to know where we’re coming from. We’re an organization that specializes exclusively in requirements definition and management. That’s all we do in life. We’ve done well in excess of 1,200 now. In fact, that 1,200 number has been around for about four years. We’re probably well over 1,500, 1,600 projects at this point in time. Most of the time people don’t come to me and say hey, Keith I’ve got an easy for you today. They usually are coming to me with something that’s-- it’s bigger, it’s uglier it’s- it’s, you know, 30 to 300 stakeholders. We’re doing one now that’s something in excess of about 200 high level business use cases and 150 or so business stakeholders and 10,000 hours to assemble the actual requirements itself on the project and we’re going to cycle that in a very short period of time. The issue for many organizations is how do you then coordinate so many people? How do you work together even with 10 or so or 15 or so people. In fact, many of you probably have this, you know, common experience. You know, three or four of you as friends got together and had to decide on a restaurant that you wanted to go to, it tends to be difficult to coordinate behavior amongst a largish number of people, right. So we specialize in this and we specialize in the area of requirements. We engage in one of four areas. One is we do projects for organizations. The second thing is people could look at what we’re doing and say hey we really like the stuff that you do. We like your approaches IAG, can you internalize us? Can you help us to implement those within our own organization? And we help people do that routinely. We help to train business analysts and we’ve trained something in excess of 30,000 analysts or 40,000 analysts over the years. And the last thing we do is sometimes organizations are just broken in this area and they really need the requirement center or excellence put in whether it be turnkey us managing it or they’re managing it. They really need that transformation to happen. And sometimes they need technologies that are supporting those requirement centers of excellence. And we work with many, many different technology partners. And if you’re interested in that kind of thing just reach out and we can have a conversation about it. So let’s look at the learning objectives, okay. And I’m going to accomplish these three things. If I don’t accomplish these three things make sure you send me your cranky e-mail, all right, because I want to make sure we’re doing more of what you want, a whole lot less of what you don’t want and that way we can continue to make these sessions much, much better for everybody out there. But there are three big things we need to accomplish. One is, there are three big mistakes that people make, what are they? And it’s candidly most organizations are not particularly good at requirements definition management. So all of you have said, hey, we don’t really do this. It is what it is. There are different mistakes that people tend to make and it is what it is. It’s not taking away from anybody. What we’re trying to do today is to give you some advice and some ideas, how can you take this forward and really change the playing field for yourself. The next thing is there are five things you really need to know in terms of the value-add, where is this coming from? And how does this link between the PM role and the BA role and how these kind of come together. It’s very techniques oriented in here and I want to tell you how to go about doing some of this stuff. What do you look at? Where do you look? How do you think about it? And how you pull those elements together. And then you need to know what goes into the plan. So certainly at the end of the day there is a requirements plan that gets delivered. People sign off on the plan. Let me give you an example of some stuff in that area, that way you’ve got some ideas of what you might look at. So let me take a test, okay, and you can stick the answers in that Q&A area, if you want, just to kind of continue the dialogue, get people warmed up and actually asking questions. But the test is basically I want you to read each of the questions and assign yourself a score of one to five, okay, for each of them and then you can stick the sum of that in the Q&A area if you really want it or just keep it to yourself. The quick survey is basically requirements is a black hole in the Gantt chart, meaning you don’t have any fidelity. Is that something that never happens? Give yourself a one. Or is that something that always happens? Meaning, when you look at your requirements plans is it just hey, we’ve got four weeks to do requirements on this project? Or is there a detail on how you’re doing that? Project managers are unable to report progress on the requirements effort, not able to answer. How do we know when we’re done? Is that something that you get a lot of, never? So if it’s a never you give yourself a one or a two. If it’s always happening, give yourself a four or a five okay. How about business analysts going to the well of the subject matter experts. If business analysts are going to the subject matter experts, repeatedly with no one in sight, give yourself a-- if it never happens, give yourself a one or a two. If it’s always happening, then keep going back, the subject experts are busy saying hey we’re just spending way too much with these analysts, give yourself a four or five. Failing to get the right stakeholders, you get the idea, okay. So go down and add up what your score is okay. Add up what your score is. So your score is going to be somewhere between 5 and 25 right. Margaret’s got it. Somewhere between 5 and 25. If you’ve giving me 2s or 3s in the box you’re doing it wrong, 5 and 25. We’ve got some big numbers here. That’s okay, I mean it is what it is, all right. Paula, you can’t have a two. It’s not possible, any more. Okay. So it is what it is. Thanks. All right, so most of you are scoring some pretty big numbers. Paula, wonderful. You guys are brilliant. You’ve got five out of five, everything is going real well. Basically what I want you to think about is these are all symptoms, all right. They’re all symptoms of poor requirements planning. In fact, these-- you should be as close to only five as possible. Requirements should never be a black hole in a Gantt chart. There should be very strong answers as to knowing when you’re done. Subject matter experts should not feel that they’re abused. Hey, Louise, I can identify with where you’re at if you’re the only BA on your team as well. So the challenges that you get into here are going to be significant if there are limited resources, if there are limited- a focus on requirements planning activities out there, but these are symptoms that you’re going to tend to get into. If you’re scoring above 13 to 15 you probably have significant room to improve. If you’re above a 20 or so you have lots of room to improve. In fact, you can probably dramatically improve your overall productivity as an analyst team if you focus in on this requirements definition management. For us, we actually end up pulling this out of organizations, outsourcing the entire thing if you’ve got three or four hundred projects you pull the-- well, sometimes as few as 50 or 60 projects, you pull the whole thing out and you do what’s called a requirement’s factory where you centralize that planning effort. And you can get a 20 percent productivity boost out of an analyst team just by doing that one activity. There are lots of things you can do. So in this particular case, step back and ask yourself, what are the downstream implications of being poor, a requirements management? What are those downstream implications? And by the way, don’t worry, a lot of organizations are poor at this, right. There’s a lot of organizations that have problems in these areas. But the issue is that they have problems in many areas of requirements because they’re poor at this one thing, because that’s so many different impact areas. So let’s talk about some of those cross over things. This is one of those few areas where it really crosses very heavily across the PMBOK and the BABOK. And so it’s arguable which area of responsibility this falls into and in fact because it’s both. In both cases you know, when you look at the PMBOK scope management is clearly part of the rule of the project manager. And inside there you’ve got specific deliverables that have to be produced, including a requirements management plan, oddly enough, which is what we’re talking about today. In the BABOK, obviously, it’s a core competency that we would expect to see in a business analyst. And all of those are key. But more importantly than either of those in terms of the hey you’ve got some specific as a professional who is out there practicing the market you’ve got specific things you must be able to produce, okay, that’s important. But what’s more important than that is that it’s a litmus test for the project managers. The quality of oddly enough this is going to be frightening for some of you, okay, the quality of your requirements plan is very predictive of your ability to produce high quality requirements in and of themselves, oddly enough. The two are very tightly linked. Okay. So if you’re out there and you’re assessing an organization and you realize that that organization has very poor requirements planning there is a very, very high probability that that the organization will also be extremely poor in terms of requirements. And will also be extremely poor in overall project control. So it’s predictive. It’s very, very predictive of your overall performance as an organization. It’s certainly one of the first things you should start looking at if you’re going to make some improvement. Let’s take a look at the changes that were introduced in 2008 to the PMBOK. And this is-- we’ve got a lot of business analysts that are in the-- yes, PMBOK, Dave. So there’s are lot of business analysts on there, you’re not as familiar with PMBOK and this is one of those kind of cross over areas as I had mentioned, okay, because when you get inside of PMBOK and you look at what the responsibilities are of a project manager, the project manager has this thing, the project skill management. And inside project skill management there are specific areas like collect requirements as one of those things. And there are some new outputs that are expected of project managers in the scope management including a requirements traceability matrix, get this, in big bold letters, a requirements management plan and requirements documentation, those are things that have to be there. The requirements management plan being, obviously the closest thing in or very close into your project manager’s core domain of understanding what they’re doing out there. So these cross over. You’ll see them in both BABOK and PMBOK so that the big-- what is it? The BA body of knowledge and the project management body of knowledge from IIBA which is the BA version of it and the PMI, Project Management Institute. So think of that as kind of some industry standards for what a business analyst should know and what a project manager should know. Sorry, David, I didn’t realize that you were hitting me back one question. So in between if you look at what people as professionals in our industry should know those are two core areas. And it crosses over. It’s one of these key things that project managers, if you went back even five years ago you probably would not have seen such focus on requirements, requirements planning and the stability of requirements out there but now it’s starting to change a lot. So when you see that kind of thing it’s just saying, well, wait a minute, this is an area that’s increasingly important when you see how predictive it is on overall quality of requirements, generally within an organization sort of saying, wow this really can have a big impact. And I’ll tell you right now, it’s the one area that more than anything else as a BA, if you’re doing this well, you can really, really shine, okay. So what are some of those pitfalls? And when we talk about pitfalls we’re talking about what people traditionally do. And often times it’s one of these things where people try to do it and they go into a corner and they fill in some forms and that’s not good. That’s really one of those big pitfalls that you can fall into. But let’s talk about some of the others. Big mistake number one. Thinking simply about requirements gathering, okay. Requirements gathering is just one piece of an end-to-end process puzzle. You know, people stop and say I’ve got to go do a requirements plan and kind of your brain locks up because you’re thinking that’s pretty simple. You’re going to go out there and my requirements plan is basically I’m going to go out there and I’m going to ask the stakeholders what they need, that’s it. I mean how much more do you want? And then they’re going to write that down, what they say. And that’s it. And if it’s a $20,000 thing that you’re trying to build then that’s probably okay, you know, it’s going to work. If it’s a $2 million thing that you’re trying to build that’s probably not going to work as a requirements plan because it’s not specific enough. It doesn’t tell you well how much time do I need with those stakeholders? And is that stuff that I’m going to do with respect to scope? Is that stuff with respect to gathering the requirement itself, modeling it, communicating it, analyzing those requirements? Where in here is this really impacting? Okay. And so what you need is to sit back and say let’s not just think of gathering. Let’s think of the entire end-to-end of what it is that you’re looking for, okay. Louise, I’m not quite sure I understand the question. The second thing you need to do-- the big mistake number two is thinking only in terms of schedule, all right. In terms of schedule people will tend to think of the requirements plan as a meeting plan with their stakeholders. Okay. So this day I’m going to talk to this set of stakeholders about this one thing. And that’s not it. It’s more than a schedule. It’s a strategy. You’ve got to think about the strategy of it. You’ve got to think in terms of achieving a certain result on the way through. Okay. So especially with project managers, there’s a desire to get a work breakdown structure, all right. And the work breakdown structure is a result or an output of the process, or an output of the strategy. The requirements activity and the work packages to be able to identify that you’ve got to bring it back to the strategy itself. In order words, in order to get requirements, well what activity is going to be undertaken in here? You’re going to start looking at how you’re going to go about doing certain things. Let’s say you’ve got a union in the mix of stakeholders, how are you going to deal with that? Let’s say you’ve got highly distributed stakeholder teams, how are you going to deal with that? Let’s say you’ve got stakeholders that are all SVPs, does that mean your process changes because of that? So let’s say the plan goes off the rails, how do you get it back on plan? What are those things that you’re going to look for? Because that’s the thing you look for in a good planner, what happens if something messes up? Where do I decide I’m going to get off the one set of rails and on to another set of rails? Because the requirements planning is all about making choices. It’s about making strategic decisions. It’s about communicating those decisions, communicating those choices, and the associated rational with your community. And yes, I would say work breakdown structure is an outcome of a requirements plan for certain, Deb. Okay. The next this let’s talk about risk management. If I sit back and I say, what are the big risks associated with the requirements plan or with projects generally? The big risks are going to be substantial, right. Big risk. Lack of user input. Vague or incomplete requirements, missing or incorrect requirements, change requirements and specification. Those are the four top reasons. It doesn’t matter what year you to go whatever survey about projects and project failure. These are the big four, right. Well, gosh, how many of these are linked to requirements? All of them. Huge. So you’ve got to ask yourself, well why do projects fail? And then you’ve got to say, well, how do mitigate that risk? And your requirements management plan, your definition of management plan is there to help you identify and mitigate risk. It’s there to help you look at and say, wait a minute now, one of the biggest sources of risk in terms of our overall project failure is that we fail to get requirements properly. We fail to get this done right. So how do I manage this in a better way? You know that 70 percent of projects that fail, fail because they didn’t do a good job on the requirements. Learn from the past. Get the stakeholder buy in. Build that buy in through effective planning and then drive it forward. So how can you use requirements planning to add value to the organization, right? You know this is beyond anything else, your time to shine as a BA or a PM. It is the first area where you really have tremendous influence on the overall process. You can influence it at this stage. Once you get past this stage, it becomes harder and harder to influence. You can fix an airplane when it’s on the ground, right. You can change up the engine. You can do all kinds of cool things with that airplane, once it gets up into the air and your project is moving forward, it takes on direction, magnitude, momentum, blah, blah, blah, harder to deal with. Okay. Sorry, I’ve got a bit of a cold on the back end. So we should try to have blah, blah, blah? No. I wouldn’t necessarily have a one-to-one match with the requirements strategy to each of those risk areas. What I would do is say make sure you are taking into account that your requirements plan and the reason you’re doing it is to manage project risks. You’re dramatically reducing project risk because you need to define in the plan how you are going to get user input. What you mean by complete requirements, what you’re going to do about incorrect or missing requirements and how are you going to identify that and how are you going to manage change to the specification. So you’re dealing with some of those categories as elements in your planning document, okay, but you need to deal with some of those different things. So in terms of-- somebody’s keeping track. Carrie, yes, I’m going to the five, right now, okay. Those are the three things where people mess up. Now, I’m going to talk about five things that you can do to add value. Okay. So it’s true, five things you must know about requirements planning are coming up, right. So and Carl, thanks for picking on me there. There is a meta principle, okay. The first thing I need you to think about is value-add from a stakeholder perspective, okay. Value-add from a stakeholder perspective. You need to be thinking about what’s in it for me, from their perspective, because if you go out to your stakeholders and you say, okay, I need the client, I need all of those subject matter experts locked in a room for three months. Well, the first thing people are going to go is whoa, whoa, what do you mean you need them all locked in a room for three months. Oh my God, we can’t do it, blah, blah, blah. You have to be able to express yourself in their terms. You have to be able to express yourself, well, wait a minute now, we need to look at this one particular business area, you know, what I mean, break it down. Talk to them in terms of what’s in it for them? What’s in it for the Q&A team? What’s in for the application development? Let’s talk about what they need to accomplish. And how do you engage them. If you go away into a corner and you just write out the plan, you’ve failed. Requirements planning, the essence of requirements planning of excellent requirements planning is it’s not document. It’s a process for engaging the organization in dialogue and loading the deck for success. It’s all about talking to people about what they can and cannot support. What their needs are and how you can better deal with those needs and how you can better deal with their needs with respect to how you’re going to go about getting the requirements. What if-- Jocklyn [ph?], so what if the PM and the BA both wanted to do requirements planning? Fabulous. That’s great because two different sets of expertise there. One of them is going to have fabulous expertise in terms of the techniques and what you need to do or how you can go about best accomplishing those the goals of gathering the requirements. And the other is probably going to be extremely good about helping you to manage stakeholder expectations, helping you to drive those expectations out into the organization, and how to communicate some of those. So think about that as perhaps the shared responsibility that you want to use within your organization. So it’s not a bad thing. In fact, it often times will share as the responsibility across the organization. How do BA and PM functions-- I’ve had to deal with blah, blah, blah the CIO, okay, doing it his own way? Yeah, well that happens. Okay. So Andrew, one of the challenges that you’re having it sounds like is that you’ve got senior people who are kind of dictating how you do the plan in a certain area. And that will happen, absolutely that will happen. And so one of the things that you can do in that role is broaden out the discussion. You can broaden out the discussion to say okay understanding with the greatest respect, I understand your thoughts on the elicitation area, in terms of how we’re going to gage this aspect of our stakeholder interaction. There are other elements of this plan that we need to deal with in terms of the scoping. Here’s what we need to do. Here’s what we need to do on this side, so you broaden out that discussion. And it helps you to create a better interaction with people. How/where does the requirements planning fit into the SDLC? I would say Louise right up the front, the very front end. In fact, we use it as an intake process ourselves and it works extremely well there. Where is he seeing the questions he is responding to? I’m not sure about your particular question, David. Maybe get you to restate that particular one, for me, okay. But be prepared to explain to each stakeholder requirements planning and what it is from their perspective. Where’s the benefit? So whoever it was that was talking about their CIO, there’s a great benefit in here to the CIO in terms of understanding how much time is going to be required of the organization to do this. So use that. Value-add number one, here’s for whoever was counting, Carl. This is going-- you’re to get to number five here by the end of the chart, okay. The first thing you’re going to do is it’s all about stakeholder expectation setting, okay. And you’re going to use requirements planning to set expectations directly. And directly is what is the expected contribution, when, where, how, why, right? What are you expected to contribute, the timing, the location, type of engagement rational what are the things you’re going to do? And that’s important but even more important is that indirect expectation setting. In other words, directly you can work together with a team of people and they will make certain commitments to you so you’ll say here’s the plan, do you guys buy into this plan, can you commit these resources on these dates and you kind of get a yes or a no, right. Because they all ready booked the meeting so they won’t. So it kind of worked out through that way. The next thing is though, however, is when you use the requirements planning mechanism that I’m talking about here, you’re also sending an indirect expectation that this time we are managing this project very professionally. I’m going to tell you what it is I’m looking for and you’re going to commit those resources. If you don’t, we’re going to debate it in terms of whether I do or don’t but, you know, if you can’t make those kinds of commitments, all right, how do we shift the plan, can we tune the plan, can we work the plan together so that we both meet what it is that we need to accomplish in here. And if we can’t do that then obviously we need to escalate, right, because we just can’t do this project the way we want to do the project. Is it valuable? Okay. Well, we need to get access to the people to be able to do what we need to do, right. So there is an indirect expectation that you’re setting in here that is very, very powerful because it’s all about building your credibility as well. If you do these things in this way we will be successful together. And you build on that. And it really sets your credibility and it really allows you to shine as the go to guy that can get stuff done for the organization. Number two, use requirements planning to confirm your resource estimates because you need to step back and many people they kind of when you say well how long to do the requirements say oh, lick their thumb and they stick it up in the air and see which way the winds blowing. And, you know, are people going to give me a week, are they going to give me two weeks, am I going to get three weeks? You know, like how many days can I get with the stakeholders and meetings? You can’t do it that way. You’ve got to pick a baseline. You’ve got to pick a common unit of work for your company and something that you understand whether it be a use case or a user story or an event, I’ve used all three of those as work breakdown or as requirements breakdown structures. And use cases is what we tend to use the most. And then you’ve got to say, well, how long does it take me to do the requirements for a use case? So that helps you to determine and stabilize your assumptions. It helps you to stabilize your work estimation because if you don’t know how long it’s going to take to do something it’s very hard to get a stakeholder commitment on specific amount of time that they’re going to be available. And then you look at that and you say, okay, what’s the scope of analysis? How many units of that kind of work? How many use cases are there? How long or complex are they? How long on average does it take you to do one of those? And then you plan your iterations around it because each iteration will have its own set of work products around the high level, mid level, lower levels of detail. Let me see if I can knock through some of these questions as I go through. So Bennett, why should so much effort be put into planning and execution gathering <inaudible>. So Bennett, what you have to think about is if you are dealing with a very small project then yeah, your planning activity might take you all of, you know, a couple of hours, go sit down and go have some good conversations with the stakeholders. You’re basically running through the exact same sets of things that I’m talking about. But you’re doing it in a very condensed way. You’re just making sure you’re covering off the bases, making sure you’ve got the right commitments in place, making sure you can interact with the stakeholders you need to deal with. If you’re dealing with a two, three, four million dollar thing, then it becomes much more complicated. And frankly, when I’m dealing with a $70 million thing and I’m organizing 150 stakeholders in through 10,000 hours of meetings, man this has got to be crisp because you’re communicating across so many people and all of their management and all of the workforce teams outside their management areas. All of those people are involved. So the bigger your project, the more this becomes something that is absolutely critical. And as you get larger and larger you’ve got to maintain and manage that stakeholder commitment on the way through. You’ve never done requirements, blah, blah, blah? Rajavit [ph?], what you need to think about with respect to your requirements in this area is if you’re being handed requirements and you need to manage that with the vendor relationships that you have the planning activities that you can do here can help you through some of those change activities because you’re probably dealing with vague or ambiguous requirements in different places. So what you might do is tune what I’m telling you about and say, well, how do I spin requirements planning here in terms of requirements clarification sessions or requirements clarification as a process of working back and forth with your vendors, okay. Because that might help you kind of help people internalize the requirements a little bit more easily. How detailed requirements need to be? Dibil [ph?] I’m going to respond to that in a second. Work breakdown structure first. Our plan first, the plan comes first then the work breakdown structure comes after that because you’ve got to have the strategy first and then the work breakdown structure. How are requirements different from the work breakdown? I’ll have to answer that one in the next bit. What stage do you involve the design time, users? Way down. Way, way, way, AB, way down, okay. Requirements planning right now is really the PM and the BA working together with the business to establish the commitment. Agile iterations. You guys are just trying to see how many of these questions I can ask and how fast I can do this. Agile iterative requirements methodologies. We run our own. It’s very iterative and agile in terms of the way we do it. Physically, however, when you’re dealing in agile project structure with real agile folks like you’re doing scrum or something like your spring zero is equivalent to a requirements planning, really, in terms of how you’re doing it. So there’s different structures that you’re using it and you call it different and you use different words. This structure I’m giving you here is much more of an iterative methodology as you can see just from the detail structure that I’m putting in front of you. That you’ve got high level requirements and you’ve got work products at both the business and IT, mid level business and IT and low level detail business and IT driving out the requirements. It’s much more of an interactive structure in terms of the overall deliverables. But what you need to think about from a requirements planning is how does that work? What are those interim deliverables and what are you trying to deal with? The next thing that people have trouble with is communicating at a level that there’s transparency. If I tell you I need all of your stakeholders locked in a room for 30 days, you’re going to say oh yeah, right, no not going to do that. Forget it. But if I breakdown supply chain systems and I say okay, well, look supply chain systems is the main area that we’re looking at but it includes all of these things. This is what we need to look at. We need to look at the CRM, products supply, operations warehouse, customer service, inventory management, control, blah, blah, and I say okay I need those guys locked in a room for 30 days and you say, wow, that seems like a lot of stuff but I think we can get it done in 30 days. If I tell you instead look transport self is trip editing, driver payroll, regional scheduling, carton optimization, carrier optimization and by the way for that one area alone we’re going to need about seven business days to go in and deal with that okay because it’s about two days each to really get down into the details of trip editing. And they’re going to say are you kidding? Driver payroll or regional scheduling is so complicated that piece alone is going to take you a week. And by the way there are 10 guys and they don’t along. The more detailed you get in terms of what the pieces are the more you break it down. The more people realize what it is that you need to analyze. The more you break it down and you get down to those unique activities, that fidelity okay that details what I’m going to call fidelity. It’s the level of richness in the understanding of the pieces of what it is you’re looking at. The fidelity itself creates manageability because when you get it down to this level of specific activity like use cases, trip editing, driver payroll, et cetera that you need to look at, right, you can get the requirements as either done or not done for driver payroll. Done or not done for carton optimization. Done or not one from trip editing. So you’re breaking down a very, very large scale project into subcomponent pieces that are much easier to deal with. The elements themselves have better stakeholder participation because they have got a more logical connection between a set of functionality that people are going to use and a set of stakeholders that are out there that need to use that functionality. The plan becomes much more credible. The plan becomes measurable because you can say I’m going to deal with carton optimization in a day and you either did or didn’t do it in a day. That’s basically a closed loop process. So you can take very, very large scale, like this one in front of you is like a $700 million project. So you can take a very large scale project and you can break it down into component pieces. What I didn’t tell you is that this is a real project from a Fortune V class company so it’s very, very large. And you’re able to take it down to this level of detail in about the trip editing et cetera, you can take it down to that level of detail in about 10 business days, right. You can drive it down there and get it all laid out so you know what people need to be in what rooms at what time to get through the discussion in here. So guideline number four for I think it was Carl who was counting. Guideline number four, coordinating business analysts. Somebody says how do I know how much detail? A use case is not a use case. You have to sit back and say use cases can mean many, many different things to many, many different people. But this is the way you get down and you describe what you need in terms of detail because there are five characteristics, okay. There’s the focus, process level, business activity level, task or function level. That’s the level of granularity that you can have on a use case. The style it’s either formal or semiformal. Some people have very structured, extremely formal documentation style in terms of what they’re putting into the tool or whatever it is or semiformal. The detail, high, medium or low it’s just comprehensiveness. In other words, I can have a process level use case with fire paragraphs of information, very high level of detail. Or I can have a task function level with basically noun verb combination, a low level of detail, all right. So what is it that you’re looking for as you go down more and more granular? If I just have a flow chart literally I have noun verb level detail. It’s very low level of information. Black box versus white box. What that means if I have a black box functionality it’s like Visa card process. All right, so I’m going to validate the Visa card. There’s no information in terms of how that goes, how you go and do that. White box you’re actually filling in all of that information. You’re putting in the algorithms, all of the business rules, the type is business versus system. So those are the different elements when you’re starting to get into the communication. And if you’re not communicating to that level of detail your analysts can’t get coordinated on the effort of what it is that you’re looking for. And you’ve got to communicate the goal of analysis. So at this stage of the requirements process we want it to this level of detail across these different areas. And you need to communicate the specialized techniques or tools that are going to be used at these different levels. So from my perspective, you can take a use case down to a certain level of detail using some set of techniques. To go below that level of detail and really get into the granular, Louise, you’re using more rule centric techniques to do that. So how do you go and do that? If you’re not using use cases, there are other fantastic techniques to do the same thing. It’s an offline question Conrad you’ll have to ask me about because it’s a long discussion. The last thing I need you to think about is lessons learned, okay. When I talk about lessons learned most organizations they do end of project close out meetings, where they say, oh boy, we really buggered that one. This is what we’ve got to do. They don’t think of it as the requirements planning stage is a wonderful time to think of lessons learned. Hey, last time we did narrative documents and we ran into X, Y and Z problems with that. We could flow this much more easily into our enterprise architecture tools if we use documents with models. Why don’t we do think about doing that this time? Last time we did elicitation using interviews and we basically serially interviewed the people. This time why don’t we use a mix of elicitation techniques and how are we going to incorporate that in? Last time we didn’t do a peer review, we had problems with respect to documentation very serious. This time we’re going to do this. So engage that conversation about what it is to be done. Engage that conversation about what it is to make improvement and actually do a better job on the requirements. Engage that conversation with your steering committee. Engage that conversation with your technology team. Engage that conversation with the people who are your stakeholders because what it is that we’re going to do better this time in terms of the way we’re doing the project. Use requirements planning as a way to apply, okay. So what material needs to be there in a requirements plan and this is the question that different people were asking. Let me give you the subject areas that you need to deal with, having the project resources. Who is doing what? All right. So describing and documenting the stakeholder and participants that are going to participate. The respective roles and responsibilities for each of those people. Yes, Kimberly, the actual documentation or capturing the lessons in each associated where it’s part of what you should be doing in requirements planning because it will guide and shift your strategy and it will guide and shift the deliverables, right. The strategy for each activity, so what are the basic activities that are going to be in your plan, determine the choice or best approach for each of those and don’t forget the technology side of this because if you’re going to use technology you’ve got to train the people in it. You’ve go to do X, Y, Z in terms of the overall structure of that and it’s going to shift what your deliverables look like. You don’t wand to be force fitting it. Communications, I’ll tell you on a little project with 30 stakeholders or 20 or 10 or whatever the number happens to be communication is relatively easy. I mean you can drive it out depending how long the project is going to run, you can run that whole process of communications. There’s certain things you must do well. But you can run it fairly simple. But when you’re dealing something that’s got 50, 70, 100 whatever it is stakeholders, I mean the communication becomes the fulltime role of a project. There’s a lot of work that you’ve got to do. There’s a lot of stuff that you have to do when you’re communicating that out into the organization. The next part is the high quality requirements plan has to have decent well-articulated work products. I mean I hey you guys are doing the requirements, right? How do you know when you’re done? Well, you’ve got to describe what done looks like in your plan? You know, describe the documents and the artifacts that have to be produced and the level of detail and the tests of quality that you’re going to apply. Put that in the plan, right. And consider the production of work products that are going to augment your specifications document. So what needs to be there? What are the minimum conditions of quality associated with this, how are you going to test that? Because that makes a great conversation with your steering committee. This is what we’re doing and how we’re doing it. The work plan itself which is your work breakdown structure, okay, so meetings, when are those going to be, what are the outcomes associated with the work division strategy. And work division strategy really applies when you’re dealing with larger and larger types of projects okay because you might have a team of 10, 15, 20 analysts. We got one now with 20 analysts working. They need to understand who does what to whom and what’s the order of responsibility and the project structure. So people want to know what does the plan look like? This is what one of ours looks like, very simple, not complicated. By the way, you have to execute with situational awareness. All right, so the process remains the same. In fact, I would encourage you, have this presentation beside you when you’re doing your requirements planning even if you’re doing like a $15,000, $20,000 thing. Just have it beside you and just go through the checkbox thinking on each of the slides okay, did I do that? Did I think about this? Anything special here? Anything special here? Just go through it and just have it there. Your requirements plan may take you all of on a $20,000 thing an hour and it might be half a page if that. And you’re doing it that way so that you verify the interactions that you’re going to need to have with the customer. And you’re verifying that set of things that you need from them as you go through each of these areas. That’s really what you’re ending up doing, right. If it’s a $10 million to $15 million project, even if it’s a $1 million project dealing with a complex organization you may need to take a day or two to got through and develop this, and then negotiate it back and forth with the people that are involved that you ensure you have buy in. Here, you are the team lead. This is what I need from you. This is how many hours I’m going to need with your people. This is how we’re going to conduct those discussions. This is why this time is different. Are you committed to doing the same things I’m committed to doing and getting to these kinds of results together? Because if you’re not, I’d rather know now than find out a month from now. And that will help you dramatically improve what you’re doing. June, no problem, you can have a copy of my slides, but you’ve got to send me an e-mail and that e-mail address is on the last slide of my deck and that just basically keeps you around. Yeah, I made a misspelling, have I? That’s because I grabbed it out of a real plan. I guess I hadn’t fixed it yet. Sorry about that, Melissa, thank you for catching it. So closing thoughts, think of value-add when you think of requirements planning. I have one plan, by the way, Melissa, it’s well in excess of 100 pages and that’s because we’re controlling a $70 million project but this particular one here is much shorter because you’re controlling a $5 million project. It’s about situational awareness. Some of them are very, very complex. Some of them are much more simple. Joseph, 900 people participating the call. You have to send me and e-mail and then I can respond to that relatively quickly, okay. Think value-add when you think of requirements planning. You have to think value-add. Don’t just go into a corner and fill in a template. If you fill in a template you’ve not accomplished the value-add. The value is in the conversation. It is a process not a document. It’s about negotiation. It’s about what’s in it for you? What’s in it for me? How do we manage balancing that together and jointly achieving what it is we need to achieve, okay. Yeah, you can get a copy-- I don’t know if I have a copy of a plan that I can share with you. We do have an example up on our website, if you want to go take a look in there. The use requirements planning to set you apart from the pack. And I’m telling you right now, this is the one area where you can really shine as a business analyst. If you take one thing away, okay, from this conversation today it’s requirements planning is the area that will help you shine as the go to guy. Because you’re the one that can help the business figure out what to do to be successful. That’s powerful. That’s exciting. That’s what you need to accomplish as a business analyst. Hey, these are the techniques. This is how we can go get this done. This is how we can better execute on what it is that we’re trying to execute on. That makes you the go-to guy. Requirements planning will set you apart if you’re great at it. And oh by the way it’s a litmus test. Organizations that are not great at it tend to be really lousy at doing requirements out there. It’s an almost direct one-to-one relationship. Track your results against your planning. You’ve got a closed loop here, right. If you do a great job on planning, you should be tracking your results against that. We’re doing one project. It is a-- well midsize, large, $20 million client side spend and we are currently tracking plus or minus three percent. Three percent on plan. That’s not bad. You need to do the same kind of thing. How good are you at forecasting? And oh by the way, when you first started forecasting it shouldn’t be any big surprise, you’re going to suck at it. You’re not going to be great but after a year, after some period of time, you’re going to get that much better and you’re going to be setting very, very, very tight expectations with stakeholders and achieving good results. So hopefully I have accomplished the business objectives today that we’ve set out. Again, if I didn’t accomplish these objectives of setting and illustrating the pitfalls of traditional approaches, I said three of those. I gave you guidelines, I hope for making requirements planning and value-added activity. I gave you five of those, Carl, five. I gave you five in that area. And knowing that and I’m cheating you Carl, no, I don’t want to-- anyway, and knowing what material must be present in a high quality requirements plans. I hope I’ve accomplished that in the last slide on the way through. Hey, by the way, we’re in this business. One slide on IAG again reminding you if this is something that you need help with give us a call. If you’re trying to drive a project and you really need somebody that can do this well and can work together with you, this is something we spend our lives doing, right, give us a call. And then there’s the REP, the PMI information, the CDU information if you’re interested in that stuff, and my e-mail address. For all of those who are interested in getting the slide deck e-mail either me or Adrian and either of us will be happy to send you the slide deck on the way through. Yeah, Louise, my point with respect to it’s not a document. It is a document, but ultimately speaking if you only deliver the document without the discussion you failed. If you deliver the discussion without the document you’ve actually probably succeeded to some extent because you’ve set the expectations. So the most important thing is the discussion. It’s the interaction with the stakeholders. It’s the setting of expectation and the description around the expectation that really sets it apart and makes that work. Danielle the presentation will be available outside of this webinar. I believe Adrian is actually taking a recording of the session today and he’ll have that on Modern Analyst. The other thing that you’ll do is you can go on to the IAG site if you want it right away and you can listen to another one that’s been recorded. How does it change depending on the environments? Well, when you get into, Ryan, agile specifically, you’re going to use different set so techniques. Specifically, you’re using a sprint zero to do this type of planning. And you’re going to do backlog building which is different in agile scrum as an environment. They’re using different sets of techniques, different approaches to drive it through. But essentially achieving very, very similar results because in agile what you’re doing is you’re presetting ways that you’re going to work. We’re going to run certain meetings, certain scrum meetings, we’re going to take an hour a day to do that set of activities. These are the interactions in the controls. This is the way we’re going to build the backlog blah, blah, blah. So you’re doing different kinds of things but you’re essentially accomplishing very similar kinds of outcomes. Real life value in using SharePoint to better and centrally locate these plans and artifacts. Carl, we actually use SharePoint on very large activities and it works extremely well. It is also I hate to say this, I hope there’s no Microsoft folks on but it’s a very pesky technology. There are certain things that are fabulous about out it and it’s wonderful in certain areas. There are certain things that are pesky about just in terms of how fragile it is sometimes. So when you’re dealing with large stakeholder groups you have to have some mechanism for sharing back and forth large volumes of iteration sensitive documentation and you need technologies like that that can do it. So to shine and to transparently show the scope of work, yes, absolutely Edward. Absolutely you need to share the scope of work and the risk of not doing the work and that’s fundamental to the plan as is the discussion around what you’re really trying to accomplish because if you- if you have that discussion around what you’re really trying to accomplish then people get on board with that. They say, okay, I understand the strategy and we’ll have those people available and they’ll start working together with you. Is there a specific methodology at which you can estimate the requirements gathering phase correctly? Yeah, Deb, it’s-- and I’m shortening up your name, Deb. So there are methods that we use ourselves and part of that is based on experience and part of is based on at what stage you are. But if you basically say that the initial gathering phase is one unit of work then the detailed phase typically is going to be three units of work, et cetera. So there are certain ways of doing estimation along that path and the initial scoping is like a quarter of a unit or is a fifth of a unit of work or something like that. So there are different mechanisms that we use ourselves based on those kinds of ratios. There are some good data out there from Gartner that can help you do that in terms of the amount of effort to any given stage of the project. Requirements itself statistically is about 18 percent of a project. The average project out there about 18 percent of the resources are spelled-- are spent on requirements. Now, low maturity companies will tend to spend a lot less but they also have much, much higher volatility in terms of on time, on budget performance. Very, very high maturity companies will tend to spend a little closer to 20-21 percent. But the average company will spend in around 17-18 percent and those statistics just keep coming up over and over and over again a bunch of studies have proven that. So you’ve got to plan in around that as the total volume of stuff that you’re going to do but it’s not all the initial gathering of requirements. There’s the initial and then there’s the detailing and blah, blah, blah all the way down through. Okay. So hopefully that gives you some basic numbers, where can you find info on the detail on work plan activities. If you go up on our site at, Edward sorry, to www.iag.biz, there are probably 100 pieces of content that you can look up there that will give you a lot of good information on the kinds of things you should look for. The other thing in terms of the plan and the activities Edward that I’d point you at is just go through this presentation, again, just have it beside you and look at it and say well, did I think about that, did I think about this, did I think about that, as you go and build out the elements in your own plan. And then last question, Leona, should the requirements plan be accepted by the stakeholders or should it be an internal document? Personally, it depends on the size. If it’s a larger project, then absolutely it should be getting the stakeholder involvement and acceptance whether you make that a formal acceptance or not depends on your PMO and its processes. But personally, I like having a good conversation with a stakeholder, looking them in the eyes and saying this is what we’re doing, right? Okay. Good. You’re going to have these people committed and this is who is going to organize the actual logistics of the meeting rooms and blah, blah, blah, all the way down through. By the way this is what we’re going to be delivering as a sample, literally, are you good with that? Okay, yeah. And just kind of walk through every element of it that way everybody is on board and you start talking through well how are you going to hand this off to other organizations and et cetera, et cetera. So with that, thank you very much for everybody’s attention and time today. I need to turn this back over to Adrian before he kicks me off the line.
Host: No, I wouldn’t do that to you Keith. Thank you Keith for a very informative presentation. I see lots of great feedback. And thank you for those that are sending thank yous to Keith because I know that gives encouragement to do more and continue to provide you with lots of useful information. So thank you, again, to all of you who attended the Modern Analyst webinar. And thanks, again, to Keith for, again, a great webinar presentation. I wanted to, again, remind you as Keith mentioned that the webinar along with the slides will be archived at ModernAnalyst.com on the webinar page, within a couple of days. So you will be able to not only download the slides but also you’ll access the recording presentation. Thank you again for attending. This concludes today’s event. Have a great day.
#### End of 2011-02-15 10.01 5 Things You Must Know About Requirements Planning ####