AMCHP 2005 ANNUAL CONFERENCE
DELIVERING RESULTS, IMPROVING PREGNANCY & BIRTH
February 19-23, 2005
SHERRY SPENCE: Good afternoon. This is going to be a little bit more up and down and interactive presentation so I need to have you tell me if you can hear me when I move around. And where’s the light go? And also I’m technologically impaired so you’ll have to forgive me. I’d like to just briefly acknowledge about a thousand people. So I’ll just say that we have a lot of partners and I want to acknowledge all of them, especially the families. Developing project systems calls for a lot of plans and to me this baby is asking, you planned this? The first steps in developing project plans then are to agree on a business goal and you saw a lot of this in the previous presentation but I want to just touch on them lightly. To describe the project and identify the stakeholders and some of the early planning documents and even some later planning documents are on that back table. There are also, I think, some folders left if you want to have something to carry all this paper away with, to define the scope of the project and to develop the project requirements.
And I’m going to just start with the assumption that we’ve got a basic idea and we have the basic go ahead to deal with that idea and to move forward in developing plans and that we’re at the requirements defining level for this exercise. The project documents then, that I have out there, are an executive summary. The project description or high level requirements document for part of the family net project, I’m not going to give you a description of Oregon ’s project, those of you who’ve heard me speak before are going to be surprised by that. But I’ll only describe family net in so far as we need to, I had to get the name in there, in so far as we need to understand it to understand what I’m saying about our experience in Oregon . But basically this process and some of the tools I’d like to talk about are applicable I think to any organization and I’m trying to keep it about as neutral as I can. If you have, for that reason, if you have any questions, because I was too technical or too specific to Oregon and didn’t realize it, please feel free to ask them as I go through.
Anyway, these are sort of the project documents that you build as you’re starting to build a plan and develop system requirements. And this, to me this baby is asking, do I really need this? Some of the problems that we’ve run into when we’re trying to define requirements are sort of the standard. The IT folks are over here and the program folks are over here and we have some problems just at the get go and they’re kind of expressed as users saying, woops I’m going to back up a little, I went too far. I’m sorry, I think the order is not what I expected so let me see if I’m missing something. So the users say is, nope, we are missing some slides. If you’ll follow on the handout, we won’t bother with the technical difficulties here. If you’ll follow on the handout, developers say we don’t speak the same language. Users don’t understand system limitations and capacities. Users should just tell us what they want and what they need and we’ll decide how to do it and they can’t do that because they don’t know what they need. All technical experts speak their own language, users developers and everybody else.
So one of the communication needs is to begin to understand each other’s technical languages. Users and developers do need to understand each other’s concerns. Users shouldn’t become technical experts. Developers shouldn’t become program experts, but they need to understand each other’s concerns. So one of the goals of any requirements developing in the design phase is to have early regular communication between users and developers and to do a lot of working together. Projects where the users put forth a document like one of those out there and the developers pick it up and go off and run with it, our usually a failure because usually the developers don’t really understand what was meant by the document and the users do understand what they need at the time that the development is happening and that’s the last comment, is users don’t know what they need. The problem is that a new data system, especially an integrative data system changes the process. And when it changes the process, it changes the process needs, the users come back and say, no, that’s not what we need now. And so, no they don’t understand what they need.
This is another reason why the development process has to be interactive between users and developers, which takes a great deal of time, which is why you have to nurture partnerships. Now, I’ll go to the developer’s side of the conundrums or the user’s side of the conundrums. The users say developers should just tell us what the system can do and we’ll decide if and how we’re going to use it. Well, as you know, until you have the needs, you can’t say what the system is going to do. But users very often want to have something to look at, to react to. So again, you have a problem. The developers are saying, well, what do you want and the users are saying, well, what have you got? And nobody knows what anybody else needs or wants. One of the approaches we have taken in Oregon is to use prototyping to build screens and throw up design screens on the wall and start talking about how those screens would work and who would do what to drive out both the processees and the needs. And you do need tools like that. They’re usually interactive tools and again you need everybody in the same room at the same time participating in this.
Another user myth, developers don’t understand what we say and we have to keep explaining things over and over and over. That isn’t really the case. What’s the case is as you go through the design cycle, you’re looking at first high level requirements and then you have to go back and flush those out and then you have to go back again and get to excruciating detail because that’s the level at which data systems work. And to do that you have to keep going back over and over and the users often get the feeling that the developers aren’t really listening to them the first, second, or third time. And that’s not the case it’s just that it’s an iterative process. Basically these comments express the frustration felt on both sides. The first time people get together, everyone tries to work together and to, and there’s a lot of positive energy on all sides, but there are misunderstandings, it doesn’t work. So these kinds of comments are expressions of the frustration of failures in communication and of people trying to sort of manipulate and those guys did it right but those guys are wrong.
These guys are the users and you guys know what you want, but these guys keep saying they don’t know what they want. It’s a response to a frustration of not communicating effectively to sort of blame the other group or to try to manipulate the other group to move in your direction. So these are, when you hear these kinds of comments, that’s your clue that the process isn’t working and that you need to bring people together and start talking through what the basis is for the understanding and what the basis is for the misunderstanding and work that out. When I interview, as I do sometimes, developers, when they say, oh users never know what they need, I know I don’t need that developer. So here are some of the communication comments that I sort of want you to take away from this. All experts speak their own language. We need to communicate the what, and the why to each other and work out the how together. Nobody knows the detail I’ve seen. It gets incredibly detailed. And the data system will change the process. And you need to be prepared for that to happen on all sides.
You need to understand that the only way it can change the process in a way that really works for the users is for the users to be present at all times, for the developers to be present at all times, and that’s why the partnership building that Mike talked about is so important because it’s a very long term commitment. Now, I’d like to do an exercise in defining system requirements and I think this baby is saying, exercise, okay. Everybody grab your toes, but to do that I want to do some definitions. Now a definition according to John Ralston Saul is an opinion presented as truth in alphabetical order. So this is my particular opinion and I don’t claim that it’s the truth. But after we’re done with this process and this tool and this approach, I hope this opinion will work for you and until you develop an opinion of your own. And if you already have one, please share it because that’s what we’re here for is to share tools that we’ve found that work.
So the process we’re going to go through is developing high-level requirements. This process works really well for high-level requirements and then a more detailed process like prototyping or like use case development works at the detailed requirement level. I wasn’t planning on getting into those today because of time constraints, but we can talk about them in the wrap up if you’d like to. So this is where I’m going to get sort of interactive and I’m going to start handing out things, so could you? If you can’t hear me I’ll go back up where I belong and stop wandering around. So just raise your hand if you can’t hear me. The first thing we want to describe is a business goal and can you just take one of these and pass it down. And what we’re going to do in this exercise is define each of these things and then do them as part of the exercise. So a business goal, are there enough of these? Do you have enough? So a business goal is a strategic statement of the proposed system’s responsibility. It’s how the software system will support the business processees.
So the next thing you need to define is those processees. So a system process is a sequence of events that yields an observable result as to how you do a specific act. A system process then is a sequence of events that yields an observable result or results of value to a specific actor or actors. So what’s an actor? I’m going to make you work a little harder handing things out here. An actor is an entity that interacts with the system to fulfill a business goal. So an actor isn’t necessarily a person, although an actor can be a person. An actor can also be an organization or a group such as another agency that you need to interact with. An actor can be a system because you may need to link to another system or you may need to accept data from another system. So an actor is any entity that interacts with the system in order to fulfill a business goal.
UNKNOWN SPEAKER: When you reach the end of your line, stop.
SHERRY SPENCE: I see I’m causing more trouble then—
UNKNOWN SPEAKER: No, no, no, no, now you can move.
SHERRY SPENCE: Okay, a constraint, may I borrow this? A constraint is a statement or rule that is externally imposed. When you’re defining processees and actors for your system that’s going to support your business goal, or your business function, you’re going to come across certain things outside of your control, that are going to keep you form doing something or keep you from moving to a step, and those are constraints on the system. And your system is going to have to take account of those, so you’re going to have to define those in your requirements. Another thing you’re going to need to define, excuse me, is an assumption. Thanks.
An assumption is a statement made about a process or product that is not based in fact. It either has a high probability of occurrence or if it does occur, it represents a risk to the project. So it maybe a positive assumption, it may be a negative assumption, but it’s an assumption that you need to make in order to proceed with your requirements gathering. And so you need to state what the assumption is, and as your developing your project monitoring activities, you need to identify how you’re going to deal with that assumption. So very often assumptions, constraints and risks are related. A risk is a discreet occurrence that can affect the system development project for better or for worse. So a risk is are we going to get CDC grant funding or HRSA grant funding or state funding for this project? And if you do get it, it’s still a risk it’s just a positive risk. So as I think you can see, the assumptions and risks and constraints are all factors that impact the processees and actors. So we need to take account of them and from the beginning of requirements gathered, we need to identify them to the best of our ability.
I want to thank you for helping me hand out these pages. Now our exercise, oh I, just a little thank you to the words as Liz Carroll says when I make a word do a lot of work like that, I always pay it extra. And so I should be paying you people extra, so I’ll give you double what I was paying you before. Our exercise I want to do in two phases. The first I’d like to have you help me define a business goal and for the second, I’d like to have you define the system processees and actors that would be needed and as you’re going along, if you identify constraints or risks or assumptions, I’d like you to define those also. So we’ll put the business goal definition up here and then as you identify, I have color-coded tablets that you can pass back for me. Some are on the table and you can pass back for me and pens, so we can identify maybe the business processees and the actors for this project and then the next slide shows us what we’re going to do. What we’re going to do is web enable a pet grooming service. I know this is right up your alley and so I think you’ll all be qualified to do this.
So the first thing I want to ask you to do is to define the business goal in one sentence and help me put together, what would you need if you wanted to web enable your pet grooming service? What would be the goal of the system, the web based system that would do that? What would you want it to accomplish? Anyone.
UNKNOWN SPEAKER: Easy access for the customers (inaudible).
SHERRY SPENCE: Okay, let’s write that down as a process, easy access and post it up because we don’t have to do these things in order. So that, right behind you on the white paper, just post it up. But overall, what do you want the goal to do? Overall, what do you want your pet grooming service to do? Do we want to schedule, do we want to-- Yes?
UNKNOWN SPEAKER: We want to allow clients to use the layout.
SHERRY SPENCE: Okay.
UNKNOWN SPEAKER: Arrange for the (inaudible).
SHERRY SPENCE: As you see, I can’t write. Okay, that’s-- Yes?
UNKNOWN SPEAKER: Well, I think we really, what we really want to do was to expand our business and increase our profitability.
SHERRY SPENCE: Okay. Another hand I saw somewhere.
UNKNOWN SPEAKER: I was still with the first five in saying all individuals with dirty dogs can find this on the web. And I think he was on (inaudible).
UNKNOWN SPEAKER: Not just dogs though.
UNKNOWN SPEAKER: I know.
SHERRY SPENCE: Okay, good. Do we want to bill folks on the way out? Do we want to do, keep track of who our clients are and where they live? Do we want to have access to mapping?
SHERRY SPENCE: What we’re talking about is a data system process that would support the business function. If you have a business function that you need to document, that’s going to be either a constraint or an assumption. This is a pet grooming service. For example, has anybody come up with a process yet? Scheduling, okay so scheduling, so write what you think the system should do with respect to scheduling. Any other processees, yet? Billing. Billing and accounting. How much should the system do with billing and accounting? Or if this is, if this feeds into an accounting system. Okay. So what, just very briefly, to whom should it report about what? Just write down what kind of reporting you want it to do. You can just post your card if you want to. Post your paper that you’ve written it on. Then you don’t have to, no you don’t. Just post it just on any one. You can post the sticky notes on the white paper that is next to your table. Remember that this kind of the blue-sky phase, so everything you think of is okay to write down. We’ll worry later about whether we can do it all.
Okay, and you can write one process per sticky note page or you can write a bunch on one page, it doesn’t matter. Okay, I see a lot of discussion but not much posting of things. So that’s okay, there’s not a wrong wall. Are we getting to a point where we can start to wrap? Do you want to go for another five minutes or do you want to stop and talk? I don’t want to stop you if you’re on a role here. Okay, how many of you are ready to stop and talk? We’ll do another couple of minutes then. Okay, lets, is everybody comfortable with stopping and discussing this process for a few minutes now? Because I don’t want to cut you off if you’ve got a good thing going here. This would be a sideline for you being that public health employees aren’t so well paid. Yeah, if you were a dog groomer, you wouldn’t have to work on Sundays. No, I don’t think that works.
So, the next step with this process that we can through a little bit is to start discussing as a group what we’ve been posting as individual folks and you can do this in any of a number of ways. You can have group report back what they discussed or you can just sort of talk through what’s posted on the boards as a group. You do need a facilitator for this process, because you need somebody who starts taking all of these stickies and grouping them together as the discussion goes on. So, lets kind of model that a little bit without actually taking the time to do it. How many of you had something about billing or accounting? Okay, Ken? Does anybody that’s written down just on one piece of paper that we can start? Can we start with that then? So we’ll go through and we’ll kind of find things that are the same topic. One of the things to encourage with this process is to encourage any amount of repetition that it takes to drive out the full extent of the need. So saying something somebody has already said is just fine, that’s not a problem.
A problem would be missing something that everybody knows but forgot to say, so the more repetition the better. We’ll put our processees over here and this says billing receivables, payables, payroll insurance, pretty extensive here. The last one, equipment, yeah, equipment purchases I guess is, then I’m going to ask you to put that over there since you so kindly labeled that as actors. I see one here that’s scheduling, tracking, inventory, staffing reminders, free coupons, marketing recalls. More processing. Billing, scheduling, service identified, reporting, customer targeting, advertising, so these are more processees. Any more processees that we haven’t mentioned or even that we have? Can I have that? Lovely. That’s, great, great stuff, okay. Well, that’s important you know? Yeah, that’s important. Do you handle large dogs, you know? Well, or do you schedule large dogs along with large cats at the same time? Yeah, I know. Does anybody do gerbil grooming? Or dentistry, yeah. This could be very extensive or very simple.
So we’re starting to identify processees and we’ll start to group them so that we’ve got two kinds of monitoring here. We’ll put those together under monitoring. We’ve got several kinds of billing over here, we’ll put those here. Recall will go under reporting and we’ll put all of our reporting stuff over here. This is scheduling, we’ll put things with scheduling, so you start to group and it’s best if you can get folks to put each process on a separate sticky note, so then you can start to group and the fact that you have multiple perspectives on the same process gives you a little information to help flush out exactly how that process is going to work and to stimulate discussion on, well, what do we want to do or not do with respect to, are we going to do billing or are we going to send it to an accounting system we already have? Are we going to do scheduling or are we going to send it to our other scheduler system or to our paper system if in fact, that works better? So that kind of helps you get that out.
Did anybody come up with any actors? I know we have some here, owner, groomers. So we have critter, is an actor. Well, is a critter, this is a good question now. I a human critter is an actor, is the animal that is being groomed, does the animal that’s being groomed interact with the data system? I would say that that goes under risk. Pet owners, staff, web master, business employers or employees, suppliers, good. Software vendor, staff, customer, system developer, general public, humane society, great, okay, see you guys have a second career here. So could you post those under actors? And as you did with needs, what you’re going to do with actors is put them into groups. You have sort of a stakeholder group that may fall into different categories. You have the immediate user group that again may fall into different categories.
You have the group of people who don’t interact directly with the system but need to receive something from it, reports or something. And you’ll categorize those, again, kind of grouping them on with the sticky notes, and again it’s best to have each actor as a separate sticky note and then you sort of group them into categories. And then you can turn this into a document that when you get back together with the same group or with a larger group, you can sort of go through that document and there’s an example of a high-level requirements document on the back page that was in fact developed using this system, on the back table I mean. So you go through those and the thing you want to drive out first to the extent that you can are the processees and actors and you need to really flush that out. But as you do that you start picking up constraints and risks and assumptions and you need to start defining those as maybe the second time you go through this process.
Any more actors or processees? Okay, and as a risk, okay. And this happens. Sometimes you’ll have an actor but this actor will also be a risk. If you have for example, lets see, could you put that on actor? A previous employee, might be both an actor and a risk. What are some of the risks, has anyone identified or constraints or assumptions about a pet grooming service? Okay. Is that a, the pet disease is certainly a risk and whether or not the pet is trained is a risk. What is there, is there an assumption that you have to make in order for this to work? Or is there a constraint?
UNKNOWN SPEAKER: Well, a constraint is the capacity of your business.
SHERRY SPENCE: Okay, so a constraint is that you don’t have a veterinary service, this is just a grooming service and so a risk would be that somebody didn’t understand that. An assumption would be that it is clear to everyone and you might want to state it all three ways, depending on how important this is. The understanding that you’re not a medical provider for this animal is a pretty critical one and you might want to have a constraint, a risk, and an assumption about it that you can track and verify that that’s working. Any other constraints or assumptions?
UNKNOWN SPEAKER: Capacity of your work force.
SHERRY SPENCE: Very good. Very good. Yeah. Do you have the staff that you need? Are they able to interact with the computer? Are they able to interact with the animals?
UNKNOWN SPEAKER: Well, do you have enough staff to handle the increased business?
SHERRY SPENCE: Right. Yeah, if you’re assuming, we’re assuming that this is, we’re going to expand the pet grooming business by doing this, do we have the capacity to do that? So that would be both a risk and an assumption. Are there any other constraints that you can think of off hand? External forces that might impact your ability to do this or not do it.
UNKNOWN SPEAKER: Business (inaudible).
SHERRY SPENCE: Yes, that’s a good one. Yeah.
UNKNOWN SPEAKER: Zoning requirements.
SHERRY SPENCE: Zoning requirements, that’s a good one, but is that a system constraint or an external constraint?
UNKNOWN SPEAKER: External.
SHERRY SPENCE: Okay, and you need to be careful. You need to make sure that when you’re defining constraints you are clear that there are constraints on the data system’s capacity to do its job as opposed to constraints on the business ability to do its job. You may need to report both. But you need to be clear which one you’re talking about. Anybody think of interstate issues for pet grooming service since the web goes everywhere? Somebody in Sri Lanka wants you to groom the pet.
UNKNOWN SPEAKER: As long as you don’t say we do a home business.
SHERRY SPENCE: So you might have a geographic constraint. You might have some legal constraints about going across, outside of your state if we have licensing. Okay, this is, I think we’ve basically, you’ve basically got the idea. Are there any questions about how this process is used? It generally works really well, if you focus on the actors and processees in the second session and you have one session that defines the business rule. And then if you can get people together for all day, in the afternoon you start talking about actors and processees. And then bringing people back to look at the work they’ve done, go back through it, and wordsmith it, work through it. Make sure that it’s fully accepted before you go on. And then start adding in constraints and risks and assumptions and as you do that you’ll find yourself adding in more processees and actors. So it has to be a very interactive flowing process until you get a basic document done. Then when you have that basic document, you have something that gives everybody who looks at it an idea of what this is going to do and who it’s going to do it for, and how it’s going to help them, and gives them a pretty good overview of what this system is. And of course, as we know, that’s just the beginning.
HENRY MAINGI: Okay are you done or are you?
SHERRY SPENCE: I’m not done.
HENRY MAINGI: You are not done. Okay continue. I’m sorry.
SHERRY SPENCE: If you’re tired I’ll quit but, just to give you a quick idea of what we’re looking for, we want an approach that highlights communication and collaboration. So if you can get an approach, and this is where I said, you’re getting my opinion here, which will work until you have an opinion of your own. Whatever approach that you come up with, that highlights people talking to each other, and communicating and collaborating, is the approach that you want. You want to identify what you need, not how you’re going to do it, but what and why you need first, and that’s what we focused on. We didn’t focus on the technical difficulties here. We just looked at what do we want to accomplish? You want the let the system change the process and not say no, you have to stick with what you’re doing now. You want to let free flowing thinking happen first. Then you can narrow down the scope for phase one or for the whole project or whatever but you let whatever you do, you don’t want to keep the system from changing the process because the beauty of an interactive system or of a data system is that it can help you streamline the process. And so you want to be open to that. You want to make sure you’re providing an environment where users and developers are comfortable. So if you have a group that’s not comfortable with this process you need to find something else that works. If you have a group that’s not comfortable with the process you’re using, you need to be creative to find something else. And you need to have something that develops interaction, communication, and trust. It needs to be something where people can open up and talk about what they need and talk about where they are and talk about the good, bad, and ugly of whatever they’re doing. And thank you very much. These are Oregon ’s websites where you can go look at the family net newest module that’s in development or look at project management tools or just find out where I’m from and what we’re up to. And now it’s time for a break.