“I just don’t get it.” I was staring at the email thread on my screen. I was in utter disbelief as to what it was telling me. Like pulling on a single loose thread unravels a cartoon sweater, this one email thread had just unraveled three months of my hard work on the Jericho project. I felt like the walls were falling in on me and a part of me was hoping the building would collapse and crush me so I didn’t have to deal with the fallout.

Turning in my seat I stared out my window taking in the inky black of a moonless night. Jake’s email had started the thread innocently enough. He wanted to make sure we’d addressed the dependency with the data team before he started work. Donald’s reply pointed to a dependency with the release operations team and capabilities of that datacenter. This led to a ever growing cascade of dependency and communication issues that were culminating in a pretty simple message, the project was dead before it ever laid the first brick of its foundation.

“I just don’t understand”, I said to my reflection, in the window. “We planned everything, we reviewed the plan, we had buy in. What went wrong?”

A voice answered me from  the darkness of my office, “I believe the technical term is that the right hand didn’t know what the left hand was doing.”

Why did I ask a question? Didn’t I know exactly what would happen if I asked  rhetorical question?

“Of course you knew what would happen,” replied my 800 pound conscience. Hogarth reached his massive hand out of the darkens to turn on my desk side lamp. My office no longer lit by just my computer screen, I could clearly see Hogarth looming from the darkness of the rest of my office. Flashing me a blindingly white smile, he continued “Don’t feel bad, you know I would have answered even if you hadn’t talked out loud.”

I sighed. He was right of course. May as well just take the medicine and hope to get it over with. “Enlighten me, oh wise one.”

My gorilla wagged a baguette sized finger at me, “Now, now, I’m the sarcastic one here.” His other hand came into view with part of my fichus clutched in it. Nibbling on some leaves he said, “your problem is you didn’t tie off with your stakeholders right.”

“Seriously?!” I just stared at him. I had most definitely met with my key stakeholders. Heck, half of them I met before the project even started.

“Having coffee with Jake doesn’t count as meeting your stakeholder.” Hogarth scolded.

“Don’t start, Hogarth. I know how to talk with my stakeholders. I have relationships with all the key ones.”

He nodded his beach ball sized head. “Yes, you do. Let me ask you a question though. When the teams create user stories, is there a specific formula?”

I nodded.

“And when you do release planning, is there an agenda and set of questions you always ask?”

I nodded.

“And yet your meetings with the stakeholders are informal, not structured and not the same. How do you expect to know if  they are on the same page if you don’t ask them the same questions.”

Huh…

 

Ask the Same Questions, you will see Patterns

The Internal Customer Interview has been a staple tool in my project tool box for years. I first adapted it from Manager-Tools.com and over the years have  tweaked it and discovered its value beyond just when starting  a new job.

 

Now stakeholder meetings are nothing new. Even the Hogarth me knew to have meetings with the stakeholders. The secret to why the ICI tool works over standard relationship building meetings is in its consistency. If you don’t have consistency across your reviews, you’re not getting proper value out of your interviews.

 

Say you meet with ten stakeholders and with each of them you have a different agenda and questions, then you only gain the context of that stakeholder in that stakeholder’s domain.  You are less likely to pick up on trends that crossing the organization.

 

With the ICI format the key is to ask the exact same questions to each stakeholder. By asking the same questions, you can take the qualitative data of a single interview and begin to form a quantitative view of the whole through repeated asking of the same questions.

 

An interview shouldn’t be more than 30 minutes, so generally you want to limit yourself to five or six questions.

 

The Questions:

New Job / Major New Project:

These six questions are what I used when would start a new PMO job or major new PMO project.

1‐ What do you and your org need and expect from the PMO team?

2‐ What metrics do you use to assess us?

3‐ How have we done relative to your needs?

4‐ What’s your perception of our org in general, that perhaps the numbers don’t show?

5‐ What feedback and/or guidance do you have for me/my role/my team?

6- What are your biggest pain points?

Agile Stakeholders:

I developed these questions working for LeadingAgile. They are designed to evaluate where company is with its agile transformation (or preparing for an agile transformation). It extends beyond the recommended number of questions because of the sub-questions. It still fits into 30 minutes though, since the follow-up questions are generally shorter answers, so it still fits the model.

1- How well do you think <your company> is doing at establishing long-term, executable product vision?

2- How well do you think <your company> is doing at release planning (next 3 months) and making this plan transparent?

   2a- How well are you doing at meeting the commitments in the planned work?

   2b- Was new work added to the release plan after planning close and if yes, what percentage of overall backlog changed?

   2c- If yes to 2b, what percentage of new work was from farther down the existing backlog as opposed to brand new features/stories that did not exist when release planning closed

3- How well are you doing at delivering of working, “accepted” product to the end customer? Is it high quality, is it delivering value to the customer?

4- How well do you think <your company> recognizes problems and opportunities for improvement? With it’s Products (internal and external)? With it’s processes?

   4a- How well are you at executing on these opportunities for improvement?

5- Do you feel you are getting sufficient support to fulfill your  job role?

6- What are your biggest pain points in your job (or what keeps you awake at night).

Meeting Setup:

While the questions are the secret to a successful series of interviews, you need to make sure you set things up for that success.

Invitation: Contact each stakeholder individually. Request 30 minutes of their times to ask for them questions related to X (new job role, project, initiative). In the invitation include the one slide overview (see below) and a copy of the questions you will be asking. Never send this out as a broadcast message. Each person should be contacted individually.

One Slide Overview:  This isn’t a presentation. This is a focus for talking points. The contents are:

Mission Statement/ Goal Statement- What is being attempted?

How Statement (Optional)- It may be helpful to include how something is going to be done in some instances. For example the Goal focuses on improving predictability, and the How states this will be done through the rollout of agile governance (for example).

Plan– For a new job this is usually the 90 day plan. For a project or initiative this should be the next steps planning, not a detailed list. There should be no more than 5-6 bullets.

The Questions: Have them prepared before hand and let your stakeholders see them before you meet with them. For about half your audience, they won’t ever look at them. However the other half will look at them and be much better prepared to answer them in the interview because you gave them a chance to think about them before hand.

Stakeholder interviews are too important to go in off the cuff. Take some time to plan them and you’ll get a lot more value from them.