Ben Eadie: Hello everyone. My name is Ben Eadie, and I'm the online media manager of modernanalyst.com, the premier online community for business analysts. I'd like to welcome you to today's webinar, titled "Learn the 11 Habits for Highly Successful Business Process Management Programs." Today's featured speaker is Bruce Partlow, client partner, BPM Solutions with IBM Software Group. Bruce has over 20 years of experience helping customers improve their business processes; ten of those being with IBM. He has been focused on BPM projects and maturity for the last three to five years, making a significant impact at companies, both big and small, around the world. The webinar will last approximately 60 minutes, including the Q&A session. So make sure to submit your questions in advance, using the Question feature on the webinar software. I'd also like to say thank you to IBM for sponsoring this event. And at this time I'll turn it over to Bruce to get us started.

 

Bruce Partlow: I'm going to go through the collection of 11 habits of successful BPM projects. We've been collecting this for I guess almost a decade now, and frequently we get these questions from customers as to, "How do I be successful? What's the patterns or best practices?" There's a variety of ways the question is asked. But really we have collected from our customers, both big and small, these successful patterns or habits that really are characteristics of organizations that really are able to try BPM adoption and success in their organizations. So at IBM we believe that BPM is about helping customers improve productivity of their people. Fundamentally that's what it's about. It's about providing innovative software and expertise to engage business process owners and their participants in every aspect of process improvement. And that's an important point, that holistic view, because at the end of the day, if you're in IT, you can never know as much about the business process as the people who are actually in it. So part of that, from upfront discovery documentation of the business processes, all the way to the actual construction, we strongly believe that you need the tools and capabilities and the methodologies that enable you to engage, and stay engaged, with the business throughout the cycle. 

 

One of the continuing points that we find is the collection of the right business data and metrics that are used to measure and identify the areas for our process improvement are very important. And our focus of business process improvement initiatives is putting business engagement first, and that has consistently yielded the most transformational results for our customers. 

 

The things that I’m going to go over today was loosely based on this framework that was suggested by the famous author Stephen Covey, The 7 Habits of Highly Effective People. Whether you've read it or not, the basic point that he makes is that you have to have a paradigm shift in order to be effective; that you have to think about things differently, you have to approach your problems in a different way. And there's a progression and stages that you need to go through, in terms of building up both your capability to become more effective, and the ability to take advantage of that. And the first stage of that in his book, his examples, looking at yourself as an individual; being individually effective, and as it progresses to being someone who can have effect across others or within your organization and community. We believe that BPM is very similar to that. When you look at the levels of BPM success, you can't just jump to the top. If you don't have a BPM program in place, if you haven't done the basic learning, you can't just declare a center of competency in your organization, and "Henceforth we are going to be improved in our processes and our efficiency effective by commandment on top." It just doesn't work that way. The reality is that you have to build it from the bottom up, and that means you have to learn the basics at each level. And with each level you'll find that that level supports the next level of maturity and the next level of growth. 

So starting with the ability to deliver successful products is the first point. If you can't deliver successfully in a rapid and value-driven approach, then you have no hope of leveraging BPM across an enterprise. It will just become a huge money waster and time waster, as opposed to being really transformational. And remember that success breeds success. Once you have the wins, people will come out of the woodwork to be part of additional wins. And that is a consistent thread that we've seen. Some people refer to it as being viral in their organization. But case after case after case that I see with customers that are highly successful, that really are transformational, it doesn't start with a super-integrated grand strategy. It starts with dealing with a tactical business issue and being highly successful with that, and then replicating that success throughout your organization. So one of the key questions you'd ask is, "What are the habits that will help an organization move up these levels?" And that's what I'm going to talk about today. 

 

The first one, as I said, successful projects and delivery are critical. So the first habit we're going to talk about is proving your business value first. Don't forget to focus on your business value, and be willing to make tradeoffs of your first release. This is kind of the antithesis to the big-bang theory of let's gather all of our requirements, let's build this huge waterfall approach, and let's analyze everything to the nth degree, and then deliver something to yours [ph?] now. That really makes it very difficult to prove your business value and associate your business value and its true impact to the business. So don't do too small a project, but you need to do a project of sufficient size that you can learn how to deliver these projects. But also, and most important, it has to be associated to the value and bring balance to that value equation. While you can do lots of things-- an example being is that you can put a lot of time and effort on the beautification of a screen. Does the beautification of that screen really have any impact on the person doing the work? That's an example of a tradeoff. So you can do the beautification of a screen in a subsequent release; not necessarily the first release, because you want to drive out that first release quickly and drive that first level of success. Well when you look at it from our perspective, we've developed an iterative methodology to do this. And this is common knowledge in the BPM world, is that the waterfall approaches just don't work. The approach of gathering lots and lots of requirements and huge amounts of documentation, and then passing it to a team to do a design, and then disappearing while you code, and then 18 months later returning to the business with the solution, that's just not feasible in today's world. By the time you return in 18 months, the business needs have already changed, the process has already changed, and the business, you're just missing the mark once again and delivering the things that IT has always delivered. So understanding that you need a highly iterative process, one that is measured in weeks not months, I think is one of the key solutions to all of that, to really effectively having that first habit be successful. Iterations over multiple iterations, multiple times over several weeks, continually engaging the business, is very, very important. 

 

Generally when we view our projects, we tend to operate on a three or four iteration cycle. And part of the argument is that we want to down scope the work we're doing, just as if was in a 90-day window. And not to say we never do projects larger than 90 days. We do. But if it's more than 90 days, we start to question whether or not we're trying to do too much in the first cut. So peel an onion one layer at a time, don't try to peel it all at once, is the key message here. The next key habit for BPM success is really making BPM about productivity and visibility. Metrics, KPIs, SLAs should be part of the defined phase of that initial phase. Don't scope them out. In my projects, I tend to look at that within the first week, and I challenge the business and the organization to define what those metrics, KPIs and SLAs are. Because if I can't define what they are, I can't make it better. If you don't measure it, you can't improve it. So that's a key point is don't scope out those metrics. And those are great checkpoints, because I could use those same metrics, KPIs and SLAs later and ask the question, am I collecting them; am I tracking this; do I know this; can I measure that? And if the answer is no in my process, then I know my process is incomplete. And this is a mistake that I see a lot of organizations do. They put reporting, metrics, SLAs and KPIs at the end of the project, when in reality it needs to be in the very beginning. So that's another key habit; that's a habit function. 

 

Well when you look at what kind of processes or kind of how our customers are using our BPM solutions, they really divide up into fairly two even camps. We have visibility processes, which are cross-functional, event-based, inter-organizational; sometimes referred to as business activity monitoring. They're finding out what happened, when did it happen, who did it, and how long- how many times did we do that, and whether or not we can do that again in a repeatable phase and fashion. And the other is an automation or a workflow condition, and that's where you've got a series of steps that need to be repeated over and over and over, until you want to bring some kind of automation or control. Those are probably the most two common ways, and everything else is some derivative of these two key points. Successful officers [ph?] not only think about automation and orchestration, but the opportunities to drive key metrics in both of those, and to bring visibility. If you look at it from a management's aspect, from a senior executive's perspective, if I could be assured through visibility that my day to day business activities are being taken care of, and I'm only escalated to or alerted to those items that are not fitting within the normal holes, then I can spin my primary function, my primary time, which is to provide leadership strategy and vision to the organization, as opposed to try to drive and complete the basic day to day activities. That's a very transformational activity when you really look at the average executive and where they spend their time. They spend far too much time chasing what we consider day to day, routine activities now, versus doing that strategy type work. 

 

The next key habit is never won and done. And what we mean by that is that we've seen a pattern with some customers that they don't really bring the rest of the necessary resources to the project. They're focused not just in driving continuous improvement. They're focused on just I have this tactical problem, I need an application that does actionally deliver that; and then they walk away. And then six months, 12 months, 18 months, what they'll find is in a BPM or process-based applications are no different than any other application. But BPM or process-based applications give you the power to do continuous improvement, and if you don't then when you walk away you-- over time that application will deviate from the business. That's just a natural thing. Your business is dynamic in nature. Your applications need to be dynamic in nature. So maintaining and factoring in continuous improvement is part of being successful in process-based applications. Building in and designing and understanding that phases two and three, or versions two or three, will always happen is important; and that's part of one of the success criterias. And making sure that your tradeoffs, you can successfully argue to the business for lower value items to be pushed off to future versions. But as long as they're not the metrics that's okay, and that gives that continuous improvement view and one of continuous change. Now we've given this graph to some of our customers who are trying to explain to their colleagues how BPM accelerates better business outcomes. And if you look at this-- when you start in a traditional IT-driven or code-based solution or application construction, you've got your first phase here, Month 0, you're doing your program initiation. And then you have out here far into the future your target range of where you want to go. That one, that's the big ERP deployment so that you see your end system or some other such big project. Well then as you proceed through and you begin to gather all the requirements and you start to make all the customizations and the code changes and what have you, with the traditional programs you have complex tooling, it's very IT centric, it's big plane deployment. And what ends up happening is over that period of time, from Month 0 to Month 60, you have this broad range of destinations that you could hit. If the star indicates the ideal destination, you may end up anywhere in that end result. And usually what ends up happening is in that last six to 12 months, there's a lot of tradeoffs to try to declare success. We've all been through those kinds of projects. But BPM gives you a different option. If you start with the same sequence, and you look at that same aspect, with that iterative, model-driven tooling you're able to establish those small stars throughout the cycle, so that you're able to adjust and adapt as the business adjusts and adapts. And that's how you get to the end result. And if you think about it, it's logical sense. If you're going to drive from Los Angeles to New York, you don't look at the map when you're in Los Angeles and say, "Good, I've got it," and then put the map away and never look at it again until you get to New York. So if you did that, there's a very good chance you wouldn't get there. So you're going to be continually checking and rechecking. And that is really where the key elements of this iterative approach is important, because it allows you to revalidate the business and to double-check. And it also gives you the ability to have faster returns. So I frequently have this conversation with key executives, "Would you prefer to get 10% of measurable business value in 30 days, versus 40% of measurable business value in a year?" Well they always answer with the 10% today. And that's part of how you're able to do this. If you're able to push out in that first six months your first version of the product, and you're able to, even if it's in a rudimentary form, collect 10% of the business value of that overall improvement, that's money in the pocket of the business, and that helps justify your next part of the solution; and that's how you get to the funding models to pay for iterative development. 

 

That kind of leads us next to Habit Number Four. And I want to really stress this one. This is one of the ones that's my personal favorites, is don't skip process analysis. Requirements documents are not process analysis. Creating Visio diagrams documenting what was is not process analysis. Don't overdo your requirements. You need to do a reasonable amount in that initial phase, but not too much either. But you really need to do true process analysis. And true process analysis not only documents what is, but starts to ask the question why? A classic example is if you look at some of the older brick and mortar companies that used to have multi-port forums, you'll frequently find an organization such as that, that the gold copy goes to Room 128, and there's a process engineer, and you chase that down and you ask the question what do they do with the gold copy? And they receive these big stacks of gold copies of whatever they are, order forms or whatever, and for years this organization has been collecting those. They take them, stick them in a folder and put it in a file cabinet. You ask the people in that room why they do that, and they say, "Well that's what we've always done." It seems like a silly example. I still see that stuff today. But there's more and more of that in your organization than you think. When you start to ask the question why, what you'll tend to find is you'll tend to find that multiple units or groups tend to overlap one another. They don't quite understand what your organization or your part of the organization does, or doesn't do, and so they'll create their own process-- there's an organic nature of process-- because the systems won't necessarily support them. You'll start to see this duplicity and duplication throughout the organization, and only through proper detailed process analysis would you see that. 

The next habit I'm going to talk about is taking time to deliver value, is Habit Number Five. As I said, projects longer than 90 days aren't a failure, but I would question them. When I see a project that's 120 days, 180 days, 200 days, and those projects fall under me, I start asking really tough questions. I start asking why do we have to have it that way? Is there anything that we can downscope or outscope for that cycle? Can't we cut an earlier version sooner? Because the longer the time you go from the point at which you gathered the data and did that initial process analysis and documentation phase, to when you deploy, the higher the probability that there's going to be change. There will be change, and there's deviation. The question is how big is the deviation? Self-sufficiency-- in other words, learning how to do this yourself, whether you're using a chosen partner like IBM or somebody else-- is important. But that can impact your project times. That's an example of why you can go to 110 or 120-day project lengths, and it's acceptable because the answer back to me would be, "Boss, here's the duration of the project, but also we're being expert mentored or being coached and trained through this exercise so we can do it ourselves." That's a really great answer to why it's taking longer than 90 days. And timelines can be dependent upon the sophistication of the process. And as a general statement, but specifically I would still ask, "Is there a possibility to subdivide the process? Can we break it down into smaller pieces?" Sometimes you can't, and I've had projects that have run longer. But generally I want to see those projects stick right around the 90-day window. That also forces an interesting conundrum. Because everybody's under pressure to deliver in 90 days, it really crystallizes the entire team's focus. They truly focus on business value, and any conversations of whether this needs to be a 3D button or a radio button are tossed out because there's no time to make that argument. You're really focused on well just let's put a button up there now and we'll figure it out later. That's the kind of thinking that you want when you're doing process improvement because until you put it in the hands of the person who's consuming it, you don't really know the answer. 

So now we've talked about the initial five habits were really focused on how to get a successful project out of the door. The next part that we're going to talk about is what it takes to transition your organizations to that next level, to-- what did I call that?-- enterprise thinking, to see how you can leverage that success to have broader impacts in your business. The first part of that is understanding your team. Probably the most common mistake I see organizations make around BPM and process-based applications is they staff it with technologists. And while technologists have an important part, they're not all unique. You have to have the interaction with the business, and if the business sponsors and owners are not actively participating on at least a weekly basis in the project, then you have a high degree of failure, probability of failure, with this project. You have to have that right mix of resources. It's understanding that the best coder in the world is not a process analyst, and the best process analyst in the world doesn't code. It's understanding and identifying a little talent pool for developers. An example, frequently we ask the question, "IBM, what do you guys look for in your process developers?" And ironically enough, most of our process developers are not computer science majors, they're industrial engineer majors; and that's a pattern that we've looked for. Because they approach the problem set differently. They understand the sequential and task-oriented nature of process, and they can think in that way. Coding is the easy part; the configuration and building with our tool set that enables you to do this, that's actually the easy part. The hard part is how you think through the problem and understand how to approach the problem. So I've seen really, really good coders not be successful, and I've seen people you would not consider in the top talent pool for a coder be wildly successful at this. And it really has to do with that mentality. If you look at breaking down what does a traditional project look like? So now if I was to create a project, I think part of it has to do with understanding the differences in the roles. 

I'm going to focus on three key roles here. I’m going to talk about that BPM analyst; I'm going to talk about the BPM developer and the technical consultant. These are kind of generic terms. But the analyst-- we already talked about the importance of process analysis. But having good analysis skills are critical. Some companies will just take people who used to be system analysts and put them in this role, buy them a requirement box.  That doesn't make them business process analysts. That's just not a good fit, because they're not really thinking about what the work is being done, they're just documenting a series of events. So having someone who really wants to have those face to face conversations around an end to end process, and understanding how to ask the questions of key metrics that drive that process is critical. And that's really the function of a business process analyst. What I'm referring to as a business process developer here is someone who's kind of like the starting line between understanding what the business imperatives are to the process, and assembling the components of an application. That includes the screens and the basic integration phase. 

A technical consultant really is-- to me-- is someone who connects your process execution engine to things outside of it, like your backend systems, your ERP systems or your HR systems or manufacturing systems, whatever they are. And each one of these roles have their own importance. If you look at a typical project, you're going to see probably 10% of the time is spent doing the analysis, the vast majority of the time doing your VPM developer, and then probably another 15 to 20% of your time doing technical consultants. And the only person who would actually write in a code here would be the TC, the technical consultant. Because frequently they're having to make complex and unique hand-coded or created integration points. So that's an interesting perspective. If you think about what I just said, the vast majority of the work has nothing to do with coding, it has to do with leveraging the technology and assembling the components. It's very important too, when you look at it from a project perspective. 

 

And then you have supporting roles I think that you're all quite aware of, the database administrator who's going to help us create gain and understand access to the database; that we're going to create a data model that we're going to create, but also the supporting systems around it. An integration or Java developer who is going to support your TC; they're going to create Web services into your backend or older systems. Your infrastructure administration, your process owners or process users; and those are the two points I want to highlight for just a second before I move on to this. Those process owners and process users need to be actively engaged. They want to stay engaged throughout the development cycle. Companies that do that are companies that have the highest degree of success above anybody else. Companies that don't do that have about a 50/50 chance of whether the project will ever be successful. Sometimes they are, but more often than not they're not. 

Let's go to Habit Number Seven on your enterprise journey. It's making self-sufficiency a priority. While I like to boast about my resources' capabilities and their expertise and their skill-- they're really, really smart folks and they can really help you through this journey-- at the end of the day you know more about your business than anyone else. I will never be able to learn as much about your business as you already know. And so the best way for you to be successful, and the best way for your projects to be highly value-driven, is going to be when you do them yourself. So setting yourself on a pattern or a path, to understand that and to build that capability, is really, really important. If you think about it, it means that you have to take responsibility for the thing. So it means you have to eventually say, "I'm going to make the investment." That means you can't turn that over to somebody else, even like myself. Even though I'd love you to, at the end of the day the best way is for you to be self-sufficient. It also means that you don't allocate partial human beings to the project. You can't have somebody who's 20% of the project. They're either in or they're out. Make sure that you have the right skill sets, as I described before, and don't mix self-sufficiency with tight deadlines because it doesn't work. So self-sufficiency should be a goal, and it should be planned and it should be scheduled as far as your activities, and should be funded as such. So frequently you don't focus on self-sufficiency for your first project. You need that first project to be a big win. So get the expertise and assistance to make that big win. And then Project Two, and Project Three, get assistance. Blend teams with your chosen vendor, your expert assistants. Help them and then they'll help you understand how to do this and learn yourself, and then over time you'll eventually take over it all. But part of that is education. And education is not experience. Education is just that, it's education, and part of that education needs to be that you take the time and effort to invest in education; that you have a vendor or a partner that understands there are different roles with different skill sets, and it's not just about the product set that you're going to use. Part of it is learning how to do that.  And that means that you have to have education that's role oriented, not a one-size fits all; not a webinar or a download and click, here learn a tutorial. It isn't about learning how to use the product. It's learning how to do what needs to get done, and how the product supports that. It also means that I'm doing testing and training as necessary; that just as we didn't go to school and stop learning once we got out of school, education in this kind of space is the same way, it needs to be continual. That doesn't mean you need to take a class every month, but it means that you need to sit down and look at the development of each individual, and you need to understand where they realistically are on the maturity cycle and maturity path, and plan their education and mentoring as that. That means a combination of actual classes. That means expert mentoring. That means experience working on projects. And you move people around on different projects so that you can gain the experience and get a multiplier effect. Those are the critical elements. Because that's what drives you into leveraging across this enterprise. Once you've got awareness at these levels, once you've got these base levels of maturity that I'm talking about, once you understand these critical elements to being successful, not only at a project level and growing your team's competency, you can now start to leverage this across your enterprise. Customers who have made this investment, and who have had those BP successes, have grown their team. And that's how they get their CIO, and even their CEO, to raise the level of awareness of BPM and process improvement within their organizations. 

That drives us to the next habit, which is fund the value, not your release. What I mean by that is there's lots of things that you can do. And the example I gave before about whether a button should be a button or a radio button, or whether it should be green or blue, those seem like silly examples. But I've been in meetings before where people have had those arguments. Those are not value-driven elements. Those don't add any additional value, whether the button is one color or the other, or whether or not there's pretty pictures on the screen. That's not fundamentally what the person is doing. So focusing on what the person is doing within the process, and what is it necessary for the person to do, that is a value aspect, and having those items, those first and most critical elements first to be developed, drives you to continue this improvement. You can add those additional elements later, and as the business changes, as they-- when, and this is a pattern that I've seen consistently as organizations deploy their first version of a process, you get a lot of statements like, well I know that's what I said, but that's not what I meant, and, now that I see the way this is working, I understand it better, and man, we could really use this little change, or that little change. Now do you want to know that at 90 days, or do you want to know that at two years? At 90 days, it's a minor correction that takes 20 minutes. At two years, it's a major correction that takes four months of additional development. This is what we're talking about when we're saying, keep the focus on value. BPM should be programmatic in nature, it should be one that has a continuous improvement and you understand that the project isn't done, just because you deployed it, that's just the first stage. And your funding models should reflect that as well. When you're looking at BPM, because, again, BPM is business process management, it's not a technology, it's a discipline. Part of what you need to look at is, where am I going to get these opportunities and how am I going to leverage these things to grow the organization? Part of it is tying it to your corporate strategy. So every year, every organization goes through their business planning and they come up with their corporate initiatives for the year. That should drive you into, how is that affecting my organization, what is the process impact to merge with company X, or develop the one year movie, or build a commodity hub? How does that impact my entire organization? And that's where you would drive into each one of these process analysis areas. That is where you're going to find the value proposition, that's where you're going to get the organizational shareholders, that's where you're going to identify the key systems, the KPIs, the key error states, that process priority. It's also going to allow you to develop the high level business cases and determine which area you need to invest in and which area you shouldn't, and that's going to drive your process roles and your team members, your integration point, and it's also going to help you develop your cost bump as you proceed forward, and you really start to build those <inaudible> concepts and subsequently decide which ones are the best, that's how you build your executable process, and build your deployment, so understanding the linkages between those, if you can't trace back what you're doing to a corporate initiative, it's probably working on things that are not necessarily of high value. Let me give you a different look at this. I have another customer, who, they knew that they were a shared service from the get go, their organization, their BPM group started in a shared service, so it's one of the things that they do is, they go out and advocate to different lines of business. And they say and listen, that they can help to drive customer value, and we can help you drive this effectiveness in the operational efficiency and the service efficiency in each one of your different areas. And so that's what they're asking their end user customers, or their lines of business, how can we apply this in your particular area? They get a lot of feedback, and that's also where they get their key opportunities. It's interesting that it tends not to always be always the same organization, it tends not to be the organization that's always driving the biggest success, at a given moment, it's usually the organization that success is struggling, that they're going to get their first investment areas, because that organization is looking for a way to drive down the costs or increase their productivity, or whatever it happens to be, whatever the area is. Now when they go through all of this exercise, they get into this, what they call the productivity target areas, and then they drive into a prioritization matrix, and that allows them to calculate, based upon their particular approach, you know, a score card that helps them drive their ROI for each project, and that's how they prioritize. Another interesting point is, they look at the group which they're working with in that line of business, and that they look at what organization-- what is your organizational ability to accept change? How willing are they to adopt these modified processes? If this group doesn't accept change very well, knows nothing about their processes, completely unaware of this in reality, they factor that into the prioritization, because an organization has to have some baseline education before they can adapt to a process based application.

 

That kind of drives us into something, a theme you've heard me, over and over and over, I've made references to the business over again and again, and including the business as a critical element, and that's really what I'm referring to in Habit Nine. You know, Four C collaboration. Consider your first project carefully, and consider your collaboration. Co-locate your team members, mix them together, leverage playback, so that's like, one week or two week iterations you play back to the business, what's happening, where you're at, what you’ve accomplished since you last talked. You know, drive this kind of collaboration on a consistent basis, because that also drives adoption, it lowers your testing and user acceptance cycles, it fine tunes your development effort and keeps you focused on those items that are truly oriented toward business values. Without that, when you disconnect those points, and you let the business go about its business, and the IT goes about its business, you'll lose that focus. Inevitably you come back to that. I know that's what I said, that's not what I meant. How many organizations I've been into where the argument has been, well that's what the requirements document said, and that's what we delivered, is IT's perspective, but the business says, I don't care, it won't do the job. And we've all sat in those kinds of meetings, and those are really not productive. Let me give you an example. I mean, here's an actual picture from a customer, one of our customers. A large distributor in pharmaceutical industry. In this room, all of those people sitting at the table are actually the business users. The IT folks are in the back. The person that's conducting the playback and walking the people through the application is the lead business sponsor. Quite a different focus. It's very interesting when the business is the one that is actually driving these playbacks and walk throughs, as opposed to technologists. They're explaining to their colleagues, to their peers their report-tos, how this works and its importance. It's very, very interesting to me as an observer, to sit in the back and to see the excitement that generates and has driven from that, and how quickly organizations that seemingly seem to be completely resistant to change, do a completely 180 in a very short period of time, and become very adaptable to change, just because they feel like they're involved in the process. It feels like their voice is being heard, and that when they ask for something, that change is introduced and it's done in a reasonable timeframe. That drives us to the next point, which is, who's supposed to be in that room, right? It's the owners. It's establishing who the process owners are. Now anybody who's involved in IT on the call, I apologize, I don't mean to offend, but nobody in IT is a process owner unless it's an IT process.

 

Processes are business oriented, they're owned by the business. Whether you want to admit it or not, you cannot have an independent third party managing and owning a business process. Unless they're actively involved in that work, they can't do it, because they're not involved in it. Remember, Business Process Management is a discipline, and it's a program, it's a discipline. Biotechnology-- [ph?] business process management systems are technologies that help enable that discipline. So approaching that from that perspective really helps you understand why it's so important to have the business involved throughout the cycle, and having the business engaged throughout the cycle, to directly impact the changes and the development direction is so critical. All right, so we're coming up on the last point. Seems pretty obvious, but market your work. Create internal communication about your progress, create videos, Wikis, portals, to show off your process, and remember, BPMS is enabling technology, it is not BPM, so having quotes from the business users, from the business owners, having them participate directly in and part of that overall announcement is ongoing throughout the cycle is very, very important. That derives buzz, buzz drives interest, interest drives further work, which builds your team, builds your collaboration and moves you up the maturity chain. At the end of the day, in order to go from wherever you're at, to a highly efficient, highly effective process driven organization, that's only going to happen with experience, and experience comes with building more projects, deploying more processes, learning, making mistakes, adapting from those mistakes, cycling that for the next iteration. So part of what you need to do is really to market your work internally, to be successful.

 

So to recap, as I said, the key habits, improve your business value first, it's all part of making your projects and your project delivery successful. Make BPM about productivity and visibility, don't separate the two, never create the one and done syndrome. Don't make one version of a process and deploy it, and then don't change it ever again. You need to build in continuous improvement in all your projects. Don't skip your process analysis, it's a critical function and if you don't do it right the first time, you're going to end up doing it the second time. But you will do process analysis, whether you do it at the beginning, or whether you do it when you cut version two, that's the question. Take time to deliver to value. Focus on value driven development.

 

Challenge everybody, including the business, of why you have to do something, on a continual basis, why are we doing this? What value does it have? And if you can't identify the value, don't do it. That drives you into the next habit, which is how you grow your competency? Now build a key complete team, and understand self sufficiency and experience are two different things, but make self sufficiency a part of your priority and factor for your projects, don't put short duration projects with self sufficiency goals on them, they won't because successful. And lastly, how you leverage across your organization, is you fund to value, not your first release. You're focused on a return to the business and you release multiple releases to get to that return, over a period of time. You really need to focus on forcing collaboration between business and IT. Don't let them separate. Don't let them be miles apart. Put them in a room together. Co-locate them if you have to. Do whatever you have to do to make sure these people interact on a continual basis. Finally, establishing the owners and understand that the owners cannot come from IT. They're going to be in the business and the business needs to take responsibility and ownership of the process, and at the end of the day, they're the ones that need to tell you how to make the changes, if it needs to be go left or go right, they need to accept the responsibility and the ownership for that decision. And lastly, market your work internally. Beat the drum, tell everybody about your successes and equally important, your failures, because that's going to bring not only credibility to you and your team, but it's also going to show people how this maturity is happening and how you're growing in capability over time. All right, so I'm going to open it up for questions at this time. I'm looking for the first question here, hang on a sec. Project exceeds 90 day, and the project is due in 90 days, what happens to such a project?

 

Ben Eadie: Project exceeds 90 day, and the project is due in 90 days, what happens to such a project?

 

Bruce Partlow: Well, I mean, regardless of whether you're using process technology, it sounds like you have a challenge with your project. You need to focus, in that kind of a case, you need to focus on the scope that you're looking at. I don't think that's unique to a process application. I'm not sure if I answered the question, or understood the question. If that person could maybe expand a little bit on their question, I'd appreciate that. Can you speak to the need for continuing training of experienced long time workers? Yes, you know, that's one of the points that I pointed out in earlier slides. Education is an ongoing event. I'll try to go back in the slide deck here. It shouldn't be, you know, just product training. It needs to be an ongoing aspect, and understand that, even with education, access to experts and having expert assistance periodically is important. You know, when you're dealing with experts, you know, like, my field people, they're out seeing lots of different customers. They're seeing patterns of problems, but they're also learning new and inventive ways to handle those. So don't deprive yourself to the access to that kind of expertise, so yeah, in my opinion, training doesn't stop after a certain number of years, it's an ongoing and continual aspect. There's always going to be new ways of doing things, I've learned, I mean, in the last five years, nearly continually, new and improved ways to handle process issues. Can a business analyst make-- the question that Lorrie [ph?] asks, in my opinion, can a business analyst make the transformation to business process analyst? It's very dependent upon the analyst. The answer to your question, I think yes. The danger sometimes, is that that analyst is very attached to a segment of the business. You know, think of it in the terms, if you use an insurance example, maybe that person has been on the claims processing side and not the annuities processing side of the business. They really, really understand claims processing, though, and nothing about annuities processing. If they get stuck in that mentality, if that's their whole focus, if they're much more, what I would call, industry aligned, or unit aligned, then that becomes a challenge. If that's not, if they've got good basic analysis skills, and go get some process analysis training, they can make the conversion, and I actually have converted by a few people like that. But again, it's very dependent upon the analysts themselves. Okay, let me go to the next question.

 

Ben Eadie: I see right now here, I'm going to read off two questions for you, and then we'll continue on, on that one that you led there, just so that we don't miss anybody. So Tracy [ph?] is asking, how does BPM differ from agile methodology?

 

Bruce Partlow: Well, BPM is a methodology, as a management discipline, and has nit to do with a development event. If you're asking the question, do we recommend that your BPMS-based projects follow an agile approach, I would say the answer is yes. But it's a modified agile, because some of the events in agile don't quite necessarily align to a process based application. So even in our case, we have a slight modification. But they generally follow the same basic patterns.

 

Ben Eadie: Cool, and then the next question is, N-O-M-I-C, or Nomic, in an initiative driven BPM environment, how do you justify the time taken on delivering value, when the value is one team's or person's perception of the ultimate success of the initiative?

 

Bruce Partlow: Because the value wouldn't be one team or perspective. I mean, it's going to be coming out of the business. If you can't associate an improvement to the business-- well let me back up. So there's-- are there foundational projects on occasion? Sure. I would not put those as my key first projects. So you know, building big stacks of integration points and background, just for the giggles of doing it, they are going to consume in the future is something that would be required at some point, but would that be my first project? No, that would not be my first project. In fact I wouldn't build any integrations in advance of the process they would consume. The process that would consume them would be based upon a business value. If I can't identify a business value that I'm going to improve, I'm going to reduce the cycle times for something, I'm going to improve customer satisfaction, I'm going to reduce the cost per claim, I'm going to improve my order to cast cycle, whatever, if I can't identify some kind of measurements, and some kind of value equations, and it may or may not be money, but if I can't identify that, then I don't have no business doing it.

 

Ben Eadie: Cool, so we'll just continue reading these. This seems to work fairly well. So do you recommend any websites or specific training for an analyst?

 

Bruce Partlow: Good question. I think you've got-- there's a lot of Six Sigma training out there that you could use as a good basis to start with. They really depend upon what kind of analyst-- process analyst you want to become, a lot of our process analysts have gone off and got Six Sigma basic training to start with, as a-- you know, those are just frameworks to approach process analysis. It's just being passionate about process improvement, and understand there's multiple frameworks. There isn't a one size fits all kind of approach, but just looking at all the different kind of models, that really empowers the analyst to be most effective, because when you see the process pattern that appears, you can apply the framework that best fits.

 

Ben Eadie: Yeah, and Ankur  asks, how do we make sure the business mingles well with IT? A lot of times we face an issue where business never wants to sit with IT, and hence, most of the things are done only through e-mails or documentation.

 

Bruce Partlow: Yes, very good, very good problem. Yes, common problem. Part of it has to do is, you just have to force it from a leadership standpoint, and that doesn't mean that you mix all members of the business, nor do you mix all members of IT. The realistic perspective is, some of my best coders are not necessarily the most personable people, so I have to look at that when I construct the team, and that's the person I wouldn't necessarily put in day one, project one. So I'm going to pick from both sides, from the business and from IT, working with my business sponsor, to create a team that's going to give us the best opportunity for collaboration. That's the team that I'm going to start the next, and that's the team that I'm going to start the project, and it's interesting, because when I do that, inevitably what happens is, the both sides, the people that are left out of the group, become more interested as they start to see the success, and particularly if you've got a wild success on the first one, that resistance to working together in the future, dissipates. But I also would admit, I mean, let's be honest, folks from IT, we've created this problem, right? For the last 30, 40 years in the business, particularly in development efforts, we've created a very contentious relationship with the business, and the business feels they have to ask for 200 things, even though they only need 100, in hopes that they get 60. Now we can argue why it's that way, we can argue whether it's a lack of our technology, or whatever, but we've created that problem. We've got to come more to the business, because the business, ultimately is one that pays all our paychecks.

 

Ben Eadie: Very good. So when you're communicating during the 90 days with a client, do you use mock ups to show them what the screen may look like?

 

Bruce Partlow: Well we do better than mockups, we actually do playbacks. In our technology, we have the ability to do playbacks within minutes. So we draw out the process, and we start inserting the base screens at that moment. And sometimes at the very earliest stages, a screen will have nothing more than just a description that says, this is the screen in which you're going to collect the customer data. And then in three to four days, as we go continue to refine the process, we'll go back to that screen and we'll start to put some basic fields, and it will say, first name, last name, middle initial, address, basic-- and basic stuff. We're just going to throw them on the screen in a somewhat reasonable order, but we're not worried about the beautification of it at that point. And that's how we have the continual, as I say, playback, that interaction with the business, so that they can visually see in their mind, how they would be using it.

 

Ben Eadie: And she's asking what technology you use for this as well?

 

Bruce Partlow: WebSphere Lombardi Edition.

 

Ben Eadie: Okay. Let's see, and how do you manage BPM when there are multiple owners or partners who do not agree on the process?

 

Bruce Partlow: There's really never multiple owners of a process. If you are at an enterprise level, there are multiple process owners that connect to an overall process, but there's never multiple owners of a process. It just-- you just need to-- if you've got a condition like that, you need to subdivide further. You're not in enough detail yet of the process to identify who owns which piece.

 

Ben Eadie: Okay, so next we have, from Ted, multiple releases is a challenge in industry where systems require validation. Can your model be adapted for smaller iterations over a long term development project?

 

Bruce Partlow: Yeah, that's what our preference is. I like to see one to two week iteration drops every cycle. Is that what you're asking, or are you asking for longer iterations?

 

Ben Eadie: I believe that's what he was asking. I'll just ask Ted to clarify here in a second, and when that comes up, we'll step back into that. But we'll go on to the next question, because we've got about five minutes left here. So if you've got a project slated for 90 days, and along the line, you now discover that such a project will exceed 90 days due to the volume of the project, what do you think will happen to such a project in your opinion?

 

Bruce Partlow: You need to downscale.

 

Ben Eadie: Well that was succinct. Okay, what additional areas of training will make for successful BPM analysis?

 

Bruce Partlow: I think we covered this one already. I mean, learning about various process models, and process analysis techniques. One of the ones I tend to frequently suggest to start with would be Six Sigma training, as a good place to start.

 

Ben Eadie: Right. Yeah, and then again we have another thing on education as well, and then that would be Six Sigma and everything you've mentioned before. So what are some of the key questions a BPM analyst or a BA should be asking during the process analyst exercise, or analysis exercise, excuse me.

 

Bruce Partlow: The most common is, and then what happens? So the conversation starts with, okay, so this is what you're doing. Great, I'm looking at role one, and then what happens? And then what do you do? That's a very common one. The next one is, we'll ask questions like, what information do you need to do your job? What decision are you making at this point, who needs to know this? What information do you know at this stage? I think part of the challenge is that people look at the end state screen that has all the information, and they forget that it took 50 people and 100 steps to get to that stage, so you want to decompose that end screen, end state screen back to collect the one or two pieces of data from each person along the sequence, so that's part of what we're looking for.

 

Ben Eadie: So should a BPM analyst identify the existing process, working with the stakeholders, identify key failures in the process, model the improved process and get the key stakeholders to sign off, and then use agile implementation to recommend changes of IT improvements, or is that suggested or recommended?

 

Bruce Partlow: Yeah, that's exactly what I was talking about earlier, when I said, by iterative development. That's exactly the definition phase, moving right into it. The only caveat I tell you is the process users don't sign off on it and then leave, they sign off on it and participate throughout the <inaudible> that's the only correction I'd say to that.

 

Ben Eadie: Right. Let's see, what literature do you refer to business analysts who want to start a business analyst business process, and what about BPMN?

 

Bruce Partlow: Well we support BPMN in our technologies, and that is the preferred modeling method that we use. As far as literature, there's tons of literature on the internet, there's lots of different books. I particularly like one called, Competing On Analytics, and I'm trying to remember who the author is, I don't-- you need to look it up. It's called Competing On Analytics. Oh, here it is, I've got it right here. By Thomas Davenport, it's less process analysis, but it really shows you how analytics impact all of our life, and if we're not measuring things, we're probably not paying that much attention.

 

Ben Eadie: Right, right. So as a BA, how do you solve a multiphase project versus a single phase project if the timeline exceeds six months and no scrum-- oh, it just popped up on me-- and no scrum methodology is in place?

 

Bruce Partlow: You focus on the value of what you're trying to correct. You know, why are we doing the project? What is the value that we're doing, and if you don't have that measurement then it doesn't matter whether it's 90 days or two years, you haven't identified the project yet. So you need the additional work to understand the document and get concurrence of the values, very, very important.

 

Ben Eadie: How does the BPM process allow for prioritization of the failures?

 

Bruce Partlow: Right, prioritization of failures and problem statements don't necessarily become the priorities. Those are not necessarily the areas, because in some cases, I can engineer out whole hosts of them. While they're important as far as the decision making aspect, I look at those areas of challenge, I don't necessarily let them to be the driver. The real value that I want to look at is, I want to look at what value I'm going to drive. So as I'm building a process, I may look at the happy path and the primary path of that, and I may look at the first exception and ignore the rest to begin with, understanding that all that work is going to continue to be manual for a period of time, and that's okay. So a lot of the <inaudible> will be existing in the stuff that I didn't do. But again, thinking of life as a continuous improvement and a long term view, I'm going to focus on those key areas first, and gain control and visibility of those first, then add, based upon which is the highest priority elements in the next iterations.

 

Ben Eadie: Cool, so we've got three more questions and then we'll tie this webinar up. So what, other than gap analysis can we do for process analysis?

 

Bruce Partlow: Well there's lots. You could look at, what we talked about just now, as the problem statements, you can be value driven. There's lots of different analysis that you can do.

 

Ben Eadie: Okay. Could you send a list of the books you just mentioned and the PowerPoint after the webinar? So everybody knows, the webinar, along with the slides will be archived at modernanalyst.com. Just go there, look at the webinar tab, and you'll be able to find everything you need, for everybody that is still listening. And the last question is, what gets into the queue first? You answered this already, the stakeholders do. But there needs to be a system for which they should do this. Agile provides this within its methodology.

 

Bruce Partlow: Which queue are you referring to? Tracy, could you elaborate on that a little bit more?

 

Ben Eadie: She says, when there are failures in the process.

 

Bruce Partlow: Okay, all right, now I understand the question. Well, again, the value points of what the process is supposed to do, and what you're trying to do with them, the process application is what gets in there first. Failures within the process, while they're important to look at, and they certainly have weight in the process and prioritization. They're not the primary function, unless, of course, that's what your primarily doing in the project, but most of the time that's not the case. Most of the time, the failures are caused by the lack of supporting systems to properly recognize the true nature of the business process. The people are people, they will adapt to what tools are given. And they'll create processes that go around those tools to accomplish their work, because that's what they've got to do. So discovering that true process is the first priority. Secondarily after that, once you've discovered the true nature of the process and you've got true visibility, then you're going to go back and look at what you currently think are problems. I think, in most cases, the vast majority of those goes away. Not all, but some. And then that helps you drive, based upon which is the most important value issue. Do I work on that problem that the one guy or gal has in the shipping department, or do I make the change in finance that affects 40 people? Which one of those do I do first? Well I'm going to do the latter, not the former. So again, that's what I refer to as value driven. You constantly ask the question, which is more important, the thing I'm about to do or something else?

 

Ben Eadie: Excellent, well thank you, Bruce, and IBM for a very informative presentation. Thank you everyone for attending today's Modern Analyst Webinar. I wanted to point out, the webinar along with all its slides will be archived at modernanalyst.com within a few days. And this concludes today's event, and we hope you have a great day.

 

Bruce Partlow: Thank you, everybody.