Webinar Recap: SIPOC Workshop Facilitation – Part 2: SIPOC Workshop Strategies

Please find below a transcription of the audio portion of Jeff Bongiovani’s session, SIPOC Workshop Facilitation – Part 2, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the live recording of this webinar at your convenience.

Kyle: Hello everyone and welcome to part two of MPUGs Training Series SIPOC Workshop Facilitation. This second session will cover SIPOC workshop strategies. My name is Kyle and I’m the moderator today. Today’s session is eligible for 1 PMI PDU in the strategic category, and the activity code to claim that with PMI is on the screen now.

Kyle: And like all MPUG sessions, the recording will be posted at mpug.com shortly after the live presentation wraps up. And all MPUG members can watch the recordings at any time and still be eligible to earn the PDU credit. All the sessions are watch on demand, can be submitted to your webinar history and the live sessions you attend are automatically submitted. Within your history, you could print or download your transcript and certificates of completion including the one for today. You can access that by logging into mpug.com. Click my account and click on the webinar reports link.

Kyle: You have any questions during today’s session, please send those over at any time using the chat question box on the GoToWebinar control panel and we do plan to answer those for you at the end of this session today. All right, let’s go ahead and get started with session two. So we’re very happy to welcome back Jeff Bongiovani today. And at this time, I’ll hand it over to you Jeff to get us started with today’s presentation.

Jeff Bongiovani: Okay, fantastic. Thank you. The pull-up my show screen. Let’s see here. That one. Fantastic. Well, good afternoon, everyone. And welcome back to a session two for SIPOC for Workshop Facilitation. Session number two, the SIPOC Workshop Strategies. Two main things that we want to be able to accomplish today. Number one, we want to define and describe essential documentation and the team ramp-up to SIPOC workshops.

Jeff Bongiovani: The notion is that we can’t just have a workshop, you have to make sure that the team for the most part is acclimated to concepts, thinking in terms of process, thinking of terms of customer needs, and being able to see how their process fits in within other processes. So we’ll discuss a lot of the documentation and some of you, maybe all of you will recognize exactly what those documents are.

Jeff Bongiovani: And then ultimately describe how to set SIPOC workshop goals and strategies. Along the way, while we’re ramping up and looking at documentation, what we’re doing is building the steps towards the team acclamation, towards SIPOC. And so for the most part as the goals and strategies unfold, it’s one of these things where it will be something you can easily express to the team, they’ll understand exactly where you’re coming from but we have some work before we get there.

Jeff Bongiovani: All right, last time on SIPOC, last time on SIPOC Workshop Facilitation, we had laid out the definition of what SIPOC was. And for the most part, it is a model for process awareness as well as for ultimately process improvement or design. For the most part defined in five different parts, suppliers, inputs, processes, outputs and customers. The concept here of course, is say for example, there’s a change in IT security. Due to certain cybersecurity standards we’re trying to achieve, let’s say that password length and complexity is something that we have to now make sure that all of the employees are aware of, that we have specific standards.

Jeff Bongiovani: And the idea there is that the envisionment here, where we have the customer, what are the customer needs? Ultimately who are the customers? The entire organization. Ultimately, we want the entire organization to understand this brand new policy. Now the question is, how are they supposed to know? Do we just send out a blast email? Is that enough to be able to verify and be able to validate, especially if we’re audited outside by any sort of, let’s say authorizing body so to speak?

Jeff Bongiovani: So we may decide to go the route of let’s say, an eLearning module that acclimates them to and shows them the way, here’s password complexity, here’s some examples, here’s why you should have a complex password. This way they’re attuned more to the reason and the purpose behind the policy and we could actually quiz them and test them, “Here go ahead and make up your own password,” that sort of thing. That should be enough to meet the mark.

Jeff Bongiovani: In order to achieve that output, what sort of process would we need in order to develop that and ultimately within that process, let’s say we go to our training team or within let’s say human resources and administration, they say, “Well, we’re going to have to meet with the IT department, we’re going to have to look at what sort of changes the policy exists.” So we’re going to need those materials, we’re going to need this information, this input, and we need that supplied by the IT department.

Jeff Bongiovani: That’s the idea folks. And you can see within that, part of what we had explored was not just the fact that you’re looking at an overall process, this is scalable, we could dig down to the instructional designer pulling out lines from that individual policy change and being able to create exercises for the matter of that output.

Jeff Bongiovani: So to that end though, the one vital thing heading into this particular session is that when we began to dissect processes, there’s a certain awareness that the concept of SIPOC has given us, which is really about the customer needs, goals, requirements. And the notion that we can concentrate then on an output that perhaps could fulfill that, a process that ultimately provides that output step by step resources, ultimately, the process owners and people within that process that are accountable for enabling or providing those outputs, and ultimately, the fuel for the fire, the inputs and where we’re receiving that from.

Jeff Bongiovani: However, you got to figure a process doesn’t just stand alone, there’s a lot of support necessary. And part of what we’re lecturing to last time was the fact that well, it all depends, some things can be highly unpredictable. There may be a call for more of an agile approach than a waterfall approach, if you catch what I mean, quote, unquote. The idea though with systems and project management theory were drawn… Our attention is drawn to the fact that hey you know what, if there are risks, if there are issues that need escalation, there has to be a certain level of governance. If there’s a fight between the project team and the functional manager, that sort of thing, we have to be there, we have to iron things out.

Jeff Bongiovani: Ultimately, within the customer needs, goals, requirements, I mean, hopefully, you’re writing all this down, we’ve got to have some sort of requirements traceability, and ultimately at the end of the day, we got to test and verify and validate whether or not those requirements are being met. And so there’s a certain awareness that perhaps in our own studies, our own expertise within systems engineering, or project managing, or any other study has given us is the necessity of the things that are posted up there on the right-hand side.

Jeff Bongiovani: So before we talk about this, because as you know, really, the first session was strictly theory, what is SIPOC? What are the things that help to support it? How are the different expectations of how we could use it, utilize it in the insight, and of course, reviewing all that here? But there’s another aspect of that as we drive even further than to the third session is it’s all about emotion and action.

Jeff Bongiovani: There’s one primary element that I think is worth discussing before we enter into the quote unquote reality of the matter. And that has to do with team autonomy. Now, number one more than likely, and there’s only one, more than likely you do have to gauge whether or not the team in question or teams are suited for proactive change, or used to only reactive change from the outside. Meaning to say that the mindset of certain teams is that the routines they go on, they happen day by day. And that there’s no need to change anything, nothing’s broken, unless a problem comes along. Then when a problem comes along, maybe it’s not mine, maybe it’s somebody else’s, they need to clean this up, or maybe I need to clean this up, I’ll take action for it because nobody else is doing it.

Jeff Bongiovani: But nevertheless, there’s something to be said, a truly autonomous team. It does speak volumes, that a fully autonomous team, if they are able and capable of developing their own standards without prompting, they already probably see the value in standardization and process improvement. And the fact of the matter is that it may be an issue then, as you can see, it may be a matter of whether or not they appreciate allowing, “business authority” right? Directors and managers and supervisors to come in and then bark down at them saying, “This is the standard. This is the way.” Because it really undermines their subject matter expertise authority.

Jeff Bongiovani: And just pausing on that for a moment, this all comes down to whatever management or leadership style, I realized there are two different things managers and leaders, but nevertheless, it’s what they’re used to. I’ve been under, we could say, different types of matter, I’ve been under the supreme pace setting manager that says, “You’re going to get this done to the end of the week,” and oh my goodness, like it should take two weeks now, you get it done immediately. That sort of thing. And they’re just leading the charge, we’ve got to get that out of the door.

Jeff Bongiovani: And then you’ve had leaders that perhaps are kind of like, “Do your own thing, that’s fine as long as you get the job done, I trust you to do it.” And when there’s a shift or a change in leadership mentality, and therefore, management techniques applied, that there can be some resistance. When I was making up this slide, once upon a time, I was actually thinking about one of the classes that I gave a while back and think it was around in 2003, 2004, and it was for Help Desk administration.

Jeff Bongiovani: So folks could go for what’s called HDA, HDA certification, Help Desk Administration certification, but essentially, it’s kind of like this, the class was geared towards saying, “Okay, you’re a small to mid-sized company, you just started with this, you offer IT services. Now, you’ve sent a bunch of IT professionals to this class because you need to learn how to stand up a Help Desk, customer service.”

Jeff Bongiovani: And so this guides them through, you need to have tickets, you need to standardize, you have to have the communication plan, you have to write down and log everything, stuff along those lines. So I’m like, “Okay, let’s go around the room, let’s everybody introduce themselves. Tell me how long you’ve been in IT services. If, in fact, you’ve been part of a help desk, how long you’ve been part of a help desk. And if you have any certifications, go ahead.” It’s always cool hearing all the acronyms.

Jeff Bongiovani: So the first guy starts out, he said, “My name is…” And I’m sorry, it’s been I don’t know, 20 some years since then or close it. But the guy said, “I’ve been with IT services in this organization for the last 25 years.” And I just looked at it, like one of those things like you’re expecting for the last six months or the last two years, and I looked at it, I was like, “What? 25 years?” Well, maybe they sent you in to keep an eye on all these other young bucks out there, that sort of thing.

Jeff Bongiovani: So they kept on going around the room, everyone’s like 10 years, 15 years, “I just transferred over where I was head manager of this particular IT department. But I took this job because I was a little stressed out with it. I’ve been here for the last two years.” And it’s like, “Okay, guys, you got to tell me, you’re playing a joke on me.” They said, “No, no, actually, the joke’s on us. Because we just had a new manager get transferred in and he gave us a pop quiz on Help Desk terminology, because we took it as a joke we all got like 70 and 80%, somewhere in there.” And he said that that was subpar. So he wanted to take us to some essential training. I was like, “That’s insult and injury.”

Jeff Bongiovani: So, that’s an extreme. That’s an extreme. Way to really wreck your reputation with the team. And I say, “You guys can leave, send in your manager.” I didn’t really say this. But you’re thinking… I’m thinking to myself, this manager could have stood to take a training course on best practices for managers, supervisors, for their first 100 days. I remember a book I used to teach out of that the first paragraph wasn’t a paragraph, it was just one line, it just said, change nothing, for 100 days change nothing. You’re just going to do active listening.

Jeff Bongiovani: And I think that is the matter here, the solution to this situation is that if you didn’t have and you come under an autonomous team, and not everybody’s hungry for change, but if you did have and find a team that was largely led by a democratic leader, if you will, like do your own thing, report back to me, I hope you get your job done. Did you establish this particular process? Cool. I don’t care what it is, as long as it gets done.

Jeff Bongiovani: That the matter they may be the experts, they’re going to be the ones who write the book or the job aid or what have you. So you might be the authorizer of their standard, if you know what I mean. So workshop preparedness, you can’t just throw workshops, you have to prepare the team for them, ultimately obtaining a shared vision, being able to acquire sign-on otherwise this can’t move forward. So what I’m advocating here is that the steps they are worth taking really are about molding a mindset for awareness, and also improvement.

Jeff Bongiovani: Being able to make stand-up meetings with successfully executed agendas, underline successfully executed agendas, a regular thing. I mean, we got to make sure we execute that plan exactly as it says on its baseline, right? And then ultimately encourage the development and use of new tools. And I think that’s really where our awareness is going to be directed first, is that before we can actually sit down and say, “By the way, SIPOC, you know what it means? All right, now we’re going to have a workshop, and we’re going to go around the room and then we’re going to talk about processes. And we’re going to talk about inputs and outputs.” Everybody’s going to be looking around like, “Man, what did he put in his coffee?” That sort of thing. What is she babbling on about?

Jeff Bongiovani: So we really have to build up the idea. It’s a training up to that point. So I thought to frame… You’re probably asking about the iceberg. Okay, I got to talk about the iceberg. The other thing, it’s not just about the top portion, the iceberg’s a whole lot more. Workshop, the SIPOC workshop I don’t know, maybe I should just take this out for next time. I’m just kidding, no. Think about this, the SIPOC workshop ultimately is only stood up by that support underneath.

Jeff Bongiovani: That iceberg is not moving, is not moving far. I mean, big boats can crash into it and sink, it is not moving. The idea there though, is that that top portion is held up, it’s floating. Why? Because that huge contribution down at the bottom. A lot of that goes unseen. And we’re not always aware of the true extent to which the model in the concept in process improvement is supported. So really, what are we doing, we’re building that bottom portion. So the little tiny part can stand up at the top.

Jeff Bongiovani: So the scenario I’m using, and there are a lot of things, when I’m writing all of the advice, when I’m building courses. Usually I have like all the different jobs that I’ve held and all of the different scenarios, questions and pictures and scenarios that my students and all of the classes have painted for me in their job circumstances. The one in particular I’m thinking about is the state job with the state of Maryland that I held for a year or two. And we were doing and processing forms for actually county and state provided assistance.

Jeff Bongiovani: And I just remember like thinking, “Wow, we are all out of sorts, there’s no standardization, we have a strong manager who wants to have everything get done, that sort of thing.” Slightly disorganized, but we got our job done, and it was the grind. So as I’m walking through these, just envision, we’re propping up all of these documents, we’re getting the team set up, like what kind of team am I talking about, though? What am I envisioning in my head?

Jeff Bongiovani: But for the most part, maybe it’s a new manager, director, supervisor, call them what you may, or perhaps a manager, director, supervisor that had an awakening. They said, “You know what, we got to get our stuff together.” And that’s sort of thing. At the same time, it may be a slightly disorganized team, they get their work done. So there’s no gripes or complaints, but maybe there’s a little bit of grief, maybe they get the sense that, “Man, things could be better. I don’t know.” But they’re really on the job doing their thing.

Jeff Bongiovani: Often, team meetings happen but not with any regularity and it’s a pretty typical grind. It’s a day-to-day. Okay, now when we’re talking about the documentation, what I wanted to do is walk through each one of the different document types in the… You’re probably are already reading the slide, and you’re like, “Hey, I know these.” But for the most part, I wanted to make sure that not only am I discussing like what to do with each one of these, as a stage building up to facilitating SIPOC workshops, but necessarily how they’re contributing, and what sort of information they’re providing, what sort of foundation they’re providing to acclimate the team towards thinking with SIPOC.

Jeff Bongiovani: And so I have three groups here and the reason why I group them out this way, you won’t find that in any textbook. And most of you might say, “That belongs in a different place.” But just hear me out, when I say process focused or on the job, what I’m really talking about is if I have an issue, if I’m learning a lesson, where am I learning them as a person, as an employee, while I’m sitting on my desk, I’m learning that while I’m interacting with a customer, I’m like on the scene right then in there.

Jeff Bongiovani: So when I say process focused and on the job, it’s really with those lessons learned, you got to get people to write them down, perhaps immediately write them and just put it on a sticky note, write it on the back of your arm, the customer would be like, what are you doing? It’s like I’m writing down this issue so I can remember it for later, that sort of thing.

Jeff Bongiovani: And ultimately, with the risk register, it may be you’re sitting at lunch, and you’re like, “Oh my gosh, if the fax machine goes down, we’re all sunk,” that sort of thing, write it in on the back of the receipt or the back of the package or whatever you got there and take it back to your desk. But the idea is that these are things that ultimately are discoverable while the situation is playing out.

Jeff Bongiovani: On the other hand, when we’re talking about process standardizing, I don’t know if you dream of a template and then go to work and make a template. That’s cool. I do that. But I thought that was just me. But when we’re talking about process standardizing, I mean, we’re thinking in terms of like templates, when you have a systematic report, a template is something that already has formatting, already has the page setup, already has different sections. We talk about job aids, it’s a process or procedure that’s already written out or described that sort of thing.

Jeff Bongiovani: And ultimately, the reason why you bucketed if you will, assets library underneath process standardizing is that you’re really now kind of leading saying, “Okay, if we have these things like an issue log, lessons learn log, a risk register, templates, job aids and stuff like that, here’s a standard place where you put them,” they’re all living documents. As you can see, across the bottom here, we’re talking about while you’re encouraging active contribution, continuous improvement, and ultimately, it should be framed as our team, our process.

Jeff Bongiovani: And a lot of times where I’ve had, you can tell when you’re talking to coworkers and they say, “Well the process that you guys came up with,” “I was like, oh dear.” In the [inaudible 00:23:05] he or she may be right, I don’t know, that’s pulling an example out of thin air, right? But at the end of the day they really should say, “Hey, our process could stand to improve.” Rather than say, “The process that you guys did,” that sort of thing. It’s our process, we’re in it together, I’m going to help you with yours, you’re going to help me with mine, that sort of thing.

Jeff Bongiovani: So when we come down to standardization, the assets library really kind of is the hallmark of centralization. And then ultimately, lump these together because in our expectation management, think about it, requirements, traceability matrix and RACI matrix, and ultimately stakeholder identification and management, this is what the people have grown to expect, this is what I expect of you. And ultimately, this is their expectations and how we hope to manage them.

Jeff Bongiovani: So let’s talk and one other aside before we continue, I’m going to use these terms, business goals, functional goals, technical goals. You may have in another school of thought have a different definition of them, just want to make sure that you know where I’m coming from. So when I say something like a business goal, what am I really talking about, quote unquote, I made the most money from spending the least amount of money and I didn’t lose reputation or undermine my company morale. That’s a business goal, right? That might be the ultimate business goal. I was able to justify my budget for this fiscal year and then fulfill the quote unquote, platform promises of the current administrative body.

Jeff Bongiovani: So the difference between perhaps like a for-profit business or a nonprofit or government agency. When I say a functional goal, quote, unquote, the product or service did either exactly or more than what the customer desired or envisioned? A lot of times, that’s not always written down on a piece of paper. But you know what? They wanted the blue lollipop, not the red one. But they didn’t tell you what color they preferred until last minute.

Jeff Bongiovani: But a functional goal, ultimately is the fulfillment of the product or service. And when I say technical goal, I’m talking about using specific programming language because it’s the most extensible, and as well as adaptable. A lot of times, you want to look for the technical goals as something that ultimately could help you in future projects or related or adjacent projects.

Jeff Bongiovani: All right, so number one, lessons learned log, issue log, we probably know about this terminology. You’re like, Jeff, we’re project managers, what are you doing. So you get the idea, you start out with this, and it could be innocent, the slightly disorganized team, you say, you know what you should do, start recording concerns or incidents or issues when they happen, write it down. If you haven’t jumped ahead to having the repository, at least have them write it down on a sketch pad, or keep a note on their computer or something like that. But one of the things that you want to be able to do is, if you’re writing it down for them, they come to you and they talk to you about the concern or incident, that’s fine too.

Jeff Bongiovani: Just note the contributor because that’s going to come into play, ultimately, when we get the whole team together and talk about things because well not to embarrass them, but say so and so had an excellent point, they pointed out this particular concern that they had with this. Now, as a trainer, as a manager, honestly it’s great when you can say, well so-and-so had an excellent discovery. So-and-so contributed this, that’s always an important thing, not calling them out, but per se, explaining their overall contribution. That is if they’re not going to get embarrassed.

Jeff Bongiovani: You also want to make sure that your recording how often it happens or investigate whether or not it has been addressed. It’s still going on that sort of thing. So you want to make sure what are all of the loose threads or the outstanding issues. And ultimately, if it’s feasible, if it’s something within their range you could assign that particular contributor the task of developing potential solutions of how to address that particular issue, or ultimately work through it with them.

Jeff Bongiovani: The language is very important here, being able to frame a better way of expressing concerns, incidence or issues. And it comes back to the last slide here is the use of it. And we’ll see this again, when we’re talking about risk registers, right? This happened leading to this issue or incident, you always want to make sure you get that cause and effect. This happened as a result, you have the cause effect. What you eventually want to mold that into is that this happened leading to this issue or incident, which ultimately compromised this business functional or technical goal.

Jeff Bongiovani: And it’s not one of the three well then who cares. I mean, why else are we talking, it’s not losing us any money. It’s not detracting from what the customer wants or ultimately it’s not undermining the the qualities of the particular product that put us at a disadvantage, we do have to consider that part of business goals is organizational morale. So we would have to take certain incidences that happen between people breakdown of communication seriously as well.

Jeff Bongiovani: But ultimately, we do want to create that repository, and we need to get folks interested and being able to document things because that’s a large part of it. And if it isn’t happening so far, it’s not part of the standard we can’t necessarily expect that when they go into like, “Hey, welcome to the SIPOC workshop, here we’re going to talk about stuff then ultimately, when you’re mapping out, what sort of process do you have? What sort of process do you have, and you’re going through all the processes. Now tell me all your problems and grievances.” That’s not going to work, it’s a lot of information. But you do have now, you can stage it one little piece at a time, because ultimately, if you have led the conversation towards customers, output suppliers and or inputs, basically now this allows you to explore the issues further upstream, further downstream, you’re broadening let’s say the vision of the impact of particular issues.

Jeff Bongiovani: And not only that, but you’re also getting the ideas into the minds of the team members of thinking and defining in terms of well, how did this customer react to that? What sort of thing? What sort of output did you have? Now, you may not use those particular words. But was there an issue with the report? What was the report missing? What did the customer need out of that? What sort of when it comes to suppliers and inputs? What information were you missing that you weren’t able to actually follow through with your process? These are all surrounding around issues.

Jeff Bongiovani: And ultimately, then when you conduct your SIPOC workshops that are focused on process improvement, you can use these issues in lessons as elements of consideration. I like the term elements of consider… Well, we do have only $100 in our budget. Well, that’s an element of consideration. It’s a constraint, it’s a challenge. But in that idea, it’s kind of like if I’m going to have to find the route between point A and point B to get something accomplished I kind of have to know the bumps in the road, or at least the considerations that I have to make during those steps.

Jeff Bongiovani: Per the risk register. So you got an issue log that’s going, well, now what you’re doing is fostering a mindset of thinking ahead. So say, “Hey, guys, we’re going to write down anything we can envision as being problematic. You have these issues, are they going to happen again? And this time around how are we going to be prepared?” So you begin with the issue log, you explore the impact and probability response plans. That sounds familiar, right? Those are different columns in a risk register. It doesn’t have to be 100% formal.

Jeff Bongiovani: But nevertheless, you do necessarily have to say, “Wow, man, that was really terrible. How often does it happen? Will it happen again? What were the setbacks? How did it impact meeting deadlines?” Notice there, you really once again, how did it impact meeting deadlines? Now, ultimately, did you develop any solutions? What does that become? That becomes what? Mitigation planning perhaps, how did you handle it? “Well, I told you boss, how did you handle it?” That’s escalation right there.

Jeff Bongiovani: So the idea is that we want to get people then to start thinking, the issue happened before, will it happen again, if the issue happens again, how we’re going to better deal with it. This might be there, the information might be out there, but it’s not standardized. It’s not documented. So this gets people acclimated to, “Wow, when the problem comes along. We’re not just whipping it, we’re writing it down.” And we also then want to go back to that language, we’re very familiar with that language and hopefully cause effect leading to an undermining a business or functional or technical goal.

Jeff Bongiovani: So when we say, “Well, if I don’t get all of the information from the IT security policy, if they’re not clear about what I should do or give examples to me, how am I going to be able to develop an exercise?” And then what does that mean? Well, that means if they don’t give me this during that session, we’re going to have to redo another session, I’m going to have to meet with them again, their calendar is always full, it’s hard for me to get an appointment with them, when they do, they don’t necessarily take it seriously.

Jeff Bongiovani: And there are all these things that are coming up, oh my goodness, like business goal, loss of time, ultimately functional, they don’t get the clear message across. So, that’s the idea. How are we going to deal with that? Well, I’ll place a call to their manager whatever’s going to be in the risk response implementation plan, if you will.

Jeff Bongiovani: So where it relates with SIPOC is what? You’re holding brainstorming sessions maybe it’s a speculate on potential risks, equipment failure, essential workers out from work at the same time, power outages, global pandemics, whatever is going to happen. And you’re leading the conversation once again towards customers, output, suppliers and inputs, getting them in that framework, looking through that lens. Not only that, but you are focusing then on business functional and or technical goals because the essence that is SIPOC, if you look back within the context, say for example, like Lean Six Sigma or just systems in general, you’re looking at what is value additive to the product or the delivery, where do we forge that is oftentimes in something that is tangible, functional, or financial in that sense.

Jeff Bongiovani: When you conduct and ultimately conduct the SIPOC workshops focus on process improvement. This is where oftentimes risk avoidance, part of the process, risk mitigation plans identified potential deviations from the expected, but we know what we’re doing. And of course, assigning your implementation owners. And there, ultimately risk escalation plans can be put in place, and you’re starting to recognize certain level of governance, and under which circumstances that we have to actually escalate. They’re not alone. Right? If we don’t have that framework of communication or incident planning, especially within a given process, what are they going to do? They might have their own solution, they’re making it up on the spot.

Jeff Bongiovani: My goodness, just go ahead and research, what was it? All the subway building in California. Look up that article, where’s your implementation? Risk implementation plan, we don’t know, we just decided let’s knock this frame out just a little bit further and collapse the entire tunnel. That’s the idea, folks, we have to have a plan in place. So this is on the spot, and ultimately lending itself to SIPOC in the sense that you’re thinking in terms of, we may have a regimented process, but these things are bound to happen. And these exceptions may have to be considered when forging whatever that process is down the road, not losing the sight on what the customer ultimately needs.

Jeff Bongiovani: But we also have been drawn to the attention that the supplier may not always give us exactly what we need. So we have to have a plan of action in order to obtain whatever that is. When it comes down to standardization, templates, we want to examine the tools of the process. I mean, ultimately, we’re the work is iterative, there should be templates. And we really do, you see all the questions here, the standard reports, log sheets, communication narratives, or scripts, or whatever you follow. Thinking back to my state job, every individual had their own interview sheet.

Jeff Bongiovani: There was no standardization and so if somebody had their own template, or had their own script sheet they may have missed up. And who knows, that’s really terrible, there were consequences. But the point of the matter is, though, that we want to start thinking of this idea of standardization. So we can begin with the templates, it’s kind of cool, right? Why not make a template? Why not have a fill in the blank form? We ultimately are here though identifying all of the documentation that can be templated. And then it gives us in draws and attention to what’s recurring versus what’s variable. And for what’s variable, we can ultimately give guidance in like a job aid or a standard as to how to figure out what that variability is.

Jeff Bongiovani: This is essential, explain the framework for what is necessary. We have to realize that over time expectations and requirements, they may change and this is why we need revised standards. They used to ask for that information, they don’t ask for that information anymore. Don’t you remember the passed a law, we’re no longer to ask those questions. But why are we still asking those questions. This is important to have a standardized process, making revisions, perhaps the standards like templates, as well as then what we’ll see when it comes to job aids.

Jeff Bongiovani: The idea is that where SIPOC goals holding template development meetings, allowing people to contribute getting them once again interested in the act of standardization. But it also offers yet another opportunity to really discuss customer requirements. And this draws our attention to making sure that if there are a supplier providing an input, they already now have a contact saying, “I have to make sure that the person who receives this is getting every single thing every checkbox met.

Jeff Bongiovani: And so that leads us to where we’re talking about job roles and activities, and how you can really start to say, “Okay, if it’s not documented, written down, where are we driving towards here,” you could start with job roles, assignments and have them list their primary assignments, making sure to define like general time, dedication on those assignments. And that means like periodicity, recurrence or how long it actually takes them to do the thing. And then look at parameters, have them explain what’s a good day versus a bad day. And that comes back to like, “Hey, maybe this is fodder for our register, maybe these are things like lessons learned” “Well, did you write that down in your lessons long?”

Jeff Bongiovani: But ultimately having them describe how they know that their work is complete? Do they have sign off? Like, is this signed off, going to the next step? Does the manager come in and say, “Hey, checking off this, checking off that? What is the phase-gate approach?” We’re putting the pieces together at this point, right? Because if you think we’re stages away from having the actual process written down, in fact, our next slide’s going to be job aids. But at this point, you’ve really been able to discuss and have open discussions about inputs, necessities, drawn attention to that, in order to get the process done, a general description, you have now discovered expected durations and the parameters between the pessimistic and the optimistic, the specific outputs, the drawn attention to and have an awareness, “That output has to be a certain way.”

Jeff Bongiovani: And then ultimately, yes, the verification validation, in fact, putting that in place, not saying, “I’m hovering over your shoulder,” but you have to have something that’s peer reviewed or manager reviewed. But ultimately, at the end of the day, it might be saying, “Hey, did you complete your work, let me just go ahead and read through that checkmark, depending on whatever it happens to be if it’s going out to the customer.”

Jeff Bongiovani: What this drills down into then are job aids, and as you can see very clearly down at the bottom, 1, 2, 3, 4, 5 different columns. What we’re going to be mapping out are the major steps, I do this thing, I do that thing and then I do this, and I do that, if they’re so inclined to map that out for you. The idea, though, is this. On the job training, that’s extremely important. If they have to bring somebody up to speed. You said, “Well, here’s an excellent opportunity,” so-and-so is going to shatter you throughout the day, but then they’re going to be expected to do it on their own.

Jeff Bongiovani: What do we have in terms of all of our processes written down, going step by step? Well, I don’t think we have that. Well, can you provide them something for that, and we can work together to be able to map that out? And the idea is that, yeah, you want it to be descriptive of the major steps, you can even call them particular names, right? What do you need for this step? What are the requirements… Do you need this information? Where do you get that information from? Who’s supplying you that information?

Jeff Bongiovani: And then ultimately, what are you doing? Do you have screen captures? You click this screen you go to here, you type in this, that sort of thing? Ultimately, what did you produce? What tangible evidence do you have? Or milestone did you hit that’s verifiable? And ultimately, who is the customer that receives this? If you look there, though, think about this. If they’re writing down a job aid, when I talk about that, it’s the major steps, specific templates and tools that were involved in each step, helpful tips, right? Just look into lessons learned. Here’s some helpful tips, maybe you have to consider.

Jeff Bongiovani: And then exceptions, or potential risks, just once again, look in the issue log or the risk register to help you out when writing that. And then the end of each step and just the beginning of the next one. That’s the idea. The point of the matter is though, this might be going a little bit too far. That is you could still hold a workshop, if they’re still brainstorming, I’m not quite clear, what are my procedures? There have been situations where I said, “Hey, let’s go ahead and let’s make a flowchart of what it is that you do here step by step.

Jeff Bongiovani: And they’re like, “Well, I don’t know,” “But you do it every day.” Yeah, but I don’t know.” “Where do we start?” “I don’t know,” “Okay, give a general description,” “Well I just I make the report,” “Well, that’s great. You make the report. Now, how did you get there?” Some people are not acclimated to that way of thinking. We’ll talk a little bit more on that in a second. But the idea is that the SIPOC relevance behind this is that job aids are fundamental for thinking both about processes and the customer requirements that they fulfill. Right, because here we have focused how the requirements that need fulfilling come together, business functional and technical.

Jeff Bongiovani: We may ultimately need to hold working meetings to walk through the construction of job aids if necessary, because why? Well SIPOC does, it requires a level of systematic and structured thinking that isn’t always the mindset or mentality of team members. But if we stage it just right, you know if that’s a necessary thing, and we’ll talk about on our next session, staging, walking through it and asking those questions, that ultimately we can get people into that rhythm. You’re ice skating, hold on to the wall before you let go. And it also does help, I believe if a person, if you’re working with somebody, and you’re realizing, “Well, if you do this, then this is going to happen.” Well we also have to consider this too, and then this, just getting thrown, all the exception this and exception that but unless this happens, well that’s important to know.

Jeff Bongiovani: Because why? They may not be lying, it’s a complex process. It’s something that involves a multitude of factors that they may not be able to get through it in a waterfall style fashion, they may have to think through it with a certain level of agility. So this way, that draws your attention to and you can start to take inventory of processes that may be more on rails and predictable versus the level or lack thereof predictability.

Jeff Bongiovani: So what are we doing, we’re establishing all the documents, besides getting the team acclimated to that way of thinking, we want to stuff it into a shared quote, unquote, library, right? I mean, there’s SharePoint, right? But there are other types of technologies out there. And if possible, maybe a shared drive where you can put the documentation. But you do want to make sure that everybody is capable of finding it, reading through it, that you can review it that perhaps you’re going to start to establish meetings, where you revise all of these, does everybody have? Did anybody encounter any issues? Any particular risks, perhaps you’re starting to have stand up meetings, or scrums, if you will?

Jeff Bongiovani: Templates, job aids, all of that. And anything else that helps to edify the process. Now, I would say that ultimately, in addition to all those, you do also want to have a central job aid that provides the purpose and function of each asset, the proper method of using them, you may want to have asset owners, like by the way, “Could you manage the issue log and you over here, you’re in charge of the risk register.” And since that’s your tablet, and I helped you to… You help me develop it, you can own that. And if there are going to be revisions, talk to me about it, that sort of thing. And in that case, you know which templates or job aids are used in association with the specific processes.

Jeff Bongiovani: As we start to build up and out, requirements traceability. Now, I’ll get to the punchline of all of this momentarily, but you got to figure if it’s not clearly written down. You can’t just sit and say, you know what, why don’t we make up a requirements traceability matrix? “Yeah, yeah.” “No, no, no. What are we doing?” We’re looking at what it is that we do, and then saying, “You know what, honest to goodness, I think we value these things and believe the customers want these things.” Now, that may be true, that may be coincidental. That’s exactly what they want. But the idea is, we’re ultimately backwards engineering a requirements traceability matrix from what it is that we do.

Jeff Bongiovani: Now, once we realize and actualize that matrix, once we have all of those requirements written out, that perhaps you’re staging it, look very closely squint at the screen, but you’re going to say in each job aid, “Well, you know what? This is what we discovered, this is the output, this is what we’re trying to build.” Thereby those must be those requirements that we’re trying to fulfill or at least we’re investigating each one of those right? Each of the requirements and thereby we have particular standards we have to follow. The templates follow those standards, the outputs follow those standards, the process owner ensures that those standards, templates and outputs are being followed and created and ultimately, what it is in the inputs and the process steps, what we need in order to obtain all of those things.

Jeff Bongiovani: I said here also the verification, the validation methods by which that we know we fulfilled those processes. So if you see anything, what is it? The requirements traceability is a roll-up. Ultimately of all the requirements found within the things that we do. Know it may be more of a bridge than building from the ground up. But the concept here is that nonetheless, it may have been a completely, let’s say bottom up type of build, it may have been that you begin at the very bottom with the the actuals. And you’re tracing your way back to the baseline. And the concept there is that from that requirements, traceability, my goodness, who are the people in your neighborhood? Who are the people who are on the team? Who are the customers? Who are the suppliers, you’ve now gathered this growing cast of characters. So RACI chart is not out of the question at this point, you can place a list of all the people on the team, and then ultimately, the roles each person plays within those processes.

Jeff Bongiovani: And if you go so far, stakeholder identification and management, you set aside each one of the… This may be private, but you have each one of the different customers as well as the process owners and suppliers. And you talk about what their contributions are and exactly what their temperaments are, and so forth and so on. Where that has its ultimate SIPOC relevance, like I was saying, this is getting the team into position. If the team mindset is the foundation, documentation is the frame, meaning that we can’t build up little walls and paint them and make it pretty and functional, and all of that, unless we have the foundation and we have the framework.

Jeff Bongiovani: And it really does, it prepares the team for SIPOC workshops in general, not that we haven’t already kind of in a way done a SIPOC workshop, perhaps without them knowing it. But like I was saying, it’s pretty much wide, it’s pretty much bottom up planning or backwards engineering from actuals to construct the plan, if you’re starting from fresh, then do it the systems or project management way. Guys start start with here’s a storyboard, here’s your epic, work it out, here are the stakeholders, here’s how we’re going to integrate, this is the vision, this is what we invest in. Great.

Jeff Bongiovani: But what we’re talking about here is that we’re already in the middle of the trip to some destination, how are we traveling, and the chances are that if we did not have the things that are the support, that is so useful, that’s so brilliant for project managing that we need to make sure they’re in place because it gets people thinking in a process kind of way.

Jeff Bongiovani: Now, our focus along the way with those processes was to drill down and concentrate on customer needs and goals and to focus on the outputs and standardization of them, saying what the processes, standardization, or at least a focus that we can write things down and externalize it. So wow, last time I showed you this diagram, it’s brilliant. But it’s the fully insulated and supported and strengthened SIPOC, with our process requirements, our quality management in place or phase-gate, being able to verify customer requirements, or at least where to position to regulate and control and manage and revise all of these things for the betterment.

Jeff Bongiovani: So that you might be asking the question now, “So what’s the point of a workshop? Why do we need one? Jeff, we’re already did it huzzah! We win, right? We’ve got all the documentation, what could be the problem?” And yeah, okay guys. But the the point is what? Just because you have a clearer picture of all the pieces doesn’t mean they’re fitting together. It might be a terrible process, they’re not getting their work done, you may have written it down. And I know that sounds crazy, like go ahead and make me a job aid of this terrible process you do that does not accomplish the work correctly but at least you have something there. That’s the idea.

Jeff Bongiovani: Maybe you wouldn’t have them do a job aid but at least a shoddy workflow chart or something drawn in crayon. The point of the matter is though, we at least have to lay the foundation and begin to have the support to move into a position of correction. And all the aforementioned documentation that you’ve been creating, it did come from the individuals, but maybe not the entire team. And we do want to get the entire team involved. So even though we may have had one-on-one meetings to develop those templates, or job aids or the risk log contributions, maybe you sent out an email. We at least want to begin those stand-up meetings and SIPOC workshops to be able to work through certain aspects.

Jeff Bongiovani: I stuck it in here. You know what I’m talking about, right? experiencing The Karate Kid moment. It’s that point where you can take either the remake or the original or any of the iterations. But here’s poor little Daniel sun, and he’s been waxing cars, it’s when Miyagi is like, “Dude block this.” And Daniel’s like, “Dude, I know karate now,” that sort of thing. It’s kind of like saying, “By the way, let’s talk about SIPOC.” And so when you’re introducing the concept of SIPOC, and you say to suppliers, inputs… They’re like, “Dude.” “Yeah, I know. That sounds familiar. I know that. I’ve heard that idea before.” And that’s the idea. We’re having that moment where it’s not just a chore anymore. It’s like you really know how to how to fight, that sort of thing?

Jeff Bongiovani: Well, you really know how to SIPOC and all along, sharing the documentation you’ve been building up with their help, being able to acknowledge the individual contributions, establishing the precedent of ongoing contributions, inviting the team members to voice their concerns, and if solicited, having those not assigned to specific work, help develop solutions. “Well, did you think about doing it this way?” It depends. Some people like to take it personally.

Jeff Bongiovani: The idea is ultimately workshops will be iterative, it seems like you know, all the preparation to the ultimate birthday party, one workshop to rule them all and that’s not the idea. It’s not. Workshops are iterative. Here’s where we go from here, and like I said, establishing the goals and working with what you’re going to do with SIPOC does rest on this foundation of holding up and standing up particular standards and documentation.

Jeff Bongiovani: When it comes down to it, there are three different dimensions that we can think on when it comes to SIPOC workshop goals. Number one, there’s the process state as it is. Well, ladies and gentle… That’s what we’ve been doing, really trying to map the process state as it is. And ultimately, perhaps we’ll throw a workshop to confirm all of that. But then there’s that transition to the ideal, and the in between part, the transition into its ideal. There’s also the level of detail, the overall or overview or summary, the specific set of processes, and then down to drilling down to that step by step to a procedure.

Jeff Bongiovani: But then perhaps a third one, because the other two maybe already have been addressed. There’s ultimately the utility, the standardization and onboard training, but taking it a step further, really measuring effort and cost, but ultimately improving efficiency. And I think that’s really then the the business goal orientation of it, is getting towards the improvement of efficiency, and making sure that we’re getting high quality without working excessively.

Jeff Bongiovani: So we’ve done on the left, right? We got processes step by step as it is, we’ve already said here, we’ve got some sort of utility, standardization or onboard training, it is what it is, but it isn’t necessarily perfect. What we need to then concentrate on is then rolling it up, looking at the big picture, we may then decide within the big picture how to re establish the smaller pictures, the process state, are there ways that we can improve? We do have to keep mindful of the fact that, when we’re in transition that one thing has an impact on the next.

Jeff Bongiovani: And then ultimately it’s their utility for it, the strategies ultimately that we’re going to play out and that we’re going to talk about in our next session. We’ve already done kind of an introduction to the overall process management based documentation. But really then looking at open discussions current processes, issues or risks, brainstorming sessions, improvement of current processes based on issues or risks, sessions focused on upcoming challenges and what processes may be impacted. And ultimately, you can also use them for sessions focused on issue response for how to better plan. But as you can see, as we’ve guided and prepared them for the conversation, documentation, getting the mindset in acclimating the team towards thinking in a SIPOC way is going to better help us to fulfill those particular strategies.

Jeff Bongiovani: So until next time, thank you. I look forward to the next session, which we’ll then get literally into guiding through those particular workshops, setting an agenda and working through them. Thank you very much.

Kyle: Thanks, Jeff.

Kyle: We appreciate another great session, everyone claiming the PDU For today’s presentation, I’ll get that info back on the screen for you now. And the activity code to claim that with PMI is xxxxxx eligible for one strategic PDU. If you missed any of today’s session, or the first session, and would like to go back and review, the recording will be posted to mpug.com later today. And you’ll receive an email in just a couple hours with the link to view that. Session one is also available already, inputs members have access to our full PDU eligible library upon demand webinars on mpug.com.

Kyle: I did chat over the link to register for part three, so that’s in the chat box. And that’ll be next Wednesday and on March 31st at 12 p.m. And we also have some more sessions on the calendar as well. So be sure to check those out and save your seat for those, the next one after this course being on April 14th, Carl Pritchard will return for a session covering the risk register boxes and how to handle those including with Microsoft Project as well.

Kyle: And with that said, that does it for today. So once again, I’d like to thank you, Jeff. Thanks everyone that joined us live or is watching this on demand. We hope you have a great rest of your day. We’ll see you back next Wednesday for part three of the SIPOC course. Thanks.


Watch the on-demand recording


Avatar photo
Written by Jeff Bongiovani

Jeff Bongiovani is currently the Lead Course Developer for Edwards Performance Solutions who oversees the production and maintenance of courses on Project Management, Systems Engineering, Software Development, Business Process Improvement, and Cybersecurity. He is also a trainer with over 20,000 hours of classroom experience spanning 17 years.

Share This Post

Leave a Reply