Nobody really cares about standards… until suddenly they do. When a standard reaches some threshold of adoption, a tipping point is reached. Then, if you’re not on the standard you’re proprietary....

Business Process Management - Time for Change

In my previous article, “The Design phase”, I discussed the concept of designing the change from the current way the process operates to the improved way with very few constraints. Does this mean that you can do without rigorous deployment planning? No, but you need to separate the discussions: First focus on what needs to be done. What type of changes need to be made, what type of skills do I need on my projects to make those changes, and what changes are dependent on each other: understand the possibilities. The final phase of a BPM project is to get ready for launching these projects you defined in the Design phase. You are about to deploy your change programs. You just need to make sure to get them prioritized and funded. This article addresses this final stage before you deploy your changes: the Deployment Planning. In Deployment Planning I will introduce constraints on the time, budget, and other key areas of the overall plan.

Why is it important to first focus on the requirements in the Design phase before incorporating the constraints in the Deployment Planning phase? Because, constraints can cloud the discussions of what needs to be changed. E.g. “We cannot change the way we stack those boxes because we do not have equipment for that in the warehouse.” Or worse: “we will never get budget for that.” So, even though the team agreed that stacking needs to change, you would actually dismiss the recommendation because you anticipate your sponsor will not fund your recommendations? If these types of conversations or this line of thinking emerges consider this: The company invested in your project and your sponsor and stakeholders expect an outcome that addresses the area you investigated; wouldn’t it be a better idea to have them, the sponsor and stakeholders, make the decision on what can and cannot be done? Upon completion of the Design phase you should have an understanding of the future process. You have defined what needs to change and how. And you have determined the type of skills you need on the project, the type of investments that need to be made and the expected improvement. Now let’s look at availability of resources, money and expected outcome timelines and manage expectations.

Resources
Do you recognize this kind of statement: “this can’t be done, we don’t have enough people that can do that”? That’s the type of challenge you address in this phase. You have alternatives that you need to consider as part of your deployment planning: Do I make this change for all products/plants/regions at the same time? Or do I apply it to one (thus train some not all at the same time) and then roll it out to other products/plants/regions. Do I train a group that can roll out in other locations, do I bring in expertise from other parts of the business or from outside the company, or am I the only person that can do this? You may not even have a choice here. If timelines don’t permit sequential roll-outs then you need to do them in parallel. Which increases the problem of constrained resources (read: constrained skills). Some will tell you resources is just a matter of budget; this is true to a certain extend. You can augment resources with external resources, but there maybe a long learning curve.
Time
          The time constraint can be very restrictive. “You need to complete the project by such and such date”. This means your deployment plan needs to work towards a firm end-date. Targets are good; they keep us on our toes. It is your job to highlight what is part of the deployment planning to sponsor and stakeholders so they understand the choices they have: Shorter timelines, means more skills and budget on the short term. Longer timelines means budget is consumed over a longer period (i.e. fits the budget better), but also means the results to be achieved later, and the benefits more diffuse possibly.

Budget
Budget can be an absolute or time related constraint. As an absolute constraint it means that you have a limited amount of funds you can apply towards resolving the problem you are trying to solve. This may mean that you have to explain that you may be able to address 80% of the problem. The remaining 20% requires additional budget to be assigned. Time related budget constraints means that you may not have enough funding for the month or quarter and are therefore pushing the timelines out. The message will be more along the lines of: We will only achieve 80% this quarter or year. The remainder is funded by next quarter’s or next year’s budget.

How to develop the deployment plan? First collect the information of your projects that you identified in the Design phase. For each of these projects you should have already created the resource needs, budget, project activities, dependencies and impact of the change. Link this impact back to the metric you are trying to improve, not the potentially artificial thing called ROI (return on investment). Secondly collect the same information for projects not on your list that will compete for resources and budget. And finally collect information of resources, (cost of) alternative resources, and budgets for change. Put all of these in a list and sort them highest impact to lowest impact. Insert the budget cut-off in your table to understand which makes the list of projects that are funded and which will not. Don’t forget to check the interdependencies. A project above the cut-off line can not be dependent on one that is below the line. Repeat this exercise with different timeline, resource pools and budget scenarios until you find a mix that best meets the need of your business.

An example for this approach is often found in corporate IT governance organizations. They monitor and facilitate the prioritization process of IT development budget and IT assets (such as developers) to the most important IT programs. Oh, and they have a best practice you may want to consider: don’t try this alone, involve your sponsor and stakeholders in the decision-making process.
The take-aways? Recognize that you can play with duration, sequencing, budget and resources for your projects. You can stretch any one of those. But more importantly communicate the alternatives and the impact on when to expect results and how much. Involve sponsor and stakeholders in the process of creating the final plan. Like always don’t take my word for it; prove it to yourself in practice.

Caspar H. Hunsche is Managing Director and co-founder of Process Core Group (PCOR.com). He is the original author of the Customer-Chain and Design-Chain reference models. He is a practitioner, trainer and advocate of standards based process management.

About Caspar's Training Course.

Back to Articles, including BPM, SOA, BDM, BA & OP