The new A in SMART - Getting Agreement

Getting agreement becomes exponentially more complex as number of stakeholders increase. So how do you agree a goal, objective or deliverable, when everyone seems to have conflicting opinions?

Begin with the end in mind. When defining the scope, ask yourself what does success look like? How do I know I’ve reached my goal? Then ask your stakeholders the exact same question. If they are not able to answer now, they will not be able to answer three months down the road. Not knowing is worse than not agreeing, so make sure you define SMART objectives (se below) before you start.

When interviewing stakeholders, you will probably find that success looks different to different people. If this is not the case I’d be willing to bet your not getting into the necessary level of detail. Trust me, people have different agendas. Marketing wants something flashy, Finance wants something cheap, and the CEO wants it all yesterday. But don’t worry. Facilitate the process. Getting this right will be the difference between success and failure (literarily).

First start by listing all requirements. Highlight what is aligned, and what is at conflict. It’s much better to say “we agree on 70%, lets sort out the rest..”, than to only list the problems and complaining that “we’ll never be able to agree.“

Once you know the gaps, it becomes easier to discuss them. Get the key stakeholders in a room. Do a cost/benefit analysis, a prioritization exercise, map to the overall business strategy… Remember you are only facilitating. It’s up to the stakeholders to tell you what they want. Don’t let them out of the room before they have defined and agreed on SMART objectives.

S – Specific (Do we understand what we are trying to achieve?)
M – Measurable (How do we measure the result?)
A – Agreed upon (Do we all agree?)
R – Realistic (Is it possible to achieve?)
T – Time Bound (When should it be achieved by?)

Note: Some people argue that the A stands for Achievable, and the R for Relevant. I prefer the above since it better supports decision making.

Once you have your objectives, two activities remain. Sign, and Communicate. Yes, I know we’ve already said it’s agreed upon, but the power of Ink on Paper is remarkable. You’ll be surprised how much more people pay attention if they know they have to sign their name. Suddenly the “I never agreed to this”- argument isn’t quite as valid.

The second is communication. Once the stakeholders have agreed have them communicate it to their subordinates. Make it easy for them. Provide the material. Tell them what to say, but don’t communicate on their behalf. The act of actually saying it makes it their own. So the more they communicate the more they’ll agree.

So to summarize. Let the stakeholders state their opinion. Highlight where there are gaps, and help them work it out together. Make them physically sign a SMART objective, and finally have them spread the word. Only by fully engaging the stakeholders can you get their agreement. It’s a painful process, but compared to a painful project it’s short-lived pain.

On Risks, Issues and Dependencies

I love risks! My projects have lots of them. I go looking for them, and sincerely thank people for bringing them to my attention. I keep a risk log and am happy to share with anybody, exactly how risky my project is.

I hate issues! Issues are risks that have materialized. A risk is something that might go wrong, while an Issue is something then has already gone wrong and is impacting the project result. Time, Cost, Scope, Quality.. even morale. Risks are good, Issues are bad.

I am terrified of Dependencies! A dependency is a connection between your project and a factor that you do not have control over. A typical excample is being dependant on a deliverable from another project to be able to move on. A dependency is a risk, just like any other risk. It can (and should) have mitigation plans, and should be monitored on regular basis. The difference is that dependencies are tightly related to people and communication, or lack thereof. You’ll typically have good visibility within your own project, but how confident are you that you are getting the necessary information (in a timely manner) from another project?

Communication is usually not a problem when things are going well. Weekly status updates, and ad-hoc synchronization could be sufficient. But what about crunch time? Go-live in a week, multiple critical defects, last minute decisions with impact to both time and deliverables… How likely do you think it is that the Project Manager will pick up the phone just to chat about the change of plan? I wouldn’t put a lot of money on it. This is natural. He has other priorities than you. And he might not even understand (or remember) to what extent he is impacting you. But even if he does give you a call, and let you know that unfortunately he’ll be a few weeks late - your risk has materialized, and turned into an Issue.

Let me summarize: Risks are good. Issues are bad, Dependencies are damn scary.

So what to do? Create a risk log! Lots of fancy tools out there, but excel works just fine. Give each risk a unique number, a simple name and a short description so it’s understandable for someone external to the project (and so you don’t look stupid when asked what it’s about).

Then estimate the likelihood of it occurring (0-100%) and the impact if it should occur. 0-100 is fine here as well. We could get into lengthy discussions on how to classify and measure impact, but I find that simple is better. No impact = 0, project failure = 100, and anything else falls somewhere in between. Multiply the two and you get your risk grade.

Example: If a risk occurring will cause a 2 week delay on a task that is not on critical path, I’d give it an impact of 50%. Let’s assume it has a 70% chance of occurring – you risk grade would be 50%*70% = 35%

Do this to all your risks, sort them by risk grade, and you have your very own prioritized risk list. Now work through your risk list starting from the top. Give a short description of the potential impact. Don’t overdo it, but don’t sugarcoat it either. The next one is optional, but I like to include a trigger description, stating what will turn it into an issue (e.g. Business Requirements not delivered by end of month).

Finally you need to come up with one or more mitigation plans. These should be formulated as proactive action plans that you or your team will execute to avoid a risk from turning into an issue. And this is important. You need to execute your mitigations before the risk becomes an issue. If it’s already an issue you are already being impacted. Depending on the risk grade I try to have at least a few mitigations for each risk. For the risk of business requirements being delivered to late, a few potential mitigations could be:

• Make sure project X understands the impact of a delay (over communicate), and secure frequent status updates.
• Re-plan project tasks to reduce impact of late delivery. (Is there something else we can do first?)
• Work with early draft or assumptions until final version is available
• Ask management to add more resource to speed up project X’s delivery

And now for the fun part: Start executing your mitigations. Again, use common sense. Depending on your experience and sense of empowerment, you should probably not go running to management unless it has a high risk grade. Start with the things you can easily do yourself without wasting too much resource. Most of the time this will eliminate the risk, and you will be a hero for running issue free projects.

But if the risk grade keeps increasing, escalate to a steering group or a sponsor, by stating what the risk is, and what you have done so far to mitigate it. Follow up with your recommendations, and the impact of not doing anything. This will give whoever is in charge enough information to make informed decisions, and if you bring it up before it turns into an issue you will most likely get the help needed to make it go away, or at least get a free pass out of jail.
On my weekly status update I always include my top three risks, and a one liner describing what I am doing to mitigate it. This is primarily to keep everyone informed, and is a good talking point when discussing your project. “The project is going well, and we are mitigating the following key risks…” I try to plan escalations for regular steering group meetings, but have sometimes had to call extraordinary meetings when I need help.
Go ahead, make a risk list, and start executing your mitigations. It will probably feel like a time consuming activity, but once you get used to it, it’s fairly simple to keep up to date. Do this for a while and you will start reaping the rewards… and I bet in a month or two you will surly agree that risks are great and issues are bad…

Good luck!