Experts in our organizations don’t speak our language. Nor do we theirs. This frustrates them greatly
Project Managers are a good example. The PM thinks about time, cost and scope. They have systems and processes that we have to fit into.
We are a paradox – they are supporting us – but we represent a volatile environment of constantly changing specifications. We can’t fit their discipline, and we keep disrupting their ‘expert’ status. We really are very frustrating. The PM talks to their partner over dinner about how impossible we are.
Meet Peter Proudfoot* the PM expert.
Peter has to control everything on his project and make clear decisions among a group stakeholders. He’s good at his job, yet feels stuck. How do we help him do his job? Do we tell Peter;
Keep analyzing data until you understand the biggest problems
What I need is a list of specific unknown problems we will encounter
Since we can never learn the PM expert’s language, how do we help Peter, the expert, make sense of what we are saying? How do we get to solutions sooner?
Who needs to be pleased in this project? Not just us, but other stakeholders and the client? What will we be doing that works for them? What do we need from them?
Suppose, Peter, this project has been a success – messiness included! How will our team have been useful to you in the work?
What will tell us that you have understood our processes?
When you have seen a project like this go well, what were some of the things that worked best – on both sides? What small steps can we take to use those approaches?
Suppose the customer will notice that the project went well for them. How would we both have supported them?
Given that we don’t know your processes, what are some of the critical elements that the team needs to know? How do you see us helping you in those areas?
Suppose the project goes sideways – most do – how do you see helping us with the changes?
Tracking is important to you. What useful tracking processes do we already have in place and how could we build on them?’
Peter, my team may let you down because we can’t always know how to support you. What do we need to do differently in order make a difference?
What are the first small steps in our project (so that we see progress)?
What other expert languages have you encountered in your organization?
Guest post by renowned European based project management expert, John Nicol
Running projects with Solution Focus methodology shifts your team focus from “What’s wrong?” to “What’s wanted?” Any project I have ever been involved with gets stuck at some point.
Project stuckness tends to be rooted in problems of resource allocation, poor scheduling and inaccuracies in cost or risk management. In my experience too many project managers will invest far too much time and resources to get a deep understanding of why the project is failing to move forward. Understanding what is wrong and who is to blame gives them the illusion of control. As a Project Mediator I aim to minimize root cause analysis and instead focus more on looking for clues for success. I often throw out the open question; “OK, we’re stuck, so what’s wanted here to put it right?” I am not ignoring problems, I am just not adding more fuel to the problem talk. What I do is support the project team to propose small steps to start unsticking the situation. The problems are still there but the team is committed to share successes and shift towards solutions.
1. Focusing attention on what works always maintains higher human engagement and gives proof that we have good people and systems in place.
Many people I have worked with have written this approach off telling me; ‘Just being positive won’t help’. This approach is not ‘being positive’. It is about investing time and energy with the team looking for concrete, measurable evidence that we can fix our problems and become unstuck. It is about shining a light on the team’s creativity and thereby driving better cooperation.
2. Deep diving problems drives problem talk, talking about solutions drives sucess talk.
All projects have strict budgets of people, time and money. In my opinion it is always a better investment of those precious project resources to steer focus away from deeply understanding problems and towards what steps we can take to define and implement solutions. In the process of designing workable solutions, the team begins to describe how much problem analysis is actually useful in this case.
3. Simple questions leverage the resources you have more effectively then small miracles happen.
As a project mediator I often adopt what SF calls ‘the beginner mindset’ to find solutions. By assuming a position of no project management expertise I can ask simple (even naïve) questions such as “Suppose the tools were working as we need them to, what would be happening?” or “When did you successfully solve a problem like this in the past? Walk me through the steps you took”. In most cases like this I have heard people speak up who had tended to stay quiet in the past. This is what I refer to as the small miracles.
4. Minimize Problem Analysis to radically reduce bickering in your project teams
When projects become stuck, what normally happens in the very worst projects? The manager will kick off a Blame Game. He will insist that we need to get control of the situation by writing down everything that went wrong and identifying the guys responsible. Apart from being an unpleasant experience for everyone in the project, the process of investigating wrongness is very expensive and almost useless in terms of delivering better business results. Using Solution Focus methodology, I absolutely minimize – ideally avoid – investigating why things have gone wrong. Instead I acknowledge that ‘things go wrong’ and encourage those involved to step up and talk about what we can do to get back on track.
5. Solution Focus Project Mediation methods require hours rather than weeks to learn
Above all the solutions focus tools are simple and require very little training time to apply. Solution focus methodology taught me a couple of powerful principles for managing complex organizational projects
Every project is different
We do not need to deeply understand our problems to find solutions
The first point reminds me to respect the uniqueness of the situations and problems and avoid ill-fitting theory. Experts are only useful in as much as it helps to define and implement the solutions as close as possible to the given project constraints. Solutions always emerge when we ask each other questions about how to best succeed.
The second point emphasizes that the over-analysis of complex problems does not move us towards solving them. Instead it is more efficient and ultimately profitable to spend my team’s time building confidence about how we can design and implement solutions as quickly as possible. I ask very simple questions such as What else? and who else? to start writing impactful project plans.
John Leslie Nicol is a co-owner and partner of Q595.com. He is a Solution Focus Project Mediator who specializes in getting stuck projects moving again towards better results.
Traditionally, project managers tend to be very risk-focused and heavily assess the risks in a project, ranging from those that are most likely to cause system failures (integration, security, etc) or have a huge cost impact (licensing, outsourcing, etc), to those that might push the schedule back in failed scenarios (resource related risks). So eventually a lot of time gets spent in looking at ways of de-risking situations and analyzing what could go wrong.
How can we shift the focus of a project manager from ‘Failure and Risk Management’ to ‘Envisioning projects with risks and failures removed’?
Suppose a team does that, what benefits would they notice? How will that help the team in getting guided towards successful execution of the project?
John Nicol, whom I interviewed recently, helps answer these questions and explains how Solution Focus (SF), due to its collaborative and facilitative nature can be a very powerful tool to enable project discussions with failures removed.
John is a SF professional and a Certified Scrum Master. As a SF professional, he has been successfully applying the approach in different types of businesses. As a ‘ScrumMaster’, he has been practicing Agile project management techniques in numerous organizational transformation programs.
1. Look at successful methods of doing things to enable progress:
The greatest advantage of using SF tools is that it is forward-looking – teams look for strengths and opportunities going forward, they look for indicators of what’s working. For instance, in an effort to centralize software tools within an organization, project managers can begin by answering following questions and use that as a platform for getting to solutions in the future.
“Where have we centralized the tools already?”
“Which parts of the organization have succeeded in this effort?”
“Whichintegration steps are already in place?”
In a SF approach, project managers do not ignore that things could go wrong. They acknowledge the risks and the failures, but turn the question on its head by asking
“What could we do instead?”
“What could we do that would make the situation better?”
2. Apply SF “future perfect” tool for better project planning:
Using SF tools such as future perfect and scaling before the development starts, imagine a project with risks and problems removed. Answering questions such as the following will help teams to list out the activities that they must get right.
“Suppose the project is X months ahead. The project is over; it is delivered on schedule, and has met all the objectives. On looking back, what were the useful things we did to get there?”
3. Leverage SF coaching to self-organize teams: Scrum projects (an Agile project management methodology) are delivered by self-organizing teams and it puts a lot of emphasis on coaching and learning from each other. The ScrumMaster is often challenged by the maturity of their team to self-organize in order to address the risks and rearrange the work activities as needed. What SF adds to the picture is that it enables the ScrumMaster to better coach their agile project teams who, when faced with cost-driven and time-driven risks, can remain on a positive note by asking questions such as the following
“Where do we already have examples of on-time delivery from past projects or project phases?”, “What did we do then to keep the work on schedule?”
“Which free or low cost alternative solutions are available or in use in other parts of the organization or project?”, “Are there existing contracts in place that are cost effective?”
“Suppose a cost-effective licensing solution was already available, what would it look like?”, “What else would help?”
4. Acknowledge and reward your team to promote solution-talk:
With more and more virtual teams operating, project managers need to work harder at acknowledging their teams and communicating the rewards and successes (an area where most managers suffer!). There are a lot of people in businesses who don’t feel heard – many of them have very smart ideas but haven’t really gotten the opportunity to bring them on the table. SF is a very powerful way to give these people the acknowledgement that they are looking for by acting as a mirror to their language and using their words while talking to them.
5. Maintain transparency in communication with the Business Partners to create visibility:
In Agile, the Customer or the Product Owner is part of the project team. They need to know that the development team and the Agile project manager agree upon a common solution, and maximize their investment by equipping them with the critical information they need to know.
In conclusion and to summarize John’s comments, I think Scrum is well-aligned with SF tools. Both systems of thought and practice share a strong grounding in delivering quick results through self-organizing teams, having openness and transparency in communication with product owners and customers, and encouraging coaching to empower the staff to think for themselves.
A definition of ScrumMaster that I came across supports the views mentioned here quite strongly.
“A ScrumMaster is a servant leader helping the team be accountable to themselves for the commitments they make”
Some of the significant characteristics one associates with a servant leader are trust, collaboration, listening, empathy, and foresight. They do not manage the team, because the beauty of Scrum is that teams are self-managing. Instead, the ScrumMasters coach their team to help them achieve outcomes on their own.
What are your comments on the proposed SF approach to project management?