Sweet: Thank you Peter.
Schooff: So now to kick it off, why would you say process is the answer to today's enterprise?
Sweet: So I see process as absolutely key to a successful organization. It tells us how to work and information flows. It articulates customer requirements. And because we're talking about a process, that's actually how a customer sees how the work goes for them, so a cross-functional process actually describe how the customers see where it starts and where it ends. The customer doesn’t really care about the organizational hierarchy. So from a results standpoint, processes increase the quality in the work, they help you make automated decisions, they provide analytics, which can be incorporated and therefore provide a lot more agility and so all those things are really important to the enterprise. But although I'm a process person, I don’t see process as the only thing that's important to the enterprise, things like strategic planning, I'd say at best they're an adaptive case management process so that's another area sort of outside of process but the performance of process really informs the strategic plan. Then there are other things also like skills capabilities and company values that I don’t see as processes. So I see processes as really important but not the only thing that's important to today's enterprise.
Schooff: Now process improvement, what the key to a successfully process improvement initiative?
Sweet: Well, I like to keep things to threes; I don’t think anybody remembers eight or nine things so I'll tell you three important things. Maybe I'll have some more in my book but these are three key ones. One's a project charter. Project charter sets the improvement targets, it provides a vision, it builds a high-level map so there's your beginning process that leads to scope, and it tells you the necessary key resources. And this all gets the leaders working together because they're the ones that are doing the project charter. Then I think the right leaders and right team /right resources are also critical. Well, that's the second item. And I would call four leaders: the executive sponsor, the process owner, the project lead, and the BPM team facilitator. And then there's also a team, which will work with a project lead and the BPM team facilitator but I won't go into that here.
And then the last thing, the third thing is discipline then timebox methodology. Because if your process improvement efforts take too long, the energy just dies, so you really need to have a disciplined and timebox methodology.
Schooff: Definitely. Now, for companies first looking at BPM, how important is it to document the current state of their processes no matter how bad they might be?
Sweet: That's probably more important if they're really bad, but I consider it really important to document the current state. And I know there's a little bit of a tension in doing this or not. A lot of companies think, oh, it just takes too long to do that. But I think it's really important because you must get metric data and you must understand the foundation in your current state in order to know if you improved anything.
But like I mentioned at the beginning, I also don't think you should go on documenting current state diagrams forever, you shouldn't do all your current state diagrams before you do any projects. If you do your current state diagrams and you go back to them a year later, they're going to be all changed. So yeah, I think you should document current states as you're doing projects. And then I also feel that you shouldn't document them and people say to me, we've been documenting the current state for three to four weeks. Uh-uh, and we don't need to take that long documenting the current state. The BPI blueprint shows you how to do it in just two hours.
And I'll also give you an example. I had a high-tech company that I worked with once and they didn’t want us. So they were in this case. They didn’t want to document the current state. So I being the consultant, I tried to convince them how important it was to document the current state, but I didn't win the argument. And so we went ahead and didn’t document the current state and we actually sort of created future states or to-be states. And we were able to do that, but as we've looked at them, and I looked at them with them, the improvements we made were actually pretty small than what I would’ve called just quick wins. They weren’t at all transformational. They weren't really important ones across the whole process. So because they hadn't looked and they hadn't actually seen what worked with [unintelligible] and then really thought about what could be bigger, they got smaller results than they might have, so high on my document the current state process.
Schooff: Very interesting. And now, I think we're all familiar with the idea that what matters for a company is measure. So taking that idea, so what should companies measure in terms of their process of improvement initiative and why is this important in your [unintelligible]?
Sweet: Well, I totally believe in measures. Although I must admit, I've been calling them measures and metrics and sometimes I call them data because I think data is also important. Data may be something you're gathering. Metrics imply we're going to gather them, and gather them, and gather them. So let's start with some of those key metrics. First, one I would say is baseline metrics. And so by baseline metrics, I mean what are the metrics of your current state process, so there goes with your current state process. But they actually go with what I would say the process owner named in the charter but I call improvement targets and I ask the process owner to give two improvement targets, two things he wants to see changed in this process. So let's say the process owner says reduce the time to complete this process. Well, then the team needs to find the metric, the baseline metric for the time in this process, so that's pretty easy. We have to find out well how long does it take to do this process today. So maybe the answer is its four to ten weeks.
By the way, it's unlikely that people are going to know what these baseline metrics are. We don’t do a very good job of actually automated ways of measuring metrics. So the team is going to have to go find this out, may have to manually put it together or mash different reports together. So that's the baseline metric and the baseline metric has two parts; it has the category and then it has the value. So the category is what we just chose. We chose time because of what the process owner says. Then we found out the value, which was four to ten weeks after we had chosen the category. Now, once you have the baseline metric, then the process owner give the goal metric. The goal metric is the same category, in this case time. But he knows now that the time currently is four to ten weeks. So now he says what goal do I want to reach so he might say a 50% reduction, he might say I want the two to four weeks, whatever he says is the goal.
So that's what I would call for the beginning ones, the baseline, and then the goal. Then there are others that are important as well. Another piece that's critical is customer data. And customer data is not general data from a survey about the whole company, its specific data around how the customer feels about the process, what does he need, want and require about the process, and how's it doing right now, and what would it look like if it was perfect. So customer data, specifically around the process you're trying to improve.
Then I say there's some other analytical data and that’s what I call quantitative data for analysis and that’s data that would again relate to your improvement targets. So if you had improvement targets about reducing the cycle time, then you'd want to have this analytical data [unintelligible], why is the time right now four to ten weeks, where's the wait time, where do we have a lot of rework? So this analytical data, which will be different depending on what your improvement targets are, is data that’s underneath, its data that's giving you the reasons for these inefficiencies. So we need baseline data and then its partnered goal metrics and I put those words baseline metrics, goal metrics, customer data, analytical data, and then in the future you'll want to have monitoring data as well.
Schooff: So data is key. Now, in our discussion leading up to this podcast, we were going around that about half of the time process improvement fails. In your experience, what are some of the key ways that you've seen enterprises fail with process improvement initiatives?
Sweet: Yeah, I like to use the top three reasons that BPM.com came up with when they were doing a major study of this with their members. And those three reasons were lack of executive sponsorship, scope creep, and resistance by end users and key stakeholders. But I actually agree with those, there may be more but I think those are three big ones. So let me give me so sort of specific examples in each of those categories.
So lack of executive sponsorship, sometimes we have a BPM professional group and they'll say to me, Shelley we are not able to sell our executives on doing BPM or on doing this project and I'd say red flag, red flag, probably you shouldn’t go ahead with that project. We shouldn't be selling them, they should actually know reasons why this project is important to them and why it's at the top of their list, maybe it's about a bonus, maybe they see it as something really important to the company and the customer. So another thing about executive sponsorship is as I listed those four leaders, executive sponsor and process owner were key members of those leaders. But sometimes people don't know what an executive sponsor is and what a process owner is so they don't know what their goal is, or maybe you don’t get them involved and they don't designate the improvement targets. You're off already on the wrong foot. They should be getting involved early and designating those improvement targets. They're not supposed to be waiting until the end and when this BPI team says, here's what we recommend, then they look. No, they should be engaged the whole time. So those would be reasons about, smaller reasons or smaller example about how you get lack of executive sponsorship.
Now how about scope creep? Well, in the charter, the BPI Charter carefully defines the scope, what's in and what's out. And if you got that defined, then it's not as likely somebody will touch you and say, oh, can you just add this functionality. Well, this would make it really important too. No, we wouldn’t be looking at what's in scope and what's not. If we felt this might be important, we'd go back to the process owner and say, do we want to expand the scope. Nobody's just letting it kind of squish out. And the scope also says where the process starts and where the process ends so how big are we making this scope from a process perspective for this project? Is it fully an end-to-end process like order to cache or maybe we look at that and we say, no, we're going just take these four sub-processes and that’s all we're going to concentrate on now because maybe order to cache is too big, maybe it's much better to take just those processes.
Now my last one, resistance by end users and key stakeholders, you need to engage the end users and the key stakeholders early and often. Don't start thinking about change management when you're BPI project has come up with all its recommendations and its implementation plan, that’s much too late. And so there's two things in the BPI improvement which really help in that regard and the first is the team resources. The team resources represent the end-users and key stakeholders so they help understand the process, model it, analyze it, redesign it. They're totally engaged and part of that is that they're also talking to their colleagues so they're getting ideas and they're vetting what they're thinking about. And then there should be a specific engagement plan. I actually use the term engagement plan versus communication because to me, engagement plan is more distinct about saying I'm not just going to send you an email about this, I'm not just going to blast at you. I'm going to talk to you, I'm going to hear what you say, you're going to hear what I'm thinking. And that engagement plan starts right at the beginning and it's at a variety of levels with different stakeholders and different reasons that they would want to hear it. So that really helps in that regard too.
Schooff: Fantastic. Now, I think we're facing a future where IT is becoming one of the drivers of business success, so one of the problems that comes up with this is the divide between business and IT. In your opinion, what are some of the ways that BPM can help with the IT business gap?
Sweet: So I want to start just a little bit by giving you just two reasons, there may be many more why I think this divide begins. Heck, I have another article called The Business and IT Collude To Reduce ROI because I think both sides are kind of creating this divide whether they want to admit it or not. And so I see that the business sometimes asks the IT to fix the problem. And they might even given them a solution. But IT in the business don’t talk about the process in a larger context. And so, IT goes off and creates what the business asks for and then the business isn't happy about it because guess what, the business didn't say it so IT understood or we haven't really looked at it fully so maybe we should've optimized the results. So they don’t really talk fully, they make a request and they're the ones [unintelligible] fills the request but hasn’t totally understood.
And then I also think that sometimes IT purchases software and they implement and install it and the business doesn’t use it. Well obviously, the business is talking with its feet. It didn't meet their needs, or they don’t understand it, or its too complicated. So those are like two underneath reasons that I think that there is this divide. And the ways to bridge the gap are the business and IT; they need to be working together from the beginning. So let me just say it like the organizational level, and the business and IT should be looking at what is our strategic plan for the enterprise as a whole and how should business and IT be focusing on processes that would really help the business as a whole, would it really support our strategic plan? So they should be deciding which are the important processes, prioritize them and they should be putting resources to those processes.
Sometimes you might even have business and IT being co-process owners if they were both heavily involved in a process so that's kind of at the organizational level. And I think you go down to this sort of process level and so therefore a single process, a single project improvement project, the business owner and executive sponsor need to understand the IT component of the as-is state, the current state and the possibilities for the future state, just even at the beginning when they're doing their charter. And the executive sponsor and the process owner better make sure that IT is ready to help them when they want to implement their improvements, no need to even start on a project if IT says, oh, we won't be able to work on that for three years, we'll just be hopeless.
Then additionally, the members of the team resources should include both business subject matter experts and IT subject matter experts. I'm not necessarily talking about developers; I'm talking about people who understand the current IT processes and IT systems, IT software involved in the current process and also have ideas about the future process. And what I've found is when they work together on the team resource component, they both understand one another much better. The language barrier goes away a little bit, we have some laughs together, IT sees the whole process so they just seen that context talk about. The business is not be fooled by IT, oh, that'll take forever, or IT begins to say to them, oh, we can do that today, we've just never even turned on that functionality, or oh, this this would be a really good automation for you, or oh, adding some business rules here would really help us automate so all kinds of things that they can do together to help one another and that's where the synergy also begins.
So I'm giving you some at the high-level, the organizational level, some at the sort of project level process owner, and executive sponsor and IT and then some down at the team resources, those would be all ways to bridge the gap.
Schooff: Sounds a lot like agility so excellent examples Shelley. This is BPM.com's Peter Schooff speaking with Shelley Sweet of I4 Process. And those listening make sure you check out Shelley's book, The BPI Blueprint. Shelley, thank you so much for the podcast.
Sweet: Thanks for having me Peter.