I’ve been absent a while. I’m back.

A few weeks ago I was asked to facilitate a one-day eeting for a software system development team. They were behind schedule, over budget, and in a general state of breakdown. A good friend who is a member of the group recommended me to facilitate the meeting at which they would put together a briefing for their client that articulated the current state and suggested a plan of action. I don’t “market” my facilitation skills, so do not do this sort of thing very much and hadn’t done for a while. I did a quick refresher on project breakdowns by calling Dennis Smith, a colleague who has deep experience in helping project teams. He gave me a quick summary of the five most frequent causes for project breakdown: continuing to accept new requirements, inadequate testing, lack of control of the build process, lack of control over problem prioritization and resolution, and lack of accountability.

As I prepared for the meeting, talking with the project team leader, we discussed the standard “brainstorm, collect issues, affinitize, prioritize” process using stickies, etc. OK, I said, but maybe for the prioritization we ought to do some voting (I thought of my friend Kathy Hornbach who instilled in me an appreciation for using colored dots to get groups to vote). Great idea, said the client, so I tucked that away.

Later as I thought about how to collect issues, I thought about my Cynefin training with Dave Snowden and thought perhaps a “future backwards” might be a good method. In “future backwards,” teams describe the current state, and work backward to identify the key events that led to it. Then, they imagine a future “hell” and a future “heaven” and imagine the events that would lead to each. Through the dialogue of creating these scenarios, issues and obstacles emerge. These would be a good starting point for collecting issues and ideas. Unfortunately I did not have a supply of hexies, so we had to use Post-It Notes, just not the same, but the exercise had its intended effect.

We started the day with that, which both surprised and pleased the clients. Although there was not time and it wasn’t appropriate to integrate the entire Cynefin framework, I did something a little different. Given the system framework that I use in my consulting (based on a “Star” model that I learned from the OD people at Digital many years ago), we put the issues into the categories of technology, culture, processes & work practices, mission, and organization. Then I had them separate the stickies on each chart into the “things over which we have no control” and “things which we can control.” These provided the basis for the content of the briefing.

How to structure the briefing? I reached again into my experiences and remembered Edith Poor’s MAPSIQ (from her book, The Executive Writer) and used that to focus the conversation. MAPSIQ is simply a mnemonic for Message, Audience, Purpose, Situation, Introduction, and Question: the central content-organizing principles for developing an effective document. The dialogue to flesh these out was clarifying and helpful.

It is amazing how, in the moment, the relationships that have led me to learning over the years come together when you focus on what the client needs.