Facilitating the “Angry Mob” Meeting

Imagine for a moment, the nightmare scenario. You have been engaged to deploy a new technology for a client. The CIO unilaterally made the decision to deploy it. The technology will eliminate IT jobs and will cause 50% of the IT group to either terminate their employment or re-skill in a technology area that is foreign to them losing their; status, years of expertise and seniority within the company. However in their current roles, you need their cooperation as a team to ensure the successful deployment of the technology. Some have just given up, some are going to fight the decision, some like the decision and others have turned to drugs and alcohol.

(OK. It was actually a Fortune 100 company and the CIO got tired of the Java/Mainframe versus .NET wars, eventually simply proclaiming that .NET was the direction and that all current systems would be moved over to the new platform within 7 years. I was engaged to facilitate the “transformation” effort and get them an executable strategy and achieve the first 2 deployments in the strategy. The company was 70% Java and Cobol Mainframe personnel with an average tenure of about 20 years, too young for retirement and too old to enjoy a wholesale update in their skill set.)

From the outset you understand that this will be a high emotion, high stress process for the participants. So good facilitation skills are paramount.

Creating the workgroups

Don’t attempt an initial mass “we’re all in this together” meeting. You’re not. Just face that fact.
Structure initial group work carefully

Peers only, no room for anyone to “pull rank”
Select people around a small achievable objective
Keep it small enough to fit in a standard meeting room but be inclusive, don’t shut-out the known opposition

Know your role going in

Facilitators facilitate and influence. They do not make unilateral decisions or defend decisions.

Workgroup Preparation

Crystalize the objective of the workgroup so that there can be no misunderstanding of the purpose

(The objective of this workgroup is to determine how we can get a detailed and complete inventory of Java and Mainframe applications. We will first define the level of detail that is required and then recommend and approach for each environment on how best to collect this information, the correct people to involve in the process and what target schedule should be placed for the completion of these activities. )

Sanity Check the objective – Is it small enough for the first workgroup? Is it achievable? Is there anyway that a participant could legitimately refuse to align with the objective. (Example: If the group were tasked with the objective to pick the first application to transform, there may be hundreds of viable excuses to not provide full cooperation to the process)
Gradually increase the size and scope of objectives after a track record of success has been demonstrated.
Send the objective in advance, cc: the executive sponsor and arrange a reply-all email from sponsor that shows support for the initiative and thanks everyone in advance for their commitment to the process.
Create and send the agenda in advance not for comment but for courtesy.

Workgroup Process

Re-introduce yourself, who you are, your role as facilitator.
Review the Agenda, Breaks and Time expectations
Explain the ground rules (minute taking and publication, attendance requirements, proxy policy, ecp [email, cell phone & pager] use etc.)
Validate that each participant knows the other and their role. (most likely the case)
Open the discussion on the first agenda item in question form.

Item 1 is the determining the level of detailed inventory. Let’s start with the mandatory information, what do we need to know about a Mainframe application? Jeff, why don’t you start us off as you own the MF app portfolio?

Control the flow, ask all participants questions. Ensure everyone participates.
Summarize out loud what you hear, not just to ensure accuracy for the minutes but also to ensure that every participant heard it the same way.

So what I heard you say is that in the MF portfolio, the user list, # applications, application summary, security requirements and code-base size should all be considered mandatory information to gather? Is that correct?
Yes. What should be added to this list? Jack what is your view?

Common Process Problems