I have been working with clients on complex projects for around 20 years. In that time, I have run across only one (that’s 1, count it….) project in which the technology mix was more complicated than the ‘”people issues.”’  Unfortunately, the human component of BPM is freighted with nuances that many people are not equipped to deal with.

Many Process Analysts see themselves as “Process Engineers,” and they take the designation quite literally.  They like to staff the project with like-minded people, not those pesky line workers who say, “But that’s not how we do it.”  Shortly after project kick-off, the Analysts dive into as much process detail as possible, as rapidly as possible.  They generate thick notebooks of swimlane diagrams, waving them around as if they were Holy Writ. These Engineers preside over process work sessions which are jaw-droppingly boring, mistaking the nodding heads of dozing participants for some kind of agreement on issues.  They are invariably shocked and dismayed to find that their final output -say, a Requirements Definition document – is panned by project team and sponsor alike.

So, what are they doing wrong?

Frequently, they are not attending to the “People Stuff”.  Now, a thorough discussion of the People Stuff would take a good deal of time, and should really be the subject of its own training course.  I will just touch on a few key pieces of advice here:

1. Start working on the People Stuff during your very first discussion with the Project Sponsor.  That person has an agenda of his/her own (no, really!), you need to determine what it is, and whether it will be a barrier to success.  One of my best projects, years ago, was one that never even got started.  I determined in my initial meeting with the Sponsor that he was demanding a lot of time and money for automation which would be of minimal benefit to the organization.  I made the case for tabling the project (and I had to make the case multiple times, because he was politically influential).  I count it one of my great successes, because I actively promoted the good of the company over the pet project of one person.
2. Determine the stakeholders – ALL of them.  Any stakeholder whom you ignore will show up at the worst possible time in your project, count on it. And, a stakeholder who has been ignored can be a powerful antagonist to the success of the initiative.  A good way to identify the stakeholder is to use the ProVision Business Interaction Model. This modeler helps you to push your team through the task of identifying touch points and it provides a really useful visual for your scope-setting conference with the Sponsor.
3. Ask every stakeholder: “What does success look like to you?” Ask them to pretend that the new process has been implemented successfully, and has been operating perfectly for six months: “What are you seeing? What are the things you love about this new process?” These discussions will surface some objectives which no one has talked about yet.  If undiscovered, these desires would have been voiced only at the time of project ”go-live,” when it would be too late to address them. 
4. Push both the Sponsor and management to get some workers of all levels on the project team.  You really need the day-to-day experience of all levels in order to get clarity on what the process SHOULD do for them.  Managers will tend to define the process according to the documented policy, line workers will tell you how often they have to violate that policy just to meet the goals set by management. Your job is to surface the real process; identify the broken parts, and help your clients to design a better way of doing things. Bleasdale’s Third Axiom of Process Management:  Honor the REAL process. If it’s broken, fix it; but don’t pretend it’s working when it’s not.
5. Plan to do a lot of crowd control in your work sessions.  There is no free lunch for the Process Analyst:  you must prepare for the work session with forethought; spend a lot of time developing visuals which will elicit maximum understanding and engagement, generate a good agenda, and keep to it. Provide descriptive meeting notes and lists of “takeaways” for the team to work on for the next session.  Without these tools, your meeting will degenerate into a “venting session.”  All this preparation is very difficult, very time-consuming – and a big part of the “magic” which makes a project successful.  Incidentally, I strongly advise tag-teaming the work sessions, with at least two people working on facilitation and scribing.  It is virtually impossible for one person to facilitate AND take notes.  When the facilitator stops to document issues or questions, that lull in the action sucks all the energy out of the session.
6. Find out what individual team members like, and provide it.  If possible, get a small budget for refreshments. Keep in mind that the people staffing these projects are doing ‘extra’ work. Yes, they really have full-time jobs; and they must add these meetings, and your wearisome take-away assignments, to their already-crammed workload. This causes them to feel a bit entitled to a treat, now and then; and it is only fair for you to provide it.  If money is tight at my company, I pay for candy myself (customer service is my thing.). My clients are very appreciative of the fact that I care enough to learn their preferences, and the sugar keeps the energy level up for those long afternoon work sessions.
7. Perhaps the most important advice on the people stuff—Plan to work harder than the rest of the team. If you are running the process analysis portion of a project (or the whole initiative), you are the one who sets the tone for diligence, precision, and thoroughness. Your audience will care only as much as you do. So, you must be willing to set the standard for others to follow. And, from a pragmatic standpoint, you will not be able to hold other team members accountable unless you have demonstrated that you have gone above and beyond. 

 In trying to think of a way to synthesize it all, I remembered a conversation with a potential client a few years ago.  He wanted me to work with a group comprised of IT and Marketing folks, very cantankerous and opinionated.  He was concerned about the “volatility factor” on the team, and wanted reassurance that I could manage the personalities. He asked me, “Would you mind telling me your management style?”  I hadn’t had THAT discussion in years, and the question took me by surprise.  So I answered from the gut, but tentatively, “…I guess you’d call it:  “Mother Hen…” 

 Even as the words slipped out, I thought, “Oh, brother, this is a deal-killer for sure.”  But before I had even finished the thought, he blurted, “That’s eXACTly what we need!!!!”   

 That was an “Aha!” moment for me, as I came face-to-face with my own philosophy about The People Stuff, something I had never articulated before.  And, if you think about it, it’s really not a bad paradigm.  The mother hen clearly cares about her wayward charges, but she’s not going to be a pushover.  She constantly watches their progress, intervening when necessary to keep order.  She bothers them, and bothers them some more, until she achieves the desired result. She doesn’t harm them, but she doesn’t let them deviate from the chosen path either.

So, if you are your project’s Mother Hen, look at it this way: You may bruise ‘em a little bit – but you’ll keep ‘em all alive; you’ll all get where you are going; and you won’t inflict any lasting damage.  Not bad, as management styles go.

===========================

Pat Bleasdale is an AVP with Wilmington Trust, a financial services company in Delaware.  She is a veteran Business Process and IT professional, with extensive experience in management consulting.  She has been actively involved in process analysis and business transformation since the 1990s.  Her background spans multiple industries, in sectors as diverse as Financial Services and Manufacturing; and her clients have included Fortune 100 firms, as well as small and mid-sized companies.  In 2006, Pat joined Wilmington Trust as the Company’s Business Process Specialist, charged with developing and deploying a BPM framework, a process engineering methodology, and best practices throughout the organization. 

 Pat holds B.S., M.A., and PhD degrees.  In the 1980s, she coined what has become Bleasdale’s First Axiom of Process Management:  ‘Never automate a mess.’

Related posts:

1. Knowledge Management (and beyond!) with Metastorm Metastorm was recently named to KMWorld Magazine‘s “100 Companies that...
2. Planes, planning & process improvement Today’s guest blogger, Brian Chaney, was recently featured on a Metastorm webinar,...
3. The Art of the Peel A few years ago, Donald Trump wrote The Art of...
4. Business Transformation – It’s elementary with Metastorm! In elementary school most children learn about the transformation of a...
5. Process improvement projects- cut the fat to get lasting results Recently WSJ.com featured an article that examined why, like many...

Related posts brought to you by Yet Another Related Posts Plugin.