Wednesday, June 24, 2009

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 ;-))

1 comment:

Scott Stephens said...

Roeland - I just discovered that you were gracious enough to include my blog on your blog roll. I had not discovered your blog but have found it fascinating and will include it on my blogroll as well. Your business rule mining discussion was great (it reminded me of issues we had in the development of the SCOR Model) and a bit of software that we built when I was at Lockheed. It reverse-engineered a product based on the software code. It may sound trivial now, but there was time when the only place to find the business rules were in the code).