Sigh! Process as intervention is just not sexy...

I am jealous.
I see many types of interventions that management can choose to influence people behaviour in their company...

I see great workshops focused on culture, people doing fun-games at remote locations, deep and inspired discussions on values
I see managers working on mission, vision and strategy in expensive resorts, golfvenue around the corner
I see IT-systems being designed, and delivered, forcing people to follow the screens and workflows embedded in these systems, with all kinds of cool UI-widgets
I see budgets being given or denied
I see people in fun training
I see promotions, new hero-managers, with powerfull mandate
I see jobpromotions, jobdescriptions and evaluation cycles that will actually hit people in their wallet, with big bonusses for the right behaviour

And then there is us, process consultants, proudly showing the next swimminglane model and desperately trying to find someone to take process-responsibility...

How sexy and influencial is that??????

Can anyone help this disillusioned BPM-practioner with concrete examples of process-interventions that inspired, motivated, improved, e.g. sexy?????

10 easy? questions for managing IT-change

Where various parties from business and IT collaborate in deciding on IT-change (implementing changes, based on various new or changing requirements), a complex playingfield arises.
Often, in my observation, many companies struggle, in terms of "who will need to decide what", during the preparation and delivery-phases of IT-changes. With a more fundamental understanding of the types of questions that needs to be answered and the ownership of these answers/decisions, more clarity can be created (and confusion avoided...).

I think, in essence, we have to deal with 10 easy questions. Well, easy, in terms of the answers provided, they are easy, but to answer them with confidence, based on the right information, might be quite complex....

Here are the 10 questions, that should drive your change-process (for instance your ITIL change process, or any other changeprocess, for instance in deciding and implementing change-requests for your software applications) and create a clear demand/supply relation:

Before realizing the change:
1. Do we understand and really want this change? (business)
2. Are we willing to invest to research solutions? (business)
3. Is the change really feasible, what solution-scenarios exist? (IT)
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)? (business)
5. Can we agree on a realistic start- and enddate? (Business and IT)
6. Do we commit to adequately lead the change from the business perspective? (business)
7. Are we, as IT, willing and able to commit to deliver the chosen solution? (IT)

After realizing the change:
8. Do we accept the delivered solution? (business)
9. Are we willing to implement the solution in our operations (and supporting IT-layer)? (business)
10. Are we done, happy and ready to move on? (business and IT)

I hope that during your changeprocess these questions are clearly answered by the right stakeholder!

In more detail:

1. Do we understand and really want this change?
Key owner: business (and IT to advise)
Remarks: we need to adequately understand a change-request, and assess (preliminary) if it is realistic (we want our app to make coffee, but the end of this week)...
Subquestions:
- Is the submitted change-request clear and understandable? Is the context (Why, Who) clear? Is it (preferably) mainly stated in "what" terms (business requirements), and possibly supported by (preliminary) "how" statements. Is there a "When"?
- Is the requested change (in principle) feasible? (IT advise!)
- Is the (preliminary) "When" (in principle) realistic? (IT advise!)

2. Are we willing to invest to research solutions?
Key owner: business
Remarks: only for very simple requests, we might directly see the solution and required changes in our IT-landscape. More often, IT will need to research the request, and come up with various possible solution-scenario's, that each has it's pro's/cons and consequences
Subquestions:
- Are we willing to free and assign capacity @ IT to research the requirement, and wait for some time to let them deliver? Do we accept the cost? Owner: business
- Are we, if needed, willing to deprioritize other IT-activities, to let this research be executed? Owner: business, with strong IT advise
- Are we able (as business) to further guide IT (and answers business related questions about the requested change)? (business!)
- Are we able to deliver adequate research? Do we have the resources with the right experience and knowledge available? (IT!)

3. Is the change really feasible, and what solution-scenarios exist?
Key owner: IT
Remarks: Based on the changerequest, IT needs to research: can we do this, and how (not in all detail, but in enough detail to have enough trust to answer the question and allow the business to decide the next steps). Research in terms of technical scenario's, their functional and technical impact for the business and IT and the consequences of the solutionscenario, in terms of cost, required resources, time, risks. And an assessment how the scenario fits in the architecture(plans and guidelines).
Subquestions:
- Are there technical solutions that fulfill (fully or partly) the requirements from the change? If yes, what solutions?
- For each solution:
- what are functional consequences
- what are technical consequences?
- what are consequences for future maintenance and supportability?
- does the solution fit in the current/to be architecture?
- And for each solution: how can we realize this solution, in terms of approach, cost, time, required resources? What risks?

4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)?
Key owner: business
Remarks: In the end, business needs to decide the scenario and accept consequences (to it's operations and the related change-efforts/investments)

5. Can we agree on a realistic start- and enddate?
Owner: Business AND IT
Subquestions:
- Does this fit in current plans and available resources?
- If not, can we agree on re-priotizing/delay other requests?
- Are there other solutions (in terms of sourcing)?

6. Do we commit to adequately lead the change from the business perspective?
Owner: Business
Remarks: This is a critical question. Many IT-projects suffer from ambitious business, that fails to provide clear and adequate guidance (enough support and time from critical business people) and speed of decisionmaking
Subquestion:
- Can we, as business, free the required people as leaders and subject matter experts?
- Are we willing and able to setup a good issue-resolution process, and commit to it?
- Are we willing to steer the project, take part in steering organization and make tough decisions in a timely fashion?
- Are we willing to invest in the relations and social networks between business, IT and project?
- Do we have but also feel the trust that we can work together with the people on the IT-side?

7. Are we, as IT, willing and able to commit to deliver the chosen solution?
Owner: IT
Subquestions:
- Do we have the drive, trust, knowledge, experience to deliver?
- Do we have the maturity to manage this?
- Do we feel the circiumstances are right? All critical succesfactors covered?
- Do we have but also feel the trust that we can work together with the people in the business?

8. Do we accept the delivered solution?
Owner: business
Remarks: IT has delivered now, and we have taken various actions to gather information on the solution. We checked in various tests and reviews if the solution conforms to the change-requirements(verification) and also checked if the solution will work in our operations(validation).
Subquestions:
- Does the solution comply to the requirements?
- Will the solution fit in our operations?
- Do we have sufficient information to really assess and decide on acceptance?

9. Are we willing to implement the solution in our operations (and supporting IT)?
Owner: business
Remarks: now it's time to get the IT-change in production.
Subquestions:
- Are we ready?
- Has the change been rolled out correctly?
- Acceptable risks for operations?

10. Are we done, happy and ready to move on?
Owner: business and IT
Subquestions:
- Will the business case be reached?
- Is the change correctly functioning in operations?
- Can we close the change, with full satisfaction?
- Did we learn the right lessons? Will we remember them?
- Are we still respected partners?

Five models to assess your project and stay sane

BPM, IT, and actually any type of project can sometimes be overwhelming in complexity, issues, social patterns and such. In my 17 years of projects, I have developed enough scartissue... And for the more junior-readers: yes, projects fail, including projects I was part of....
In the 17 years I also tried, every time, to learn and understand what happened in the project and why it was a failure, a challenge or a success. It lead to a large set of "sanity checklists" and other best practices. And also to quite some analysis-tools. In this post I want to share 5 easy diagrams as tools for analysis of the project you are working in (or better: about to work in). The tools deal with simple questions you can research within your project. It leads typically to 2 answers: the way it is currently, and the way it should be to be able to deliver succesfully.

Model 1:
Model 1 deals with the process or method you need to choose to deliver the projectproducts.
Two simple questions, try to answer them, map out where it lands in the diagram and then compare to the method that has been chosen for the project (hopefully it was a deliberate choice, and not the often occuring "goodwilling people, yet chaos approach").

Model 2:

Model 2 deals with the amount of ceremony in terms of process and documentation you will need. Again two simple questions.... This tool is great to work with people that either want to overstructure/overdocument when it is not required or people that want to travel very very light, when more is needed...

Model 3:
Model 3 deals with control on the content in your project (so, not on time/cost, which typically already gets enough attention). This deals with: how do we deal with uncertainty in requirements or design. I see many projects that fail to create control over these vital elements. The results are typically confusion, failing assumptions and rework...

Model 4:

Model 4 deals with leadership versus group-behaviour. I have seen projects deliver with low leadership or low groupcohesion, but the combination of these situations is typically deadly. I believe in groups and the great work that can be done by them, but only if they are willing to allign to goals and have enough social cohesion. Usually this occurs if you are working with people that have enough skills and limited ego to cooperate or a strong leader that is able to align people...

Model 5:

The last model is about you (or the people you depend on in the project, enabling you to deliver your scope of the project). I developed it when in a certain project I was very unhappy. I tried to understand why - and found that I was very involved/committed, but had no real influence, in a project which was heading for disaster. Stuck between a rock and a hard place, with only three options - get more influence (tried, no succes) or don't care anymore (not my style), or... get out. I choose the last option, with no regrets. The project failed 3 months later.
More lessons and tools welcome!

5 ways to green BPM

In all the turnmoil on the global crisis, but also the media storms on "clouds" within the BPM community, I hope there is still some space left for sustainability, people/profit/planet and environmental issues.
In my opinion, a process-focus can strengthen our ability to improve the sustainability of our business and reduce the negative environmental footprint: P4 (people, profit, planet - and process).
BPM, as a framework for seeing your company through the lense of process, aims at understanding, measuring and improving your processes. While the traditional focus for BPM is things as cycle-time, cost, customer value/service, environmental aspects can be easily incorporated in the BPM approach.

I suggest 5 possible ways to use BPM in greening your processes and business:

1. Analyse - Measure - Select
As part of most BPM efforts current processes are modelled/documented and measured. This provides important insight to know where improvement-areas are. For sustainability we should be able to come up with "GPI's" (thanks to my collegueas for this term) - green performance indicators. Measurements based on these GPI's can give a company insight in their processes: which processes (and even which steps in these processes) have a large environmental footprint.
You can use this information to define an actionplan, and select the processes where the "biggest bang" can be reached. The starting-measurements can later be used to compare to improvement-results. And you might even want to decide to incorporate periodical measurements of your "GPI's" in your Green Balanced Score Card.
As a sidenote: measurement can also support benchmarking, which could help entire industries (why do we need 10 kg of paper in processing 100 insurance-policies, while our competitors can do with 1 kg?)
As part of the process-analysis, the company could attempt to find aspects of the processes, thay may drive environmental footprint - for instance: is there a lot of paper used, a lot of km's traveled, a lot of interaction between various locations/people to execute this process?

After step 1, a number of other steps can be taken:
- Optimize
- Recycle
- Innovate/Re-engineer
- Synergize

2. Optimize
Using techniques from Lean and Six Sigma, various Green optimizations can probably be found. The 7 Waste approach could for instance identify unneeded transport (CO2!). The Six Sigma Root-cause analysis could help identify unwanted environmental effects and their causes.
All these results can be used to gradually improve the process
Case: by stepwise improvements paper-production companies are lowering the amount of water needed, and reduce the water-pollution
Case: a company allowed people to work from home on certain days, using a PC, which reduced CO2 / transport

3. Recycle
It might be possible to recycle materials used as input or output (either process-products, or supporting material). In many industries bottles, glas, paper, etc. is being recycled.
Case: diary factory sells milk in bottles, which are being returned by customers for reuse

4. Innovate/Re-engineer
Taking the BPR approach, one might be able to totally reengineer the process, so that a radical better environmental effect can be used. In some radical cases, the process might not even be needed anymore
Case: various companies re-engineered their invoice-processes, making them all digital instead of paper. Paper and transport went down considerably.

5. Synergize
By closely looking at your process (inputs, outputs) and other processes (within you company or outside), it might be possible to identify ways to create environmental synergy.
Case: an IT-company located their datacenter in a greenhouse-area. The heat of the datacenter is used to warm the greenhouses.
Case: a Shrimp-farm located their farm next to a large energyfactor, the emitted heated water is used to warm the shrimp-bassins.

One might think that these steps can only be applied to production-industry. But....
In many administrative factories, processes consume large amounts of paper, storage and transport of paper, and transport of people for meetings. The 5 items above, combined with BPM technology, supported by ECM and Collaborative tools (videoconferences) can deliver great green effects (and hard Euro/Dollar-savings!).

Cases and Ideas welcome!

A day in the life of a processconsultant

I am currently in the luxerious but also difficult position of a processconsultant in a quite demanding project, that requires effort from me in a wide range of (process)consultancy areas.
Warning: if you think processconsultants listen, then goto their room to draw and publish processdiagrams, and magically people will follow these... read on....

Here are 5 areas you may encounter as processconsultant depending on your scope and influence. Or in my case, because in these areas things were not evolving well, and were impacting my ability to deliver good results, so I, sigh, jumped in.... (but do check your client, to see if they want you there....)

Area 1. Power discussions
The funny thing about most processes, is that they cut through various functional areas, with their own reporting structure. When designing new processes, early on (or in some cases, too late) the powerquestion will pop up: who will be responsible for what part of the process. And this means the interesting culture of manager's ego's (score!) and risk-aversion (avoid!)
As a processconsultant you might find yourself in workshops, email fights, and waiting for the "oracles" to decide (and hope the verdict will stay the same for some time...)

Area 2. Strategy clarification/operationalization
The typical thing you want as an organization is that your processes actually support (or realize) your strategy. Porter calls it "FIT". And the funny thing about many organizations, especially during change-dynamics, is that some of the strategy might be defined (and sometimes even written down! Sorry, ironic), but often, the management "bla" is so high-level that even selling icecream might be a perfectly fine process with great strategy alignments in terms of "customer focus, quality, etc". So, to bridge the gap between strategy and operations, strategy will need to be detailed in more operational aspects. As a processconsultant you might find yourself coaching mid-level managers to translate the management bla to things that have meaning for the mortal souls, including yourself to be able to define the right process.

Area 3. Groupdynamics and coaching
So you think doing some interviews, showing the diagrams will create alignment? Will create support for new ways of working? Think again. Change is hard, and building support for blueprints describing the future, while it's being build is even harder. As a processconsultant you will find yourself often in groups that are in various forms of disagreement. And often they will look to you, to help/facilitate them to find the answers. Their points of view might confuse you, irritate you, and/or enlighten you (and possibly all at the same time). Help them to find consensus. But you will need their teamlead to decide and steer, where needed.

Area 4. Operational negotiations
Ah, the processdesign looks good, but now the real work starts: implementing it. This will lead to many additional process aspects. How will work be coordinated? Who will sit in what governance structure? Who does what in the processpart of this team? How will we split the work? How do we deal with performance requirements? Vacations and workschedules. A lot of processlogistics need to be settled. As a processconsultant you will find yourself in various HR type discussions, trying to get the team to work....

Area 5. Steering, coaching the manager/teamleads
You may have defined a great process, and even defined key performance indicators (KPI's), but the teamleads need to be empowered: what will they do when one of the KPI's goes off bounds? What steering mechanism do they have, and when will they use it? How to help them get beyond firefighting (which is often a start for processimprovement) culture and get them to start steering in a more tactical way?

Some tips and best practices
- Know your scope as processconsultant, and be conscious about extending your role (you might have too much work and/or too little influence)
- Know your groupdynamics (norming, forming, etc) and change (ADKAR, Carnall's Coping Cycle). Keep an open eye on what's happening in the team(s) around you.
- Be able to operate on strategic, tactical and operational level (including the people on these levels - culture, network, vocabulary)
- Be able to step into the facilitator's role, guiding people to make their own choices (it's their process anyway, "egoless processdesign")
- Ambitions for change might be high, but ability to deliver in the organization will determine the actual results. Be pragmatic, but also don't get crushed between vision and results.
- Maturity for an organization will take time and the right interventions. Be patient when needed, and let things fail even, if needed to get messages/learning across. "If that what must, can't, then make sure what can must" (freely translated from dutch).
- It's people, your work is about people (and a bit of process)

Concluding thoughts
I seem to return to a central purpose for a processconsultant - mainly: to create clarity, consensus and alignment (say 95% of your time), the rest: dropping it in (ever evolving) processmodels.

Last: spend your energy in your own developments accordingly (learning in 2 weeks all the details of BPMN might be interesting, but you might need other priorities ;-))

Work in a process. More then we typically see...

Recently delivered training to a group of processconsultants. One item is "workflowmanagement" (no, I do not mean the technology). What we mean in the training when we talk about workflowmanagement is all the work and supporting business rules that coordinate the work being done, e.g. that make the work flow.

Interestingly enough, the students had a hard time seeing the point.

When we talk about a process, people typically limit their view to the direct work being done. If a process consists of activity A, B and C, then, when asked what work is done in the process, they will say "well, A, B and C". Sometimes we play a little game with them, to clarify: we assign tasks A, B and C, and tell them to go ahead and do the process. Work evolves and quickly we can point to new tasks that people suddenly are doing: coordination, making the work flow. Making sure the output of A is delivered to B, so the person doing B can continue. People than understand that transport is an additional activity. But unfortunately, they still don't see that the transport also has a hidden business rule for coordination "if you receive output of A, then start processing B".

The (unfortunately now technical) concepts of "orchestration" and "choreograpy" are two patterns that are used a lot when people are doing work and coordinating the work. Often we see choreography, where people have thought upfront on the process, and agreed on various actions and rules to let the work flow ("so if you are ready with X, you give it to me, and I will...."). Orchestration you see somewhat less: "Micromanaging supervisors", but in, for instance warehouse picking, there is usually a central coordinating unit that hands out work-orders, and triggers other work-orders when the earlier work-orders have been reported ready.

As part of an MBA training we played a process simulation game, to practice applying lean techniques to improve the process. When the group analysed the results of a round of playing, suddenly someone discovered her own "choreograph" activity and the bottleneck it created: the person "batched" outgoing work and delivered when the stack was getting too big (bottleneck 1) and also delivered the items as Last In, First Out order, which later in the process created longer and variating cycle times (bottleneck 2). A nice example of suboptimal workflowmanagement....

My point: in every process, there is a hidden set of activities and business rules, that make the work flow (in terms of activating/triggering people to wait/start/continue). When optimizing processes, this "hidden" process is a vital element in process optimization. We might blindly stare at improving executing A, B or C, but looking at the coordination and supporting rules will also often give a lot of optimization possibilities.

Assignment: next time you encounter a process (say, eating out) watch the process coordination going. You will see a lot of stuff happening and (sometimes) fail....

Process-design and your view on people

Quite busy, so my flow of blogitems has been diminished considerably. But collecting a lot of thoughts, observations and lessons, so maybe some time soon....

Today's thought: view on people

As processconsultant, I think it's vital that you have a clear understanding of your own view on people in the context of processes.
I encounter two opposing variations in the BPM world (and anything in between):

1. As processconsultant, we gather input, then design the process, then implement it. Implementing means: pushing people in the pigeonholes (processes, activities, roles), and assume they will do their work, driven by KPI's and managers whipping the lot.
The basis assumption: if you design, they will come and do. The rest is "changemanagement", where we explain and assume that either "they" accept, or we encounter "resistance", which we will need to "overcome". We own the process, but accept "input".
I find this approach also a lot in the BPM technology space "Buy this tool, define the process, and your people will obey and empty their taskboxes....".
So, first goals, then process/technology, then people.

2. Processes are done by people, to reach certain goals. So... first we have goals, then people, then, as a supporting mechanism, we have processes. Quite a different viewpoint! Here we first have to understand the goals of the organization and find people willing to support these goals (if nobody found, the rest is pointless). Once we have these people, we work with them (as a supporting/facilitator) to help them structure their work to reach those goals. They own the process, we bring in the process-structuring knowledge.

I firmly believe in approach 2. Yes, it requires more talking, and even more scary: being vulnerable and sometimes unsure what the people/group will want/do/support. It means running workshops, not owning the result, only the way to get there.... It also means accepting that the quality of the outcoming processes is purely based on the maturity of the people you work with. And with careful interventions you might be able to stimulate/let them grow.
In my experience I have to often seen type 1 approaches result in a lot of paper or BPA tools filled with stuff, but no implementation or support from the key people you need for working processes: the process participants or better: the PEOPLE, that understand and are happy to be supported by the process.....

Need for other BPM patterns - business focused

A lot of research has been done in the area of process patterns, mainly performed by the TUE (The Netherlands, see here) and QUT (Australia, see here). These patterns are great for validation of the capabilities and semantics of process languages (BPEL, BPMN) and technologies.

However, I think we are missing a set of process patterns, that are business focused. If we would have a good set, I think it will help us delivering projects better and quicker, and also improve our communication between business and BPM technology consultants.

Comment: When I was working on the patterns below, I found that these are mainly task focused. Flow aspects can be served well with the workflow patterns.

Based on my projects experience, I could already see a number of task patterns:

A. Simpel patterns - typical serial workflow based processes

A1. Information capture
A task in which a person is required to capture information from sources outside the system, such as a phonecall or paper-document and enter it as structured and unstructured data.

Typical context:
- Salesrep
- Call center
- Internal HR procedures

A2. Information extraction and structured storage
A task in which a person is required to review unstructured data in the system (such as the scanned image of a document) and extract data and enter it as structured data.

Typical context:
- Backoffice document processing

A3. Prepare advice
A task in which a person reviews the data of a specific request, refines the data using functionality of the system (for instance certain calculations, risk assessments, price, etc) and prepares an advice ("yes, I propose to sell this customer a policy type X, with these conditions")

Typical context:
- Front office processing, sales, underwriting

A4. Decision
A task in which a specific person, based on her/his role needs to decide on something. The task will provide for the required information (case specific, possibly also other data), and the person will need to make a decision.

Typical context:
- Approvals

A5. Review based on 4-eyes principle/judgment
A task for which a person needs to review the correct execution of an earlier task (usual: prepare advice, decision) and make a statement of the correctness of the execution, leading to acceptance of the tasks output or rework.

A6. Inform
A task (or better: a notification) informing a certain stakeholder about critical facts about the execution of a specific process instance ("your request was accepted, your loan will be payed ...."

B. More complex situations
Many more patterns can be defined for process execution. This would support more complex knowledge work situations.
Think of:
B1. Collaborative event for sharing (plan, execute)
When more than 1 person is concurrently needed for a task, in this case: sharing of information
B2. Collaborative event for decision
When more than 1 person is concurrently needed for a task, in this case: deciding
B3. Add a dynamic task
B4. Add process participants

C. Controling & Steering (operational management)
Each process also has a "control" proces (the P, D and C parts of the Plan-Do-Check-Act cycle). For this process it's valuable to also have standard patterns...

C1. Warn
Warn a certain person if specific KPI's of a certain process instance are out of bounds.

C2. Escalate
If a certain task has not been done in a certain predefined time period, escalate it to someone else (automatically, or manually after a signal), higher up the organization

C3. Re-assign
If the workload of a person or team is too high, reassign one or more tasks to another person/team, but on same organizational level

Has these types of patterns already been defined somewhere? Used? Curious.

9 best practices for a solution & process architect

Recently, I participated in a survey where they asked: what are key best practices that a solution architect should remember. When I reread my answers, I found that my best practices actually also work fine for process architects.

Here they are:

1. Beware YAGNI (You are not going to use it): base your solution architecture on traceable requirements and no more

2. Mind the coupling of components: the less a component knows, the better

3. Beware TAGRI (They aren’t going to read it): travel light, document what’s necessary and translate/summarize to various stakeholder viewpoints to get buy-in (or at least understanding)
(TAGRI was defined by Scott Ambler, in a great essay: http://www.agilemodeling.com/essays/tagri.htm)

4. Business managers don’t care about SOA. They care about that customers are served, employees can do their job, cost, time to market and flexibility/agility

5. Have a clear conceptual model of the concepts that you will use (logical component, technical function, datamodel, etc) and how these concepts relate + trace back (and forward) to other artifacts

6. Talk to the system management people too – certain non-functionals (reliability, security, etc) will drive a lot of your architecture and these people need to become your friend too…

7. The sooner the people in your team start coding, the longer it’s going to take

8. Business analysts focus on the WHY and WHAT and represent demand, architects focus on the HOW (and WHY HOW) and represent supply, don’t get this mixed up

9. Focus on the complex scary stuff first, even though the simple stuff might make you seem to have a lot of progress