Quick Links

Webinar Recap: SIPOC Workshop Facilitation – Part 3: Workshop Facilitation and Questions

Please find below a transcription of the audio portion of Jeff Bongiovani’s session, SIPOC Workshop Facilitation – Part 3, 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, and welcome to part three of MPUG SIPOC training series. This third and final session will cover SIPOC workshop facilitation and questions. My name is Kyle, and I’ll be the moderator today. And the session is eligible for 1 PMI PDU in the strategic category. The code to claim that with PMI is on the screen now. And like all MPUG webinars, a recording of this session will be available on mpug.com shortly after the live presentation ends and all MPUG members can watch the recordings at any time and still be eligible to earn the PDU credit.

Kyle: All the sessions you opt on on demand could be submitted to your history and the live sessions you attend are automatically submitted. And within your history, you can print or download your transcript and certificates of completion for each event, including the one for today. You can access that by logging into mpug.com, Click the my account button and then click on the transcript link. If you have any questions during today’s presentation, please send those over at any time using the chat question box on the go to webinar control panel. We do plan to answer those for you throughout the session.

Kyle: All right. And we’ll go ahead and get started with part three. So welcome back, Jeff. And at this time I’ll hand it over to you to get us started.

Jeff: Thank you. All right, lets see. There we go. Well, good afternoon everyone and welcome back for a session three or welcome aboard for a session three, however we find you here today. It’s been a journey so far. We’ve had two other sessions discussing the buildup for SIPOC workshops, but nonetheless, today’s session what we’re driving towards is really defining effective methods that enable greater workshop results. Now, yes we have employed certain methods up to this point and I’m going to do a swift review as we head into this, but nevertheless, it isn’t just about the approach within each one of the different workshops. It’s the matter of staging things. So we’re going to take a look at today, really helped us stage different encounters, different workshops, utilizing and leveraging the concept of SIPOC so that we can produce the most effective outcomes and ultimately describing workshop facilitation techniques that best engage the participants.

Jeff: So as we break down each one of these different style workshops, what I wanted to do is give you pointers as far as what to concentrate on, what questions as, how to frame the entire conversation. Now, last time on SIPOC, our first session really delved into the theory behind what SIPOC was. Suppliers Inputs Processes Outputs and Customers. And from that, we could derive a certain focus or an understanding. I have a tendency to believe that if you have one field of study or another field of study behind a certain theory, like project management theory or systems engineering theory, really what you’re doing is taking that attention and focusing it on certain values.

Jeff: What SIPOC has given us is really this attentiveness to customer needs goals and requirements, the outputs and the forms of products or services, processes that provide those outputs, resources ultimately accountable and responsible for enabling and providing those outputs, inputs that enable those processes, the fuel for the fire, if you will, and suppliers that are giving you the tools to be able to complete what you can.

Jeff: Now in systems or project management theory, there’s the concept of governance, requirements traceability, the concept of scope and the boundaries of what you’re doing or what you’re not doing, baseline expectations, quality management, risk management, communication planning, and the sort, and not limited just to that list. So one of the things that I was bringing to the table between the first session and the second session was really understanding, we’ve got the right-hand side, we’ve got systems, project managing, and we understand from a top down approach exactly how we can frame work and manage something that’s brand new and creative, it’s risk in of itself, it’s a leap a will to do something brand new that we’ve never done before.

Jeff: SIPOC seems to develop in a realm where it can be applied to something that’s ongoing existing, or it could be utilized to develop something brand new, drawing the focus immediately to requirements, curious how both of them really do coincide. But in the act of ramping up, if you will, one does not simply walk into a SIPOC workshop and start spouting off, “What are your inputs? What are your outputs?” And that sort of thing. You can do that, but what it’s going to feel like is, “Ah, I was never prepared for this moment.”

Jeff: Team members, and just in general teams, sometimes even organizations aren’t necessarily systems thinking. They don’t know the step-by-step or at least they know it, it’s in their head, like tying your shoes, but are you going to sit there and write a step-by-step guide to how to tie your shoes? You just put the thing in the thing, that sort of thing. I just do it. Well, here’s the act of documenting and ramping up and getting the team acclimated to a stage of documentation and thinking in terms of systems and customers and customer needs and the solutions that help to provide them.

Jeff: So one of the things that I had recommended in session two was to say, “Hey, look, you know, what? If you’re ramping up a team to a state where, well, ultimately I know, right? Where are you going with a SIPOC thing? It’s just for fun, right?” No, you want to use it to make improvements. You want to use it when something breaks and you want it fixed. So in other words though, what we need to do is build the team up step-by-step and one major way that we could do that is introduce documentation in a staged progression, if you will.

Jeff: And like I was explaining last time when I was seeing these process focused and on the job, what do you mean by that category? But what I was really addressing here was the fact that, “Hey, how hard could it be?” If something breaks down or there’s a problem or an issue, just write it down on a piece of paper, tell your friend, they’ll write it down for you, risk register. But in other words, the degree of formality does not have to be to the extreme. We have to make sure there are boxes that are filled in and we have to make sure, what’s the level of impact rated on a scale of one to five? We’ll get to that later. But in other words, somebody knows this could be a problem. If the fax machine breaks down, this is going to be an issue. If my laptop can’t connect to the network and they’re like, “Hey, we should be jotting that down.” That’s the idea, recording, documenting.

Jeff: When we transition into something like process standardizing, “Hey, do you have a template for that? Is it across the board?” A job aid or process procedure description, step-by-step screenshots and all sorts of stuff. Is it just jotted in a notebook somewhere? Well, that’s a good start, but can we formalize that documentation? Ultimately an assets library, something where if somebody says, “Hey, you know what, can you do what he does over there for the day?” He’s like, “Oh, I don’t know what he does.” Like maybe they have a notebook or something. Maybe they wrote it down. Well, if we have an assets library collection where we have step-by-step procedures, then fantastic. They can open up the job aid. They can read through it. This is pretty good, or this is horrible, we have to rewrite it. But at least we know where we stand.

Jeff: And then ultimately arriving at expectation management, requirements traceability, racing matrix, all these fun wonderful acronyms, call it an RTM. The team goes wild. The fact of the matter is, is that an I express this, really what are we doing? We’re backwards engineering, the baseline. That’s what we’re trying to do. Or at least we’re backwards engineering the plan based on our actuals so that we know how far a skew we are from the expectation. And I think that’s the real gist of all of this to get the team thinking in terms of documentation and standardizing, it’s important, we write it down. Suddenly we’ve got this urge to visualize it, to work with it. And going from that bottom up circumstance to more of a top down approach is where we want to have.

Jeff: And so where we left it last time, the core of hangar, “Oh, what’s going to happen next?” It was really this concept of, you’ve done a great job, you’ve documented everything and you’re well on your way to formalizing that documentation. But we’re nowhere close to really being the proficient team that we’d expect ourselves to be.

Jeff: And so doing, we frame things and we’ve introduced the terms, in terms of SIPOC, we haven’t necessarily explicitly stated it, but it’s one of those things where you know in that rough rock, somewhere down below, once you start polishing it, there’s this beautiful diamond that you can show off to the team. Oh my goodness. Maybe it’s my mood today. But the point of the matter is that, once you uncover the vocabulary behind this, it’s just the matter of changing the terminology, it isn’t that we haven’t thought of that before. So where would we be at this point? But we have their specific set of processes. Maybe we have our step-by-step and we looked at these three different dimensions, and that first one is the level of detail. We don’t have an overview or summary, but we are getting our job done, we understand our day-to-day and perhaps we’re writing it down and helping to formalize that part of it.

Jeff: But then there’s the process state. We’re doing things routinely as we were. And you know this, it’s like, “Oh, well, as it is, while I go shopping on Fridays, I get all the groceries. I put all the groceries away.” It’s just routine. “What are you going to do tomorrow?” I already know. I know what I’m going to do every single day until it’s all over, as it is. You could probably write down your routine. It is much as in some work circumstances to state as it is. But what do we need to do? Well, what if there needs to be a change? We say in its “Ideal.” And I put the ideal in quotes because it’s not the ideal. The ideal would be, “I spend $1. Look I got $20 billion in return.” That’s the ideal. Or maybe not, it doesn’t buy you happiness. Maybe you wave and that’s it. You know everything, I don’t know. But the point is, it’s going somewhere.

Jeff: Change happens and when change happens, whether you will it to be, or it’s in response in recovery, the point of the matter is you’ve got to get from point a to point B, but there’s gotta be an in-between state.

Jeff: Lastly, the concept is of utility. How are you using SIPOC? Right now, we’re in a state of standardization and onboard training. That’s the best we could do. We hired somebody else on here, Bob over there, he wrote down what he did, shadow this dude for a day or two, and you could see them in motion. We got the job aid, we’ve got the templates, that sort of thing. People are going to feel so much better getting hired onto a job. And you know, you know you’ve been there before. I’ve been there before, where they hire you on. It’s like, “All right, so what do we do here?” And it’s like, “Well, you can just watch me.” And it’s like, “Well, you click this screen and you do that and then you hit the print and then you go to that screen and that’s it.” Disgusting.

Jeff: But at least here, what do we have? We’ve got utility. Well, where could this go? Measuring effort and costs, improving efficiency. We could really use the documentation, the concept focused on our solutions and understanding the chain of solution towards customer goals and requirements by being able to make a state of change.

Jeff: So here’s where we are. And what I wanted to examine here, we have four different meeting or workshop types. Now up to this point, the scenario that I was dealing with last time was really, we have this hodgepodge team of correct commandos or what have you, they get their job done. Maybe they’re a bit autonomous and that’s cool. Maybe they’re okay with a little bit of change here and there, not too much push back. They have personality, but nevertheless what are you seeking to do? But you want to be able to become a little bit more formalized. You want to become a little bit more shaped up in the way that you present the team.

Jeff: So we’ve stood up all the documentation, what’s happening next? Well, I would say number one, document focus sessions. And I say sessions because there are transitions, you’re going to introduce new documentation as you go. You’re not going to just build up a racy overnight, that sort of thing. But nevertheless, you want to say, “Hey, here’s what we’re doing. Here’s the definition of it. Here’s the theory behind it,” and so forth and so on we’ll get into details in a moment. Well, look at this, current processes, issues, and risks. So really just developing an understanding of the current process, certainly issues that arise and risks and how we tackle them and formalizing that, improving current processes and really looking at the drive behind that, and then ultimately upcoming challenges.

Jeff: Now what I’ve left off of here, I also have a couple of additional items, but you see where we’re going is really concentrating on the here and now, where we could be and ultimately where we’re going, beyond the up and coming, if you will, is the upcoming challenges. And the reason why I’m suggesting this order will be revealed as we go through and the same concept of the documentation that we’re building up to this point.

Jeff: So before we go on and start talking about these, it’s been very interesting. In this time and day, over the last year, over a year at this point, where perhaps our work circumstances changed, I don’t know how many of you would work from home virtually, but there’s such a change in the way that we have to approach, “Oh my goodness, I’m going to be working from home. I can’t collaborate with that person. Now I’ve got to learn how to work in Microsoft Teams.” That sort of thing. It’s like, “Ugh, what do you mean we’re doing away with Skype? What’s that all about?”

Jeff: These changing technologies, the reliance on bandwidth, you’re breaking up, I can’t hear you, that sort of thing challenges, right? Well, through it all, there’s a difference between leadership and management. And what I’ve seen is our surgeons of leadership style training. There’s always been management training and leadership, and it’s been a very fascinating thing, even still our organization, we give a course that’s called from boss to leader, which ultimately discusses like, “Oh, you’re a boss.” That has more to do with emotional intelligence. But if we think of leadership, leadership as I have seen, read has really become a term that’s associated with inspiration, inspiring the team, being able to sustain the team enthusiasm and knowing the right strategy for the team and how well to implement it.

Jeff: But what it comes down to, is that it’s people focused. It’s people focused. It’s ultimately that the discussion of emotional intelligence, where it comes down to like, “Oh, that’s who you are. You’re very interesting. Wow. Yeah. I like your personality.” Well, in some ways, “I want to be your friend, but my goodness, I could see where they could help when it comes to accounting,” that sort of thing.

Jeff: The point of the matter is though, that a leader is the inspiration, it’s the drive, it’s the focus, it’s the purpose, it’s the breath. If you will, management however, is what ultimately transforming investment into value. Working with the numbers, the business requirements, the feasibility, adapting a carefully plotted plan while still adhering to and fulfilling goals. Isn’t that what it’s all about? You not only walk the walk you get there when you arrive, everybody’s like, “Hey, congratulations. You really fully implemented that plan despite all of the issues that went along the way.

Jeff: Building in predictability. And we discussed in the first session within the first 10 pages, I think it is on page 10 of the glorious [Pemba 00:18:10] guide by PMI, version six. What is it all about? We work for better predictability. And that’s also why, well, if everything were predictable, why would we have to document anything like a risk register? But that’s the whole point. While discovering the limits of the unpredictable, like how far could this go? Could UFOs come down? Probably not highly probable, but the impact would be terrible. That sort of thing. So we look at the limits in the edges of how far the unpredictable can go and try to work out the way where we can have that carefully plotted, whilst plan arriving at our destination.

Jeff: So leadership is about the people skills. Management is ultimately about being able to do the things. I was thinking of an analogy, it’s like, “Oh yeah, you could have plenty of wind as a leader,” but if you don’t have sales that boat ain’t going anywhere. And the point of the matter is, you got to have both, that’s what works in the long-term. The reason why I’m pointing this out is because what we’re doing is enacting a role of being both the leader and the manager at the same time. What you’re trying to do is build the team up, but to get them inspired, I say inspired loosely, but building them up to get inspired about better managing within the team. And hopefully the inclusion will help to that end.

Jeff: So number one, we arrive at that document focused session. And I said basic, you’ll see advanced in a few moments, but first of all, what do we want to do? We want to discuss the purpose for the documentation. What are we doing here? Why are you introducing this to the team? Are you mad at the team? And you said, “No, you got to write down everything.” No, you say you want better for them. You’re not trying to micromanage everything, which is probably the biggest fear out of anything. Up to this point, you’re really cool about playing it fast and loose.

Jeff: But now you want us to write everything down. What is this? What are you trying to do? Are you getting rid of us? Well, no. You say, “Look, if we document it, all these problems, they’re not going to go away. We’re just going to be better suited to tackle.” I asked you to write down things in this issue along, why were we doing that? Oh, just for fun. So we can complain, an event, you got your journal there. The idea is no, we want to take those pages and transform them into action. That’s the point.

Jeff: So ultimately what’s going to frame the conversation is the SIPOC concept. You do want to get into the general systems, project management concepts and things like that, but not into excruciating detail. Not everybody thinks along those lines. It depends on the team. I’m blabbing right now because I’m reflecting on lots of teams I’ve worked on that were probably like, “What are you talking about? What kind of nerd?” That sort of thing. But the SIPOC, seems to be approachable. You say, “Well, why are we doing this?” We’re doing it for the customer. What is the customer? One, people can understand that.

Jeff: So really where you’re saying, what customer needs requirements, let’s begin there, I’ll put standards and then you can refer back to the document. You could say, “Okay, remember that job aid that we put together, discussing how to do audio scripting using Amazon Polly?” You had the SMI hand off the written script to you that the ISD looked it over and said, “Oh my goodness, it’s truly is going to sound like a robot. So it’s better off.” And then you say, “Well, that could be an issue.” So what do we do? We’ve started to build output standards and what do we do for the SMI or the ISD authors, we’ve took those standards and we gave it to the authors to try to follow while they’re writing it through and now they’re producing better work. And everybody’s like, “Oh, you know what, that absolutely makes sense.”

Jeff: And the process that we go through Amazon Polly, where you’re copying and pasting the script, and you’re trying to translate it into language, don’t we also now have templates and we have certain guides, yeah. That made it a whole lot easier. We were copying and pasting. So reflecting on what you’ve had them do to this point, if you don’t have that, then what do they have to reflect on? They’re going to say, “Well, why would we have to write it down? I already know how to do this.” And then you’re trying to justify in the middle of this beautiful speech to try to inspire the team. And it’s like, “Oh, well, we don’t need to write it down.” It’s like, “Oh, so you can go in and see what we do, you can replace us and hire somebody else,” and that’s the idea. We don’t want it to come to that.

Jeff: So having the documentation up to this point, easing people in, the inputs, resources, suppliers, and I say here, logical dependencies, because what haven’t we really discussed, we may have had everyone do their independent activities to build up their process, but we necessarily having connected everything together, and there’s something to be said about that. But at least saying, “Okay, so this is where you’re getting it from?” “Oh, you get it from that dude over there,” that sort of thing. ISD hands it off to you. You take it, you put it into the presentation. You make sure the audio quality is just right. You pull that into Adobe, whatever it is and fix up the audio or Audacity, I don’t know, whatever tool you’re using, it’s free. But the point of the matter is, you know where it’s coming from, where it’s going. And that’s the focus, that it’s not just siloed, that it’s going somewhere.

Jeff: So then you start introducing the overall process management based documentation and you’re explaining each one and expressing it in terms of the SIPOC. So you can really say, “Okay, why don’t we start out with the lessons learned log, issue log, we’ll look at the breakdown there. Let’s read through some of the issues that recorded.” And you say, “Well, that relates to this process.” This relates to a delay from the supplier, giving you that input. This is an issue where the customer said, “Well, I don’t like that.” And they throw it back at you and said, “Well, the output’s not good enough. You missed X, Y, and Z.” So that ultimately led to what? Well, further down the list, you get down to where you have your stakeholder identification and management, you’ve got your requirements traceability. So maybe we have to start looking at building better standards. Maybe we have to start looking at that stakeholder in terms of, one minute they’re telling us exactly what they want and then you hand it in and within a week they changed their mind, that sort of thing.

Jeff: So what’s a better approach? Can we have them sign and document something? Well, we’ve designed it to your specifications here or open up a channel, be more iterative, whatever it happens to be. But you start explaining it in terms of how then each one of those could really help us along the way, the job aids, the process procedure descriptions, the fact that they’re all housed in an assets library.

Jeff: Now what’s going to happen though, is that perhaps there are missing items here. Maybe you didn’t get so far as the RTM or your RACI or your stakeholder identification and management, and that’s fine. Just tell them what you have and maybe say, “Well, where could we go from here? What do you think?” If a customer’s complaining about a particular product and they say, “You didn’t do this up to specification,” how do you think we should handle that? I know we wrote that down and maybe the teams developing this, can we write down the requirements somewhere? And you’re like, “Oh yeah.” “Oh, man, what shall we call it?” The requirements document. And that’s fine, whatever it takes.

Jeff: But sometimes helping the team, you know where they should go in the answers to their questions. It’s the matter of, that’s what Socrates would do, but you’re trying to really guide them to answering the question of how the document, and maybe they’ll surprise you. Maybe they’ll reinvent project management or systems theory, who knows.

Jeff: Now, of all of the items, you got to ask who are you inviting to this? But this could be a whole stand-up meeting. And when I say that stand up meetings for teams are an important thing, they’re extremely important. Especially even if it’s a functional team that’s doing a routine week after week after week. It’s good for the team to get together for that half hour to an hour, and hopefully you can execute an agenda. But the idea is that you can run through any lessons learned this week, any new risks, how about our different projects that we’re involved in or different daily routines? Did anyone here discover anything brand new or make an improvement upon the process or there’s some insights there? So that’s the idea, getting people into that routine of the standup. Now, hopefully this is an extended version of a stand-up. Getting people together, while on this very special edition of standup meeting on Monday, you start introducing all of this, but what you do want to do, and I think this is the cornerstone of where to begin is developing that RACI matrix.

Jeff: I’m seeing that, and you may have a disagreement and it’s fine, hopefully we’ll glean something from this, that is something that’s important. But I always have viewed the RACI matrix as this Keystone right in the middle, because what does it do? What is it identifying? But it identifies the people on the team and then associates them with their task related responsibilities. And why is that the Keystone in the arch? It’s because on the one side you have all of the customer requirements, external customers, internal customer, whatever their routine happens to be, whatever they’re producing, you have all the requirements and then you have on the other side, all the routines, the job aids, the templates and tools to get everything accomplished. And so if we focus on this first, we can start to build outwards on both ends.

Jeff: So if the team already has prepared job aids and process guides, and they’ve already expressed what their roles are and if you’re currently a manager, you probably already know this, but finally, what do we, we have our responsible and accountable. That should be obvious. So I’m imagining something like an Excel spreadsheet where you have over on the left-hand side, because that’s going to be a lot taller, every single thing that people do. And then across the top, you have the team members, unless you’re towing around 300 people, then break it into smaller parts. But the point of matter is, that you’re cross comparing, here’s what the people do, here’s who the people are and then you’re marking down who’s responsible and accountable, that’s obvious. What may not have been obvious up to this point, what you want to do is confirm the existing entries to make sure that everything’s all right. You work on this, but the point of matter is locating the missing entries.

Jeff: And I found this is not related to SIPOC in that sense. But I found this so many times working on specific projects that consulted and informed were missing. Every single time that they finished this, I should know because then I do this. Ultimately, even though my role as the lead course developer, when an instructional designer finishes a particular task of updating a presentation and things along those lines, yes, of course I should be informed, but so should the manager or the customer, something like that for confirmation. Like did they do the job that was integral to this? You can tell me all you want, I love it. But ultimately, should we then consult with a customer before moving on to the next step and finalizing the materials? That’s the point.

Jeff: So consulted can constitute an input or output, and it may be in the form of information. There may be documentation involved in that step of confirming, maybe it’s a phase gate. Like I was describing, go onto the next thing because I approve. But that’s the idea. It’s something that needs to be put into the process, ultimately in that job aid.

Jeff: So really developing the RACI matrix then starts to build out. So we’ve got all of our process owners, we’re starting to view then if we start to develop flow charts and tables and all sorts of fun stuff, we’ll talk about next. Then ultimately we have a better idea of the full scope of who’s involved in that, now with the consultant and also the informed.

Jeff: So then what do we want to do? We want to list the other process job aids, now that we’ve got our RACI, we’ve updated, we confirmed, we did this. This is where can associate that with the RACI. We’re making the connection. This process right here, do we have clear cut documentation that describes what you do right here? If we wanted to go in, if there are too many issues, too many problems with customers and outputs and they’re not liking it, or we have delays when it comes to getting information from outside sources, then by having that particular job aid and having our estimates and having our step-by-step guide, we can really look at and start to estimate where the delays are going to be. So we can better understand why it is you’re turning that in two weeks late, it’s not my fault, it’s somebody else’s fault. That’s the point, true transparency visibility.

Jeff: We list all the templates associated with the processes they belong to, which also should be included in the job aids. But this is the expansion, that’s the connection. And then here we got a risk register, we can work on that. Lessons learned log, issue log, we can work on that. And you can describe ultimately how you need those to be used. Make sure you document everything. Go ahead. When it comes your way, when it’s a problem, jot it down. No issue is too small. We can always go in and delete it if we want to ignore you, just kidding. The point is, this gives us more information, more insight on what it is that we have to deal with. And that’s the idea. Diagramming how the documents connect and the purpose behind our interconnectedness.

Jeff: When there’s an issue in the job aid, you write it down in the issue log. You came across this problem, you anticipated a risk, so this way now the job aid connects with the issue log, the job aid connects with the risk register. The job aid connects back to the RACI and the job aids and RACI as they identify the different tasks, relates back to what requirements we have to fulfill. So we have everything, this whole thing orchestrated as far as its interconnectedness and traceability.

Jeff: Now, Like I was saying, stand up meetings are a chance for you to review the documentation that you’ve produced. What will happen over time though, is really heading towards something that’s advanced. Notice I wrote the word advance after that. Because when it comes down to it with customers, we really have to concentrate on needs assessments and elicitation. I want to say solicitate, elicitation of requirements and stakeholder management plan. Then as that gets translated into, we have requirements with requirements, come risks. So we have this marriage, perhaps a requirement categories, risk categories, seen intersections between the two. Requirements I said here, reliability ratings. Because in that sense, you go back to the first session where I was talking about the Stacey complexity model and predictability and the concept that, well they’ve told us, but you know that could change at any moment, and it may not just be about people, but it could be something that has to do with technology. It could be something in the field, first to market, the early bird gets the worm, but the second mouse gets the cheese situation.

Jeff: So the idea is that the requirements may go up and up as far as timeline, rushing that to market, the quality guidelines may diminish or go up, who knows. But the reliability of requirements really then says, do we have to take a closer more iterative approach and really emphasize requirements management and in more of an agile type of look at things?

Jeff: And then ultimately the traceability methods with requirements to your outputs and solutions and risks. The beat goes on though, all the way down the line to where we’re talking about solutions with a component breakdown, things can be decomposed small and smaller. Don’t have to go too far, too small, but if it’s something surrounding a technical requirement, programming code if you will, a certain technique, parametric estimating for executing and producing code. The idea is that you really want to start looking at those predictive methods because they may have to change, that’s something that’s adaptable over time. Process owners, ultimately monitoring and ultimately sign off, quality management, we had discussed before. So these are targets, what should we work on today guys? Should we work on our risk strategies? You don’t do this overnight, you work on one thing at a time. But nevertheless, certainly it does have a trickle down effect and we know that. It is something that will recur as we look through some of the other slides. But if a customer moves their requirements, then everything, that’s a shift in the foundation and everything moves with it.

Jeff: We may try to implement a different process altogether to try to achieve a particular output but we’re playing the game within, in the context of the requirements, making that change it’s not going to be devastating to the whole, what it is that we do.

Jeff: So speaking along those lines, the next step is really to map the current processes, and be able to discuss issues and risks surrounding it. So based on the RACI, what do you want to do? But now you can break out into smaller teams of those who can attend to a focus or working session on one specific process, you can identify all the customers, suppliers, and remember it’s a lot easier with a completed RACI, a lot easier with completed job aid because you have those references, you can use the single project as an example, for example, the security e-learning project that I spoke about in our first session, and that I touched along here, but you would say here, so the ISDs, the script writers, IT SMEs and HR reps, they’re all of our various customers, and are also suppliers in all of it, but all of them have a particular thing and role that they have to play. So you lump all those customers together.

Jeff: The point of the matter though, is identifying the explicitly stated requirements, but in examining through the job aid and examining through the temperature and what you know from all of the customers, you can also start to identify all the implicitly stated requirements to leverage that example for an e-learning project. It wasn’t a security project. It was producing a particular e-learning course. But at the time, it was the first time that we had produced it. So talk about interesting when you turn it over to somebody who’s supposed to QA it, and then you say to them, “Well, we have no standards. So make it up as you go.”

Jeff: We do want to have the font size this size so it’s readable and this. And we have to follow the branding colors so forth and so on. But when they went through it, they were hitting enter and wrapping text, and they were enlarging some of the text to making this bold and moving things around. And I was asking him, do you have a moment to sit down? But in a way, had the backwards engineer, the standard for QA in the learning modules that we’re creating. So that’s implicitly stated requirements. Explicitly would be, here’s the list of what I want go do it. Implicitly would be I’m going to whine or complain about stuff and maybe I’ll give it up exactly what I want from you.

Jeff: So where are we going with the mapping? Because what do we have? We’ve got the complete erasing. We got chubby. So here’s the point you want to build up the job aid, but you also want to start mapping things. And this is where the beauty of the SIPOC diagram could either be a shiny example or something where we say, why aren’t we doing it? This is crazy. Nobody’s going to want to look at this. And when we show it to them, it’s crazy. Well, here’s the point, you could have a list of step-by-step actions, with a free form list you can give screenshots additional tips, full narratives, that’s great. With a step-by-step table, it’s highly organized and can keep the general information together and workflow diagrams, great at the picking of process with multiple decision nodes and also helps visualize the process and easier for the team to make process revision, they can point, that happens first, that happens next.

Jeff: But there’s a drawback to each one of those. Well, the step-by-step list, it’s a little less organized and it’s a little challenging to standardize across multiple job aids, unless you’re using some template that break it down. The step-by-step tables, cool. Well, but it’s not great with decision nodes, so what are you supposed to do? For non waterfall approaches to things. It’s like, well, does that happen first or next? It’s a row up here. These all happened at the same time, but these down here happened afterwards, it’s a weird.

Jeff: And then the workflow diagram, it’s terrible. Terrible when people try to jam too much information into each box, I’ve seen it before where it’s this process will chart and you get to this one huge rectangle, it’s got a paragraph of text in it, please if you’re that person don’t tell me, it’s okay I forgive you, but don’t do that again. Okay. That’s too much. It’s an unreadable.

Jeff: So what’s the solution? Use all three. I would say the workflow diagram is great to pick the overall process at the high level. You could use as you’re building this, you can use sticky notes or a whiteboard. You could sketch a workflow, only use short task names or unique identifiers. And where are you going to find all of them referenced and broken down into a little bit more detail? You’re going to find the workflow diagram is depicted in tables. That’s where you can go all SIPOC of the suppliers, the inputs, the process, the outputs, the risks, and that’s the point. Each branch of every decision tree should be given its own table. You could have fun with formatting. Then you also want to converse about each process in the workflow. Identify the requirements, set relevant risks, identify the suppliers, inputs process names, where are you putting all of that in the table?

Jeff: And then last but not least the table may have the reference to the step-by-step guides. So you’re breaking it down. Workflow big, smaller table, smallest step-by-step list. In this way, you do have a continuity between all of those three levels. Because you know, if something switches on the workflow diagram, you say where should we look? Well, let’s look in that table and then you see the shift in the table. That’s going to be a problem. That’s going to interrupt that step-by-step guide. Or are you looking through the step-by-step, you changing something and then you can trace it back up to the top. It’s the point. And you know what I’m talking about when you have those 2000 LINE Microsoft project projects, workflows that span like three years and you’re looking at it like a ton of boxes that are scaled down five levels of breakdown.

Jeff: So I wanted to talk about contributors because about the team. You have your team members, what are they going to do? What are their issues? Well, they’re not really issues. Now, let me just say this, grown adults are not going to change. They’re not, instead though, they can learn to channel their behaviors into “Positive addictions.” If you want more information, go ahead and read that glorious book by William Glasser M.D. Positive Addiction.

Jeff: On the other hand, maybe they can learn some new interpersonal behaviors to build team cohesion. If you want to learn more about that, there’s Emotional Intelligence by Brandon Goleman. Having said that I will leave that, let it linger. Take your screenshot, click the camera, whatever you want to do. If you want to reengage, you say “Jeff, I read those years ago.” When was that? 1985 for positive addiction something like that.

Jeff: Here’s the point. Let’s talk about our contributors, the “Problem.” I always say, you know they’re great at problem. Maybe not problem solving, but they’re great at problem. It’s somebody on the team who likes to point out problems persistently, but sloven contributes solutions. What about these people? These people are extremely useful, I’ll tell you that. They’re great at providing entries for the issue log, let them have at it, write down all the issues. You’ve got a place to put it now, buddy. Have them note all of the issues they spawn, have them record them, if they have a problem with the issue log, which they probably will, have them work on fixing it and they might also be helpful at contributing to the risk register as well.

Jeff: This are positive ways that they can focus their attention, but the point is, but the problem solver, they’re so focused on problem and not necessarily solving, but there’ll be useful because they’ll have it all written out. We can come up with a solution or you say, if you’re going to have a problem with our solution, go ahead and bring up your own. The small picture person. That’s somebody else we have to watch out for, especially as we lean into the next few slides. The small picture person, somebody who fixates on the minutia of a step or the plethora of exceptions to one rule, but this could happen, but that could happen. And then this, it’s like, well, how long is that going to take? Well, it all depends. It might take three weeks. It might take two weeks. It all depends on this happening. And if this happens, then that’s going to happen. And if I can’t get this turned in, then I can’t get that turn in. Might even be four weeks, but it all comes back, you know what I’m talking about?

Jeff: Those people are great at building helpful tips and guidelines within job aids having to go through each step, what are the exceptions there? And they will also and can be filled with technical requirements. They’ll say if you don’t do this, this will happen. It’s like, there you go. Well, let’s do that. Always give them the context or focus or have them give the five most important things. Out of all this stuff you’ve been saying, go ahead and give me the top five.

Jeff: And I love asking those folks. Always tasked them with, how would you summarize all of that? That’s fun. The point of the matter is that, if you do have negativity, if you have pushback, there’s always a place for it. There’s always a mode where people are going to be strong contributors and there is maybe something that they could learn. But ultimately I don’t look on these folks as very negative. I’ve worked with these people before and I prize them, especially if we’re piling at a class and then what do they do? They give feedback for how the course, how terrible it was. And you know, you’re going to have all of the corrections to make, but you know what, if it weren’t for them and everybody else would be like, “No, you know what? I kind of liked it.” Do you kind of liked it? They’re going to be honest.

Jeff: So number three, we get at this whole improvement of current processes. And to get the most out of them once again, you have issue entries, flow charts, process tables, step by step guides. You build up to this at this point, documented standards based on customer requirements. Now, one of the things though, theoretically, and I really think this is cool, I don’t know if you’re into that kind of thing. One reference, there’s a great video called Hill Climbing Algorithm and Artificial Intelligence, being a nerd for seven minutes, it’s on the channel computer file. But it’s really interesting, even though they’re talking about AI, the concept is that, well look, if we’re constantly renovating, improving upon the process really is this the best process to improve upon?

Jeff: Of all the ways to get the work done is this going to land? Is this the best process of every process that ever existed? And I think in an analogous sense, looking at intelligence, which they’re talking about in that particular video, they said, we make constant tool retooling and improving and doing this and doing that to get to the next step. But in the random walk, given to let’s say an intelligent machine, they might find themselves on top of a plateau, but it isn’t necessarily the highest plateau of all plateaus that they could climb, but they’ve optimized what may be a sub optimal process. So the examination is really saying our current process, so should we record it all and start all over? Well, heck no, no way. You should not do that because why that may strain the team to have to start over and relearn certain process. They’re not going to like that. They’re used to their routine. You can’t change everything overnight, but the drawback to that is maybe you’re improving upon the faulty process.

Jeff: So the best way to look at this, it’s really set the longterm or maybe the next mile marker type of improvement. And you can course correct as you go along. The advice that I give you here, focusing on the one process, listing all the current requirements, hopefully they’re current, describing the products or services that could satisfy those requirements and looking at the minimum viable product. When I say that, keep only the components or elements that add value. You want to consider the issues and risks surrounding the current components and explore the risks that may arise based on newer change components.

Jeff: Then you want to walk through that new step-by-step for each of those components, will the input stay the same? Will they increase or reduce? Will the supplier stay the same, increase or reduce? But the idea though is that this is not isolated. It may in fact impact other processes and process owners. Thank goodness we have our flow chart interconnecting the different processes that in fact are interconnected, that’s worth examining. And so one of the things, especially when we look at the concepts of iterative course correction and why the agile approach in its fundamental form is really saying, we can’t necessarily solidify a hundred percent, but what we want to do is take in course correct each stage along the way. So you look at your current process, you say, “Okay, where do we want to go next?” So we can keep our eye in longterm, but we can look through.

Jeff: So we have revised process stage two, it could go either which way in our decision tree, revised process stage number three could go any which way. And this is the study that we do, especially when we talk about risk mitigation planning. Part of the theory and quantitative risk management is to look at the value to be had, depending on whatever project or way that we pursue the future. But this is also then in a qualitative sense saying will this position us, or put us in a better spot to become a better team, to be able to better handle requirements, shifts and changes.

Jeff: I don’t know if you’re into playing chess. Are you chess players? Who knows? I remember fundamentally, and at the core of chess plan, you have your opening and then it moves and then you have your closing. But the real overarching concept for what wins you the game of chess, is maximizing your mobility on the board, making sure that every piece can move exactly where you intend it to move and to understand where it needs to move down the road. So I love that quote from Gary Kasparov, “How do you know where you’re going, if you don’t understand your destination?” Well, that’s the idea. Some game theorists suggest that tic-tac-toe perhaps, perhaps chess is a solved game. But project managing, systems engineering, that is not a solved game. You don’t know the optimal strategy is this, “Oh, we’ve win, we’ve made all the money and everybody’s happy and lives forever,” that that doesn’t happen.

Jeff: So what do we know? What’s the constant? Well, we do know we plan small incremental steps. It helps the team to acclimate to change more easily. Customer requirements can shift, they can change, and that can undermine on a long-term plan. But ultimately, what do we want to do? We want to focus on the long-term strategy and it isn’t just getting the job done. Yes, of course, it’s getting the job done, but we want to simplify what can be simplified. We want to create a flexible team and we want to create a team that’s proficient at building and rebuilding processes. Because if we have to change, if we have to move, they have to understand what it is to make those moves.

Jeff: So with that said, what is the fourth stage? Upcoming challenges. This is best when the team is ultimately capable of process thinking and enjoys documenting everything, they love it. What are the changes? Regulatory legal? Okay, now every presentation make has to be 508 compliant. And what does that mean? Well, now we’ve got to dig right into all of our process guides, all of our templates. We have to re examine all of the e-learning modules. When it comes to the audio, do we have subtitles, printed scripts, things like that. Maybe it’s a cut in funding or budget or change in team members or team roles. Oh, you remember those five people that used to work for you? Same work to go around less people. And so the point of the matter is, we now have things documented. We have a systematic approach where we can say, if you throw that rock in our pond, we know where those ripples are going, or at least that’s where we want to get. And so identifying the impact, we can use our workflow diagrams to pinpoint those issues. We’re going to follow the issue down through the workflow tables and step-by-step guides, or as I was suggesting earlier, from the bottom back up to the top, and we can ultimately examine the racy and changes in roles, responsibilities, and pursue training if necessary.

Jeff: Now beyond these essential for additional activities may include things like issue and risk management reviews, if you’re not doing that at your stand-up, you at least do want to have a formal meeting, that’s a little bit longer maybe to go through the issue and risk log to see what you’ve handled, what could be expired or what isn’t there. The Ram, RACI matrix into a Ram. Because if we are looking at a reallocation of hours from one team member to the next, we want to know where those hours are going. So you can really expand the RACI matrix if needed to, into a resource allocation matrix, that’s where you’re really estimating the amount of hours that are going to be spent doing particular activities across any increment of time you’re choosing.

Jeff: And then when it comes down to the improving efficiency and expanding quality, I think one major point as we wind down to the end here, is understanding and I’ve had to have this conversation, honestly you could tell by my tone, I’ve had this conversation, I would say four times over the last year. Recognizing what’s effort driven, “Oh, just throw more resources at it and we’ll meet the deadline.” Not so fast. You can put more cooks in the kitchen, doesn’t guarantee that it’s going to be delicious. Effort driven, automation potential and craft dedicated.

Jeff: And when I say craft dedicated, let me give you for example, there was a project that I was working on that so long ago where the QA, the quality approval and editing team had an entire week dedicated to review a manual, to see whether or not the writing was up to par and make their edits and their changes and updates. The project manager said, “Hey, why don’t we shrink that on our schedule by two days?” And so I responded back and I said, “Well, what part of the scope of quality would you like me to remove from the manual? How would you like the quality to decline?” Now they love my attitude because I’m honest. And then they put the two days back on. But the point is that if you have a craft, like you’re an artist, you can’t rush that. Quality control has to be at a steady pace.

Jeff: I think underlying all of this is, is that we can draw pretty diagrams and we frame the work. We definitely can frame the work in different lights. Here you see the Rosemary’s baby of project management and SIPOC, all cuddled up and it’s bassinet. But what we’re really looking at is the team, that has to navigate this and the focus of that team set on meeting the customer’s needs and understanding the push that it takes to get there. Now, what can help and assist all of this, is to build up a library of documentation, to record all of it, but also to inspire the team, to engage that documentation, to list their issues and risks, to write down their process, to be able to say, “Hey, I can help out. We can improve this. We can make it better.” And when it hurts, we know where to point, and we’ve got the team together to navigate through this.

Jeff: So I thank everyone for giving me that extra minute of your time. For the most part, SIPOC is very interesting and it’s always been a wonderful subject for me. I hope that you all have learned a lot across these three sessions, and it’s been a pleasure teaching all of you. Thank you.

Kyle: Thank you so much, Jeff. We really appreciate your time and sharing your expertise, in the session in the full training series itself. Thanks again. We really appreciate your time. And for everyone claiming the PDU credit, I’ll get that info back on the screen for you now. Today’s session eligible for a one strategic PMI PDU. And if you completed the full course, that’s eligible for three strategic PDUs, each session having its own code. And if you miss any of today’s session or would like to go back and review, the recording will be available for you in just a couple hours, and you’ll receive an email with a link to view that on demand.

Kyle: We have some great sessions on the calendar, we’ll be back in two weeks with Carl Pritchard, covering those risk register boxes and what really goes in there. And that’ll also speak to using Microsoft Project as well for that. The following week on the 21st, we have a session on how a project manager should organize their work day, every day and where Microsoft Project fits into that as well.

Kyle: I have quite a few other sessions on the calendar, and I just chatted over a link for you to get to that. You can claim your seat or reserve your seat for those sessions. We hope to see you there, and that does it for today. So once again, thank you, Jeff, for presenting the course for the MPUG community. We really appreciate it. Thanks to everyone that joined us live. Thank you to everyone that’s watching on demand. We hope a have a great rest of your day. We’ll see you back soon, for our next session. 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

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>