Delivering Successfully is like the Matrix: It’s All In Your Head
In this blog I usually write about best practices that help set teams up for success. That is really what Getting Predictable is about. These best practices typically focus on processes or tools that help teams deliver successfully, eliminate obstacles and become more effective.
But today I wanted to write about a different type of best practice that helps make any team, or any individual for that matter, more effective at handling obstacles and meeting expectations.
First let’s set the stage…
A Typical Change Request Meeting
I’m working a project with four other developers and the project is going to take about five months to complete. The goal of the project is to merge two different customer files into a single master file. After merging the files, we have to update all the existing systems and point them to the new master customer file. It’s pretty simple and straight forward.
In the third month of this five month project, the Project Manager shows up to our status meeting with one of the managers from the business team. They have a change request. There are two other stray files that need to be merged from some older systems. We’re more than 50% of the way through our schedule, so this is a little concerning, but “Wait, there’s more”.
In addition, they don’t want the old systems that use these files to just point to the new master. Since these older systems are rather simple (just search and lookup), they would like to move their functionality to the newer systems and retire them.
And we have to stay on the same schedule!
The business user and Project Manager leave and we start figuring out how we can do this. Very quickly the meeting’s focus turns to identifying the challenges we have to work around.
- Do we even have the source code for our older systems?
- Does anyone understand the old data structures?
- Can we easily add the functionality to our current systems or do we need to revisit the whole user-experience?
- What happens to the two of us who have vacations scheduled? Can we still meet the deadline? Can we add resources?
And so on…
Solutioning from a Position of Weakness
To get to a solid solution, we have to first recognize that this type of thinking keeps us stuck in a cycle of “identifying obstacles”. Or, as I like to call it, solutioning from a “place of weakness”.
Admittedly, when I’m trying to solve these kinds of problems I still get stuck in solutioning from a position of weakness. I start looking at the challenge and identifying all the obstacles. I think about everything that can go wrong. Effectively, I am focusing on the fear.
I realize now that when anyone is solving a problem from this position, they are focused on what they can’t do rather than what they can do.
Your Choice: Solution from Weakness or Strength
To break the cycle, I have to help the team (or myself) move to solving the problem from “A Position of Strength”. And the way to do this is to start identifying “choices”.
It’s as simple as acknowledging the obstacles and then asking ourselves: Even if we can’t do everything they asked for, what can we do? Let’s make a list of options or choices that we can offer the Project Manager and business team.
The list may look something like:
- We can merge the data files, but we won’t be able to merge the actual applications. This means the business will still need to use the old applications, however the newer applications will have access to that information. (This may or may not help the business, but we are giving them a “choice” they can control.)
- We can do everything asked for, but we need an additional three months to complete all the work. That would extend our five month project out to eight months.
- We can merge the data files. However, we aren’t sure if we know where the source code is. We would like to drive the merging of the applications as a new project and collect requirements from business people rather than “mine” the old systems. This means we will need more participation from the business and it will extend our schedule by at least two months.
Note that each option starts with what the team can do. This is what solving the problem from a position of strength looks like. Rather than focus on what we can’t do, or what we are afraid of, we are offering choices. We are focusing on what we can do.
Most of the teams I have experienced seem to be very comfortable changing their approach from a position of weakness to strength (I don’t receive push back) in order to deliver successfully. But I have to work with them (I can’t just tell them to do that – that is unfair).
The Hardest Part…
The hardest part of this best practice is being able to identify when you are stuck in a “position of weakness”. I can tell you from experience that the more you practice; the easier it is to spot it. And it’s even easier to solve it.
I hope you give it a try and share your experiences.
Category: Defining Success, Team Performance