Episode Transcript
Speaker 1 00:00:06 Welcome to I see what you mean a podcast about how people get on the same page or don't, or perhaps shouldn't today. My guess is Rami hago. Rami's a friend in federal government consulting colleague with a background in military and veteran's health it. Rammy welcome to the show.
Speaker 2 00:00:22 Hi, Lou. Pleasure to be here.
Speaker 1 00:00:24 Thank you, sir. I'm looking forward to our conversation.
Speaker 2 00:00:26 Yeah, me too.
Speaker 1 00:00:28 Why don't you start with a short bio about yourself.
Speaker 2 00:00:30 Thanks Lou. I've uh, I've been in it federal consulting for the past 23 years. Wow. And, uh, yeah, as started 1998. So right around the time when people were starting to just get, start dealing with Y2K, right.
Speaker 1 00:00:49 That's right. That's right. Yeah, I remember that.
Speaker 2 00:00:52 <laugh> and then, uh, so I worked in a, a, a variety of roles. I initially actually started off working at a help desk and the doing a lot of end user support. And from there I went and I, instead of supporting the systems, I started work in NQA to start to Uhhuh, write, break the systems <laugh>. And then from there I spent a few years doing that, and then I actually started to become a business analyst to started to write the requirements for the system <affirmative>. And I did this for a variety of federal agencies. Mm-hmm <affirmative> started off at the department of justice. And then from there, uh, was at the department of labor. And then for the past eight years have been at, at the VA mm-hmm
Speaker 1 00:01:35 <affirmative>.
Speaker 2 00:01:36 So, you know, my, my roles have morphed. The agencies that I've worked more have also changed throughout the years, but it's a, uh, it's primarily been in it systems, a variety of different kinds of systems, uh, grant management systems and, and other systems
Speaker 1 00:01:51 Like that. Wow. But I like that progression starting because people who are in customer, who, who on call centers have a very unique view mm-hmm <affirmative> of it systems, not in a technical way, but it they're getting calls because someone's having a problem.
Speaker 2 00:02:06 Right.
Speaker 1 00:02:06 So then you moved to QA, would you say QA quality and,
Speaker 2 00:02:10 Yeah. Right. So I took that knowledge and I said, that's Yeah. How can I basically, for lack of a better term break the system before the users right. Get to that's cool.
Speaker 1 00:02:20 And then, like you said, you sort of moved upstream to writing the requirement for systems. That's a great
Speaker 2 00:02:25 Requirements. Yeah. And then becoming kind of a, a business architect. And then the last few roles that I've had have been a project lead program manager, and, you know, now an agile kind of a, that team.
Speaker 1 00:02:38 Right. Cool. Lead
Speaker 2 00:02:40 Sort of role.
Speaker 1 00:02:40 Well, and you and I worked together at the VA for a bit on, and, and with the, um, uh, working on veterans experience, right. As a customer experience veterans experience. And so there's a lot to get people on the same page about making it work for a user, like a veteran mm-hmm <affirmative> or, or, or a military member. If it's a, if they're active or making it work for people in the organizations who have to do something with the data, whether it's processing benefits applications or, or healthcare, medical records, billing, it's just, it's all it. Right. And there's a lot to, of, to a lot to get there's a lot to get on the same page about one of the questions I usually ask is what are you getting people on the same page about today? And you could just take that and run with it. But what occurred to me as we're, as we're recapping your career and the roles you've played in it? Well, what's been some of the most interesting challenges of getting people on the same page. <affirmative>
Speaker 2 00:03:39 Well, that's an interesting question. I think the biggest challenge really is, is the people. And I guess when I say the people, I mean the culture
Speaker 1 00:03:50 Mm
Speaker 2 00:03:51 I've worked on it. Systems where we are replacing a legacy system that has been around for 30, 40 years and with the inherent, you know, an obvious reliability that folks have have on the system, um,
Speaker 1 00:04:10 Familiarity with it. Yeah.
Speaker 2 00:04:11 Familiarity and their comfortable and, and it's, and it becomes everything that they know when, especially when I was at BA oftentimes I was the sort of a tip of the spear. Right. So I had to go in front of these users to explain to
Speaker 1 00:04:25 Oh yeah, yeah.
Speaker 2 00:04:26 And elicit their requirements or their, you know yeah. Their needs yeah. For a new system. And, you know, looking back on it, you know, I, I, I did often run into a lot of conflict and that conflict wasn't apparent to me earlier on in my career, what the motivating factor for that conflict was, I could just dismiss it as well. These folks just don't know the benefits of the new system or they, you know, the they're they're set in their ways. Right,
Speaker 1 00:04:56 Right, right, right, right.
Speaker 2 00:04:57 You know, all those sort of common things that I would, you know, kind of try and drive through without sure.
Speaker 1 00:05:04 Because you had a job to, do, you had a job to do, and you were just trying, well, then as you, throughout your career, as you experienced more, learned more and took on different kinds of responsibility, what did, how did you, what did you make differently of the conflicts then? What did you make different? What, how did you size it up differently earlier on you just thought, uh, they don't get it then later on. What'd you think?
Speaker 2 00:05:26 So I'll, I'll give you an example of some of the things that I started to. So let me start off by saying that what I started to examine was when I experienced conflict, especially when it came to writing the requirements for a major system replacement or system enhancement, it was that I wasn't understanding people's personal and or professional motivations for
Speaker 1 00:05:55 Right. That
Speaker 2 00:05:56 Conflict. And by that, I mean, personal motivations could be, I am a couple of years away from retirement. I don't want to have to learn something new. This is just
Speaker 1 00:06:09 Right.
Speaker 2 00:06:10 Not something that I wanna do. Professional motivations could be something like I help build this system. And the, therefore this is kind of my baby that you're, <laugh> right. You know, you're affecting here and that could lead to me not having to do this job that I've always
Speaker 1 00:06:25 Done. Yeah. Maybe I'm not relevant anymore or something like that. Yeah. Right.
Speaker 2 00:06:28 And I, you know, and, and I think that until I actually really started to examine some of those motivations and, and really, you know, in a sense kind of dive deeper into right. The, the why, and, you know, a lot of times that might have to been, you know, taking somebody aside or meeting somebody for
Speaker 1 00:06:46 Having a coffee, different a one on one conversations.
Speaker 2 00:06:49 Yeah. You know, things that may have not been able to, uh, easily come out in a requirements gathering type me
Speaker 1 00:06:57 With 20 people in the room. Yeah.
Speaker 2 00:06:59 Yeah. And so lemme give you an example. I had a, what I would call a, you know, you would call it a very difficult, uh, client one time mm-hmm, <affirmative> working on a system that she was the, she was the subject matter expert on, she was the primary user, the product owner, you name it. She was in that system. So, and I had, and I had to work with her to help develop these, um, enhancements requirements for the system. And she, she was, you know, she was known for being very difficult, but very being very blunt, blunt, she didn't miss words. So, you know, she kind of told you right up front that she did not like, okay, very bluntly told you that, you know, she didn't like something. Okay. What I started doing was then we had, I had, uh, at this point we had pretty much daily meetings that happened, oh, wow.
Speaker 2 00:07:57 Two or three hours a day. Oh my. With her and my team and sitting down with her. And so what I would do is, you know, it was at nine o'clock in the morning. So it's, you know, you're coming in that everybody's has that sort of, this is when, you know, people still coming in the office. And we went down to like this basement conference room that we had reserved for a couple months. So what I started doing was coming in 30 minutes early mm-hmm, <affirmative> going by her cube. And no matter what it was, I made a point to talk about something other than work with her, whatever it was, if this was the rain boots that she was wearing, or, you know, a partic a particular jacket that was hanging up, you know,
Speaker 1 00:08:40 Interesting. No
Speaker 2 00:08:41 Matter. And, and that was, that was really all it took for her to then slowly start to really, instead of banging on me for two, three hours a day, but to actually communicate, you know, where the gaps
Speaker 1 00:08:54 Were, something more you could do with.
Speaker 2 00:08:56 Yeah, exactly. And so then it really became the, the sessions started to become a lot more constructive. Yeah. And, and actually throughout our O I N T office, I then became the primary person that they sent to deal with her whenever there was any kind of issue, because just because, oh, even if it had nothing to do with the system, or it was like, you know how to go talk, you need to go. So lemme,
Speaker 1 00:09:22 Let me ask a question. What made you think of that?
Speaker 2 00:09:25 You know, I, I think it was, it was something that I saw somebody do. Okay.
Speaker 1 00:09:30 Um,
Speaker 2 00:09:31 And
Speaker 1 00:09:31 Thought you tried it. It was
Speaker 2 00:09:33 That I thought I would try. And it was, it was kind of the same thing. It was, uh, back when I was working at the help desk and,
Speaker 1 00:09:39 Oh, okay.
Speaker 2 00:09:40 We had deployed a new system that, you know, the majority of the agency was having a lot of issues with. It was their first paperless system. They were used to doing things by paper. It had financial implications. So they, you know, there was a lot, it was a high stress period. People would actually come down to the help desk instead of calling and tell you what their, their issues were. And this one help desk technician who was dealing with, you know, a set of users. And what he would do is he, he would, the first thing he would do is when they would come, uh, sit in his queue, was throw a compliment at them. <laugh> no matter what us, it didn't even have to be true. He, well,
Speaker 1 00:10:20 That's my
Speaker 2 00:10:20 Next, he disarmed them completely with just the, all of, and it, no matter what they had to say, it wasn't going to be as bad as if he hadn't done that.
Speaker 1 00:10:30 Well, there there's, there's something, there's some, there's some validity to the, to the technique, if that that's the right word to use that. Uh, well, first of all, it's hard to be, it's harder to be angry or cross bullying, defensive, whatever, fill in the blank of a word. That means your interaction is gonna be unpleasant. It's harder to be that with someone you like. Yeah. And so when you were Rommy, the, you were said you were a, a BA a business analyst at that time. Mm-hmm <affirmative> right. Ram me the BA collecting requirements to change the system that was hers, or you a Rammy that established a little bit more of a personal relationship. It, it kind of rewires the brain a little bit. There's lots and lots of research on this kind of thing. Plus just lore. There's just books full of lore about this and <affirmative> sales, right? Mm-hmm <affirmative>,
Speaker 1 00:11:20 Who's the guy I've got from his books, but Gini, Gini something. Yes. His last name is Cini. He wrote persuasion. He's a university researcher in psychology, and he wrote some very popular books, business books. And some of it touches on what you're talking about. And he, he talk, he told a story, what? He was shadowing, somebody who did like ADT sales, right. Got alarm systems in the house. And the guy always made it a point once he was inside the house to have to go back out to the car for something which he never needed. Mm-hmm <affirmative> and he caught this and, and outside the house, outside way from the client, he asked, what are you doing? And the guy's like, you don't get it. No, I don't get it. What do you, why do you go out to the car and come back in?
Speaker 1 00:12:03 He said, because if I excuse myself from the kitchen, walk out, leave the door open and walk back in. Who gets to do that? Family and friends who gets to walk out of a house, leave a door, open, walk back in without being let in. It's that same kind of thing you were doing of it's a different role. It's a different feel. But let me ask you this question. How did you keep it from being obvious? Or how did you keep it from being trite? It could have been seen as a, as a technique, as something you were quote doing to her and she could have resolve that.
Speaker 2 00:12:31 That's true. And so you had to, I, I mean, I knew my audience. She was a lot older than I was. So it, it came off as playful, you know, my compliments to her, they weren't seen as okay. Malicious in any way, you know, or
Speaker 1 00:12:48 As manipulative.
Speaker 2 00:12:49 Yeah. No, or OUS, you know, and, and sometimes, you know, I'd be like, I actually do like your hair, you know,
Speaker 1 00:12:55 You just,
Speaker 2 00:12:56 You know,
Speaker 1 00:12:58 Well, I also know you and I know that you're really comfortable in an interpersonal situation. You're just relaxed. Yeah. You don't give off any vibe of, even if you were under stressed. I don't know if you'd, cuz we were in some stressful situations, you don't give off a vibe of being stressed cuz that people pick up on that like, like the dog does, you know, and yeah. And they do, you have a nice smile and you're relaxed and you can, and you make eye contact and communicate. I think all those things would work in your favor or meaning anybody, if anybody lacked those things and tried to do what you did, it might come off as, as, as, as contrived.
Speaker 2 00:13:30 Absolutely. And there's a, you know, in this world of the right and you know, the past few years have been completely virtual. So I've thought about, and I've been thrown into situations kind of similar situations. So I've, I've thought about like, well, if I come across an issue like that, how would I solve it in a virtual environment? Mm-hmm <affirmative> like this and you know, there's other things you can do. There's a playful things you can do with cameras on. And, but it's not quite the same.
Speaker 1 00:13:59 Well, so let's, let's stay on this. What happened then in the conversation? So you go from the cube, it's nine it's time for the meetings. So you're back to the task that, that requirements gathering task. Right? How did your interaction with her change, especially, I wanna know what you did. How did the interaction with her change so that she started to contribute information you could use and you were able to keep that going. So you, you, that was your task and you had to plow through a lot. I'm sure.
Speaker 2 00:14:30 When, so I don't know if you've probably seen, but when you're working with somebody that doesn't want to give you information, it's very apparent
Speaker 1 00:14:39 <laugh>
Speaker 2 00:14:39 Because
Speaker 1 00:14:40 Yeah, there are non-verbals. Yeah.
Speaker 2 00:14:42 Right? Yeah. Well they'll or, or they'll just tell you this doesn't work, you know, they'll wait for you to write the requirement and then they'll say, they'll tell you that why it doesn't work. And so, you know, it, it just became a lot more of a conversational. Okay. Interesting. Will tell me why, you know. Oh, because we need to account for this. I mean, this was, this were a lot of financial
Speaker 1 00:15:01 That's useful information.
Speaker 2 00:15:03 Yeah. That me as a 20 something year old had no idea about I couldn't. Yeah. I needed her to tell me what the, the system should look like. And some of the things that I later on found that were really good ideas was to try and make the new system, everything from the nomenclature to even the ribbon, the color of the ribbon up at the top mm-hmm <affirmative> to match they had
Speaker 1 00:15:31 Before. Yeah.
Speaker 2 00:15:33 And I know that there's, you know, people now talk about how that's, you know, something that you know is a technique and you should be able, you should be aware of these user experience, things that matter. But you know, back then that we, we had no, you know, it was, you
Speaker 1 00:15:47 Were wing it wild
Speaker 2 00:15:48 West, we were wing, but we thought, you know, Hey, you know, you call these, uh, paper folders, red books, well, let's call this tab here, red book, cuz it does the same thing, you know? Yeah. And that way the familiarity would
Speaker 1 00:16:01 Exactly, exactly
Speaker 2 00:16:02 Is, is right there. Exactly. See things like that. It, it, those techniques definitely. I think I use 'em to this day.
Speaker 1 00:16:08 That's interesting. One could think that's trivial. I don't think it is one could think that like why does that matter? Well, but let's think about why that matters for a minute. You and I know how much change organizations go through constantly, even though in the end, sometimes it doesn't seem like a lot is different, but there organizations and especially in the government and look in the business, you're in healthcare. It it's changing all the time if, for no reason, other than technology.
Speaker 2 00:16:34 Right.
Speaker 1 00:16:35 But budgets and new leadership and new priorities, and somebody says, let's do some process re you know how it's yeah. All, all the time. And people have to steal themselves. Some like it's like if you stand in the beach about NEHI or thigh and there's some waves, you kinda have to try to stead yourself because it's just constant commotion and commotion organizations feel that way, especially around it, especially maybe around health it. So you just have to stead yourself against waves and waves of change. Not Romy, not that particular activity just change in general. Right. So then what happens if, how might change go so that it feels better? It feels more useful. Well, one of the ways is what you, what you were saying was that you, you build instant familiarity. That's not a trite thing or a superficial thing. It actually allows cuz all of us are this way. It allows us to keep that part of our brain sort of wired in the same way that it was. We don't have to rewire everything. We'd have to figure out everything anew. Some things just carry on conceptually. Right. If the system changed, but you called that thing, the red book, somebody knows always what that next time they're in the system. They know what that means.
Speaker 2 00:17:55 Yeah, exactly.
Speaker 1 00:17:56 One less thing. They've got to reorient themselves to
Speaker 2 00:18:00 Mm-hmm
Speaker 1 00:18:00 <affirmative> and the more you can build in transfers that crosses over the change date, you know, the new, the new launch date, <affirmative> the more they have to run with. Very important.
Speaker 2 00:18:12 Yeah. And I think that, you know, in this age of software, as a service mm-hmm <affirmative> and reusable systems and capabilities and, and, and that what gets lost in all of that is the, I guess the, the customization, the, that leads to that familiarity that we were talking about that leads to that increased adoption or the better user experience in the system. And I think that one of the things that I think that technology's moving away from, cuz I've, you know, I've seen in the last few years, especially a lot of software as a service systems where say basically you're handed a solution, right. That you can minimally customize for your needs mm-hmm <affirmative> and that may work as far as, you know, it investments for your budget and that, those sorts of things, but for the U it it's absolutely, I think, detrimental to the user experience because that custom, that, that special touch that you can put on a system, like, you know, naming something that you're familiar with or the color scheme. Sure,
Speaker 1 00:19:18 Sure. You know,
Speaker 2 00:19:19 I think that, that those are important. And the, and I think oftentimes those get cast aside in the interest of speed and reusability.
Speaker 1 00:19:26 Well, and, and, and tell me how, how are you able to do the same thing with some of the functional requirements so that she saw and it functions that would persist, they might operate differently. They might operate better. I've never known someone who owned a system who also didn't know what was wrong or bad about it. And if they, if they could they'd improve it, how did you get to this functional requirements? See if she's like, yeah. Let's we need to do this Rami, build that in, improve this, where she was enthusiastically helping you.
Speaker 2 00:20:00 So that came about, and this is actually something else that I wanted to talk about was she, was she, she could actually, because she was really familiar with the system mm-hmm <affirmative> could visualize no, the, the future state. Right. Sweet. But I have worked with a lot of, uh, customers and clients that they can't. So what I've done and I, even, if I'm not supposed to is I will show them the test environment. I'll bring up the test environment or even the dev environment and let them play around with it, you know, because
Speaker 1 00:20:34 Brilliant
Speaker 2 00:20:35 Giving 'em that sandbox and letting them actually kind of get
Speaker 1 00:20:39 In it, like,
Speaker 2 00:20:40 Yeah, you can't break anything, go for it.
Speaker 1 00:20:42 You
Speaker 2 00:20:42 Know, it's all dumbing data that there was, that's another technique that I think for, for folks that are having you're right. A hard time, really articulating the gaps and the needs. That's another,
Speaker 1 00:20:55 That's brilliant. Yeah. There's something very compelling about that for a user when they get to literally cuz you're right in the meetings, it's just all concepts. Maybe you're drawing something on a whiteboard mm-hmm <affirmative> <affirmative> there's words on a page, a PowerPoint slide. You've got requirements, gathering documents. You might be like a format you might template, but it's just concepts. Yeah. When they can interact with it, see something on a screen, it just, it brings it home in a way, you know, you know, Greg GIS, he's retired from government, he's doing some consulting. He and I did an episode when he was a young in her guy doing some, um, radio engineering. He was trying to buy some microwave of components. Right. And the co was just not help. It was, it was an acquisition issue. The co just wasn't working with them. He was in an urgent hurry. She was stalling. Stalling. What you just said, let me think of this. He had the idea to ask her and her team to like, it was around, I think might have been Dayton like, like right pat air force base and go to where he was his lab or his facility to see what he was doing. I mean, she didn't know he needed a telecommunications microwave component in her head. She's thinking that kitchen microwaves
Speaker 2 00:22:12 <laugh>
Speaker 1 00:22:13 Right. What's her point of reference,
Speaker 2 00:22:16 Right?
Speaker 1 00:22:16 The kitchen microwave. I don't suppose she was a CEO contr officer who had done a lot of telecommunications acquisitions before. How did she know?
Speaker 2 00:22:25 Right. Yeah.
Speaker 1 00:22:26 So she's not, not wanting to buy it. She's just not getting it and not, and got in the urgency and maybe, and this happens to all of us. Maybe it was sort of just task it. She hadn't thought it through. She hadn't thought looked at that on her desk and gone. I gotta call Greg and ask him what the hell this is about. Cuz I'm confused. You just don't think of it always explicitly. And if you're busy and you're pressured by other deadlines, you just might keep pushing one thing away because you don't get it.
Speaker 2 00:22:52 Yeah. Yep.
Speaker 1 00:22:54 It maybe wasn't very deliberate. Like I'm not helping him. I'm not buying no. Then when she went down and she said, oh my God, you're talking about these things. <laugh> like he had the parts in no time. Right. The acquisition went through is sailed right through. But it was exactly what you said. It was putting your eye on something, touching it. Yep. You know? Yep.
Speaker 2 00:23:13 Yep.
Speaker 1 00:23:14 All right. So let me ask you a, a wrinkle on the question. It's a great story. Thanks for spending some time on, on it, because it's fun to get a glimpse into how you got on the same page with somebody and how, how it worked. You do what you do. Did you do this for, for a, for a living? You're trying to get people on some same page about things all the time. Do you have a definition of what does it mean to be on the same page, a working definition, something you aim at, you know,
Speaker 2 00:23:40 A working, I think it's, it's something that you, I know when I have, I know when I'm on the same page,
Speaker 1 00:23:47 Uhhuh, <affirmative> Uhhuh
Speaker 2 00:23:48 <affirmative> and I, I can definitely sense when I'm not, and it's, it's hard for me to kind of quantify
Speaker 1 00:23:55 What do, what do you see in somebody when you know, they're they're with you or they're coming around to get on the same page with you,
Speaker 2 00:24:02 They ask, they ask a lot of questions,
Speaker 1 00:24:04 Uh, and interesting. So they become beginning more interested, more curious.
Speaker 2 00:24:08 Right. And then the other thing is, is that it, they are a lot more inclusive of me. I get added to all their meetings and
Speaker 1 00:24:20 Interesting,
Speaker 2 00:24:20 You know, because they, they want, they, because they understand where I'm coming from. They want me to hear the same thing that they're
Speaker 1 00:24:28 Hearing. Interesting. Okay.
Speaker 2 00:24:30 So that, that, that tells me I'm on the same thing, you know, because otherwise it's like, oh, I'll just relay this information to him.
Speaker 1 00:24:37 Yeah. I'll send him an email or I'll talk to him next week, send an right.
Speaker 2 00:24:40 Right, right, right. So that, that to me is a big indicator. Um,
Speaker 1 00:24:43 Yeah, you're right.
Speaker 2 00:24:44 I'm on the same page as someone, even if it's even being added as something, you know, as optional or yeah.
Speaker 1 00:24:51 You know, they're making you aware of it, which is the right. Some guys on the show have, have used the phrase. I understand what you understand about a situation. I think that's valuable. And conversely, you understand what I understand about a situation. So let's, we, we don't have to go yet to all the way to the point of agreement. We agree with some of each other about something, but if you got someone to the point where they understood what you understood and you could understand what they understood, it, it there's a, there's some way in which the, the, the separates circles we are in Aven diagram overlap more at that point. Mm-hmm, <affirmative>, there's some more shared knowledge and shared,
Speaker 2 00:25:35 And there's some peoples, I think their communication style or their communication preference is something that you need to be aware of.
Speaker 1 00:25:43 How so, you know?
Speaker 2 00:25:44 And they, so there's, there's some people that are, like I said, they're very inclusive. So let, lemme give you an example, an email. If I send an email to you, Lou, and copy your boss, my boss, couple people on this team and this team, mm-hmm, <affirmative>, it's gonna seem very different than if I just sent it to just, you obviously mm-hmm <affirmative> or, you know, know, um, so in, in learning the way that people receive your communication, I think is important.
Speaker 1 00:26:18 Interesting. That's a great point.
Speaker 2 00:26:20 And the power of communication is something. I think that I didn't, I definitely didn't realize that early in my career, the way, you know, it's even the simple things as addressing the way that you address people in meetings, Uhhuh <affirmative>, um, you know, definitely your, your writing style, I think, is something that you, everybody needs to be aware of. And also to be aware of who you're communicating with and how they're gonna receive that.
Speaker 1 00:26:46 That's interesting. Say a little bit more about that because you live in a world of requirements, which is a highly stylized thing. Mm-hmm <affirmative> right. The way a good requirement is written has to capture something that isn't technical it's about a user, let's say a user at function, user operation, but has to be translated into something that is technical, because someone's gonna take that requirement and build something with it. So you're bridging worlds.
Speaker 2 00:27:11 Yeah. And, uh, and, and developers are very little developers.
Speaker 1 00:27:16 <laugh>,
Speaker 2 00:27:17 You know, actually
Speaker 1 00:27:18 I love how you said that <laugh>
Speaker 2 00:27:19 There.
Speaker 1 00:27:20 Well, they need to be there's.
Speaker 2 00:27:22 Yeah. And there's actually there, you know, there are, there's two different kinds of developers out there that I found some will take your requirement and literally develop it the exact way it's written. So if it's written, you know, if you have the versus all or, You know, a comma in the wrong place, they'll do it that way. So you have to be, and especially, I think sometimes where there's maybe not, not a language barrier, but you know, people's English proficiencies
Speaker 1 00:27:54 Different
Speaker 2 00:27:54 At the same level. Sure. So you have to
Speaker 1 00:27:57 Oh, very true.
Speaker 2 00:27:58 Yeah. One of the things that in my earlier projects that we did was, and I, I don't know if that this, I actually kind of took off or if it really, so we had, you know, you've heard of test driven development, right? Mm-hmm <affirmative>,
Speaker 1 00:28:10 Mm-hmm <affirmative>
Speaker 2 00:28:11 So we would have our developers sit with our business analysts when they were writing the requirements, not in all the requirements sessions, but they actually write the requirements in the system. They would sit right next to them and ask them questions as they were writing the requirement, the acceptance criteria. Yeah. That way they can go back to the business and say, okay, I need, these are the questions that I had. So it's not, you know, now they call test driven development. I guess you'd call it requirement driven development. I don't know if that's a term there, but,
Speaker 1 00:28:44 But that was a good way to get at the developer and the, be the business analyst to be on the same page. Just stay on the same. Yep. And then, so that takes care of one link in the chain. And like you said,
Speaker 2 00:28:54 And the develop, then the tester sits with the developer as he's developing.
Speaker 1 00:28:58 Wow. Okay. Okay. He's writing
Speaker 2 00:28:59 The code and he's saying, here's how I'm gonna test that. So he knows exactly how to test it based on how it was built.
Speaker 1 00:29:06 That's cool. That's pretty efficient and effective. It just helps clear. It helps avoid miscommunication that is bound to occur. It
Speaker 2 00:29:16 Does. Yeah. And if you think about it, like it, people will say that there isn't time for that. You know, um, I don't have time to have a developer making hundred and dollars an hour sit with a BA to watch em, write requirement. But if you actually look at the, the, the development cycle that we go through, the sprint cycles, there's actually plenty of time for that. Because if you look at the amount of rework and conversation that happens back and forth between all those different folks, you could have eliminated that just while that person was doing his work.
Speaker 1 00:29:54 Well, you know, this, you know, they'll say don't have time to do it. Right. But I have time to do it twice.
Speaker 2 00:29:59 <laugh> right. I don't have time to write, but I have time that's, that's a good one.
Speaker 1 00:30:04 And it does become more costly. Not just because of extra time, it becomes more costly in other ways to start redoing things, to make redoing things, your, your, your, your Mo okay.
Speaker 2 00:30:16 Yeah. I mean, people talk about like, throw it over the fence. You've heard that term.
Speaker 1 00:30:19 Yeah, yeah, yeah, yeah.
Speaker 2 00:30:20 You don't don't wanna just throw it over the fence. Right. If you look at the, that's exactly what we're doing, we're throwing those requirements over the fence to the developers. Yeah. They're throwing their code over to the testers and saying, you know, yeah. So if you really do wanna eliminate those silos, I think that's probably, I think one of the only ways you to do it,
Speaker 1 00:30:40 I, let me ask you this. Cuz if something occurred to me, I bet. I think I know the answer, but I want to ask you to tell me what your experience is. I also would expect useful things to emerge from those conversations. Let's say the developer and the BA are talking, you were a BA you did your best to collect the requirements, document them in. You thought if implemented would meet the need, you could be sitting with a developer who has a, somewhat of a different background and an angle on, on it. Right. He or she could see something, say something, ask you something and you go, I, I don't know. I hadn't thought about that, but I can go get an answer.
Speaker 2 00:31:20 Mm-hmm
Speaker 1 00:31:20 <affirmative> right. It's not like all this stuff than one clean linear line. And out of the conversation could emerge something useful. And it probably wouldn't have emerged the same way or at all, if it had been thrown over the fence and you do this handoff and, and, and sometimes cuz then the developer's gonna go, BA's not around. I don't have, I'm not, I'm just gonna do it this way.
Speaker 2 00:31:44 And, and to that point there, the easy thing would say, well then why don't I just bring my developers into my requirements gathering?
Speaker 1 00:31:52 Ooh, I dunno about that. <laugh>
Speaker 2 00:31:56 That's a huge problem there
Speaker 1 00:31:58 <laugh>
Speaker 2 00:32:00 So
Speaker 1 00:32:01 Cause they really, they do.
Speaker 2 00:32:03 Yeah. You do need a little bit of that separation
Speaker 1 00:32:06 Space. Yeah. Right. That,
Speaker 2 00:32:09 That conversation, that back and forth can happen. And then really at that point then it's, it's the developer and the BA both going back to the business and asking the question.
Speaker 1 00:32:19 That's interesting. Yeah. The BA the, the, the, the, the role and the fun function of the BA is an art, because there's a, and this is a really interesting thing to me, just personally interests me about how we communicate, meaning and intent.
Speaker 2 00:32:36 Mm-hmm,
Speaker 1 00:32:37 <affirmative>, it's a phrase. I, I use a lot, I'm writing a guidebook on how to get on the same page and you know, my, my website's gonna launch in a couple months and I'm okay. So I, I, and I'm, there's some steps I'm gonna propose in a little method, four steps for getting on the same page. Meaning and intent is something that's very central to transmitting between people, two people or a team <affirmative> mm-hmm <affirmative>, and it's not exactly a black box. It's not like, well, we really can't see it and don't know what's happening. What was meaning in intent mean, how is it communicated? Or how is it shared if I see a situation some way, and you see it differently, or we size things up differently, we would do something differently about it. Doesn't mean we can't, that's probably good. And in the right conversation, we can, we can merge some of that, or we can integrate some of that. Or we can, a third thing could come out of it by how we talk. Right. So it's not like it's a black box and we can't see into it. Don't know what's going on, but it is an art is, was my point about the BA it's an art to be able to, you're kind of almost always have to hear sometimes what wasn't said, but maybe meant
Speaker 2 00:33:43 Mm-hmm <affirmative>
Speaker 1 00:33:43 Yeah. Implied you pick up a queue and you ask about it. So they go, they elaborate and then you're, then you're getting more of the information you thought might have been there. If it wasn't there there's no harm done. But if it was there, it helps you write the requirement better.
Speaker 2 00:33:58 Yeah. I think one of the, of things I've learned that a VA has to do is, like you said, you have that balance between trying to elucidate their requirements, identify what the need is, and then how that, how the system is gonna perform to meet that need mm-hmm <affirmative>. But then, like you said, intent matters. So what happens is that a lot of times, when you have a group that is open and willing to give you all the requirements that you need is that you end up having three or four voices in the room that try and kind of take over <laugh> and then start the, of trying to ask some of those same questions that the BA is asking mm-hmm <affirmative>. And there's a balance there where you have to try and try and funnel a lot of that through one voice so that you don't have, you know, five different opinions, um, really kind of morphing. So interesting. Yeah. There's a balance there where you, you kind of want everyone to, to chime in to give their opinion on how things should be worded even down to, you know, just something as simple as that. Um,
Speaker 1 00:35:09 Yeah, yeah. Right.
Speaker 2 00:35:10 But be aware that you may end up getting four or five different opinions on every single thing. There's a, there's a nice way. That's kind of arrive at consensus without basically having just the democracy on every single
Speaker 1 00:35:23 Well, that's an important point. And I was gonna ask you, I was gonna shift a little bit and ask you about, we've talked a lot about what works getting on the same page. I was gonna ask you what what's, what doesn't work. And maybe what happens when you can't, but let me stay on this for a second. I have this, I'm working on this notion as part of the guidebook and the coaching I'm gonna develop for later in the year that each of us see something in a situation, but not other things, not everything. We see something in a situation. We don't see other things. We size up what we see. We make something of it in a certain way and not some other way. We know what we would do about it and not something else as a means to an end and not some other end there's four things.
Speaker 1 00:36:03 What we see, what sense we make of it, what we would do and why that thing, different people with different roles on a project or even different use of a system would answer those questions in different way and different people with different backgrounds, different experience, different technical experience, different knowledge. We see we're trained to see different things and size them up in certain ways. And so I could imagine the situation you described where four or five people are sort of telling it, like they see it with just some subtle differences, maybe not subtle, but let's just say that there's some nuances. You probably have to reconcile some of that because you can't have one requirement, can't do two or three different things. <laugh> it can't, it can't be implemented in different ways. So you mentioned there are some ways to get consensus on that. How did you pull a few of those threads together to get them to go? Yeah. Okay. That way.
Speaker 2 00:37:00 So there's one time, one situation that comes to mind, and again, this was, these are, this was, you know, recurring requirement sessions with the same group of SME, you know, happening for sometimes two, three months. Mm-hmm <affirmative>, this was a couple months into this engagement and people were just kind of probably tired of hearing my voice <laugh> and <laugh>, you know, and, and sometimes, you know, people, you know, like I said, people's, you know, personal motivations, maybe somebody's in a bad mood that day and just wants to be disagreeable. Yeah. So I realized that I wasn't gonna be able to, to get past this. I couldn't referee this
Speaker 1 00:37:44 Disagreement. Oh, interesting.
Speaker 2 00:37:45 Because they were just, you know, both sides had kind of dug in their heels and said, you know, this is how it should be. And it was kind of nearing towards the end of the session. So I wrote both of those requirements, two separate ones, even though I knew that they in conflict. But then what I did was I, it was, I think that was on a Thursday or Friday. Then I gave it till after the weekend. And then we had the larger group of SMEEs there. And what I did was rather than present this as a conflicting requirements, mm-hmm <affirmative>
Speaker 2 00:38:19 I just present these requirements, went through them with the group, kind of talked about which, how they mapped to different areas of the system mm-hmm <affirmative> and it came out right from the group. Right. That this was a complex, so I let them, I let them do it. Yeah. But just by showing it to them. Yeah. But if I was gonna try and sit there for the last hour of that meeting at wordsmith, this requirement and the acceptance criteria for it, it would, I mean, I, I, I could have, but it still would not have achieve somebody would've felt like they're not getting their away
Speaker 1 00:38:55 Uhhuh. Right. Right. Rather
Speaker 2 00:38:56 Than through that, I said, you know what, let's just write it up this way and this way, and I'll go ahead and I'll put these into the backlog. And then when we brilliant map these to the system capabilities, we'll, you know, I didn't even have to say that I just did that. And that's what I haven't, it was very organic that way.
Speaker 1 00:39:14 And that's Roy, I have an advanced degree in conflict resolution. You act like you do too. <laugh>
Speaker 2 00:39:20 <laugh>
Speaker 1 00:39:21 I have a master's you act like you have a PhD in it.
Speaker 2 00:39:25 No. If there's one for like kids, then that's what
Speaker 1 00:39:28 I need. No, you've learned some, no, you've learned some things along the way that are, that are very what's I'm, I'm trying to think of a different way than saying insightful about human nature, but I think you've figured out some things about how people work in these situations and you've been real effective at, at interacting with that's a brilliant way to do it because you got yourself out of that intermediary role that you really wasn't productive at that previous Thursday or Friday, for whatever reasons they had their heels dug in, you might not have been able to get them <affirmative> that day, the next week there were more people involved right. In the next meeting.
Speaker 2 00:40:01 Yeah. Yep. This was the larger group.
Speaker 1 00:40:03 Yeah. That changes some perspective. But also when you presented both requirements, the context for them had changed the context for the competing requirements. The previous Thursday or Friday was whatever it was, it was the, it was the, it was the requirements gathering you were doing that day. And in the minds of those parties, they had those, they had two requirements fixed for a reason. Everything is a means to an end. They had the requirement in their minds separately fixed as a means to some end. And they weren't reconcilable at that time, the following week in other meeting with more people and presented both the context to change, like you said, you were probably giving them, you were walking through everything.
Speaker 2 00:40:42 Yeah.
Speaker 1 00:40:42 Right. And showing them how different things mapped different parts of the system. The context of the individuals was such that they could see what the disparity or the, the reconcilable of it. So what came out of it? Was it one of the other, would something come together in an integrated way that, that emerged?
Speaker 2 00:41:02 Um, I'm trying to remember. So I'm trying to actually remember the specific requirements.
Speaker 1 00:41:06 That's all right.
Speaker 2 00:41:06 It had to do with like adding something versus modifying mm-hmm <affirmative> we need the ability to just, if it's something's different, we just add it and there's saying, you know, well, no, we also need to be able to edit it in case I made a mistake and it was yeah,
Speaker 1 00:41:23 Yeah, yeah, yeah.
Speaker 2 00:41:24 All sort of, you know, back and really what they, they were saying was the same thing. You know, they needed the ability to create and edit. And I think it just getting them to see that, you know, when they, when they kind of saw everyth, cuz I was just basically going through like a, a traceability matrix going through all the different tabs. And when we got to the tab that had those requirements and you read them both, you just can see yeah. That it does, you know, it didn't make sense. Yeah.
Speaker 1 00:41:50 <laugh> um, well done. So yeah. Well done.
Speaker 2 00:41:53 And then the other thing, I think, you know, the, the business analyst that I found, the roles that I've worked in, when I say that you're thrown out there to the wolves. I mean that, so if you think about the context of a, of a project, right. A project starts with an acquisi,
Speaker 1 00:42:13 Right. Mm-hmm <affirmative>, mm-hmm,
Speaker 2 00:42:14 <affirmative>, who's involved in that acquisition process, not the users. Right? Absolutely not. Right. I mean, typically not. Right. And then after that you have an award and then there's planning and even then until you actually get to the first requirements
Speaker 1 00:42:32 Gathering you're right. Yeah.
Speaker 2 00:42:35 Who's the first person that they see.
Speaker 1 00:42:37 Yeah.
Speaker 2 00:42:37 It's the BA and you know, I don't think anybody realize is that the face that's the face of the project, that's the, that's gonna be their first impression yeah. On everything going forward with this project really, for old, through implementation and probably sustain if it gets to that point mm-hmm <affirmative>. And I thought if people really paid attention to them and invested in making that a, a working relationship and establishing a working relationship from the get go mm-hmm <affirmative>, you know, later on I had tried to do that, you know, have some ice breakers and mm-hmm <affirmative>, you know, just not throw up a, an Excel spreadsheet and
Speaker 1 00:43:17 Talk about requirements. Yeah. Yeah.
Speaker 2 00:43:20 You know, things like that. You know, I remember one time I was preparing for this one requirements kickoff, like all weekend. And I had been preparing up in my office and I had put these like giant post-its over the walls of their entire, you know, this, this business is, you know, process mm-hmm, <affirmative> all the different, you know, sort of capabilities just to kind of get it in my head. So I was talking to them, I wasn't reading off a sheet of paper and I go into this meeting and it's got, they have all their policy folks there they're SME leadership, everybody there. Right. It's a big kickoff. Mm-hmm <affirmative>. And just to break the ice, I actually, I had taken a picture of those post-its on the wall mm-hmm <affirmative> in my office. Mm-hmm <affirmative> and I put that up mm-hmm <affirmative> I put that up on the first slide mm-hmm <affirmative> and I was like, this is what I did this weekend. <laugh> getting ready. You know, just let you know that, you know, they were cracking up, you know? Yeah. They were, this is great. But just to let her know that I've, I've done some homework I'm on this journey with you. So let's do this together kind of thing, you know?
Speaker 1 00:44:25 Well that, that's another, I, I keep saying brilliant, cuz you're brilliant. That's a, so one, it was, it showed them that you cared.
Speaker 2 00:44:35 Yeah.
Speaker 1 00:44:36 You were vested in it, which they didn't know what do they know? Right. Right.
Speaker 1 00:44:42 Two it depicted without going in any details. It depicted some complexity. Yeah. People forget how complexities they, things are. Cuz you work with a piece of it or you work with an aspect of it. And there's a great book. I've read called the knowledge illusion. Why we never think alone in the early pages, the author makes the point. There's not one person. This is true. He something he says, but it's true of anything. There's not one person who, one person who knows everything about how an airplane works. Mm-hmm <affirmative> scary thought, but there's not one person.
Speaker 2 00:45:18 Yeah.
Speaker 1 00:45:18 Not even the pilot knows everything about how the plane works. Someone or he knows some things, but somebody knows a lot more mm-hmm <affirmative> some mechanic or some software guy or some, some, some engineer. Right. And, and he's illustrating that as part of a chapter, that's setting up the book where he talks, he, he doesn't exercise. He tells people to draw a bicycle, just like pencil, stick, figure, kind of drawing, draw a bicycle. He repo, he pre reprints some of the images and they're hysterical Ram. You could look at them and see that it mechanically, it wouldn't work. Mm-hmm <affirmative> they got, there's no chain on it. They got, they got, they got, you know, the they've got things connected and that wouldn't move, but it, and it's a bicycle. We've been riding him since we were five. Right. So his point is about how distributed knowledge is and how knowledge needs to be processes, need to tap distributed, know to put it, to bring it together, which is behind what you've been saying. A lot of the thing is by your image, you're reminding them, there's a lot to this. Yeah. And then it shifts the context for them because everybody walks in knowing their piece of it. And if they want to, I could, I could like pound my desk here. If they want to, they could dig their heels in about their piece of it.
Speaker 2 00:46:35 Yeah, absolutely. But
Speaker 1 00:46:36 Then when they look at, they look at that whole thing and they go, ah, you know what, there's, there's, there's a lot more to this. And all these people sitting here with me have some piece of it too. And it shifts the mindset a little bit, which is, which is a better starting place for what you're about to do.
Speaker 2 00:46:49 Yeah. And I, and actually back to that same kickoff meeting <affirmative> they had the deputy director for the program office, an SES in the room.
Speaker 1 00:47:00 Hmm
Speaker 2 00:47:00 <laugh> and one of the things that came out of our kind of kickoff, uh, requirements kickoff was that we, we are here to trans help transform your business. And, and a part of that transformation could have policy implications mm-hmm <affirmative> or there is policy that we need to be aware of sure. Or policy that needs to change. Sure. In order to meet some of these, these needs that you have after that meeting, he dedicated to policy people to every single one of our requirement sessions. Wow. To then report back to him at the end of each day, on which policies recommendations we should change based out of the requirement sessions. So when you get that kind of buy-in from business where they actually believe that you have their best interest at heart, they're willing to dedicate whatever it takes, time
Speaker 1 00:47:54 And effort resources. Yeah. That's great. Time, effort and resources. That's great. That's
Speaker 2 00:47:57 Probably the only time I've actually had that happen, where somebody's said, you know, what, what needs to change? Tell me what needs to change. And then we will take a look and see if that actually makes sense to change from policy per and if it does, we'll do that.
Speaker 1 00:48:11 That's pretty cool. Well Rammy thank you for doing this with me. I've had fun and we've well, we've covered a lot of things and good stuff and had some laughs. Thanks for taking the time to do this.
Speaker 2 00:48:21 Yeah. This, this was great. This, uh, conversations with you always are very easy list. I'm I'm glad that this went well. <laugh>
Speaker 1 00:48:30 Real good. Thanks buddy. Really appreciate it. Have a good one. Okay, great. Thanks homie. Appreciate it right buddy. Bye-bye and that's how we see it. My friends, I wanna thank Rammy for recording today's episode. You can find it at, I see what you mean.casto.com. Plus all the usual places, send questions and suggestions through an app. Subscribe and give me a five star rating. Unless in which case, tell me why and join me next week. When we take it on the look and how to get on the same page and stay there unless we shouldn't.
