Friday, October 26, 2012

Define and Own the Problem (Principle 1)

Preface - you may want to read the introductory post.

Let me start with the simple and move out from there.

What are we trying to do?  And
Who owns making sure it gets done?

No matter at what level a problem or opportunity exists, it must be defined to be owned and it must be owned to be delivered. Just having an organization or team that does this regularly (and mind you they do not have to be great) will make good strides in providing value.

Seems simple and in well running organizations or teams it is handled without much fan fare. For weaker organizations or teams, problems can be 
  • poorly defined or not defined at all
  • the wrong problems can be defined
  • they are not owned
  • they have the illusion of being owned
Once you have definition and ownership, you can improve your outcomes and accountability by asking two questions.
  1. Did we define the right problem?
  2. Do we have the right owner(s)?
To help illustrate, 

Project status meeting

Project Leader: It looks like we will not make our delivery date due to delayed development and QC.
Development Leader: Yes, we will be late. Requirements were delayed so we had to push out some work.
QC Leader: And of course, that will impact QC.
Project Leader: The date has financial implications. We need to make some corrections. What can we do?
Development Leader: Hard to make up time when requirements are late.
Requirements Leader: Some of the requirements were late. Most were on time or early. It is not a requirements problem.
Project Leader: So what are we going to do?

... Long silence...

Project Leader: I will schedule a followup meeting after I look for ways to crash the schedule.

Meeting adjourns

You have probably been in a meeting like this. And even worse, you have probably had the same meeting multiple times to dance around the problem. This can occur in any type of SDLC. The problem is rooted in the organizational or team culture. So for the example above:

What is the problem? Who owns it?

There are many problems in this. First, the leaders do not behave as a team (Five Dysfunctions of a Team). Second, the project is late and there are financial impacts. Third, it is not clear exactly why the project is delayed. Fourth, it is not clear if or how the date can be met.

When it comes to ownership, all in the meeting have some awareness that the project is late and there will be financial impacts. Having been in a few of these types of meetings, the thought bubbles for the different leaders may go like this.

Requirements Leader: Development always blames us. This is their problem it is not mine.
Development Leader: We have to pick up the slack again because the requirements team goofed around early on in the project. I knew this would happen. This is their fault.
QC Leader: Always the last in the train of misses. They always expect us to pick up the slack. This time I am holding the line.
Project Leader: Someone has to fix this and I know these people never will.

So the project leader walked away owning the problem. All the other leaders left the meeting feeling justified and the primary problem of making the date still exists with no clear plan for resolution.  It is likely this meeting will happen again and with likely the same results.A lot of emotional energy can be spent on these types of issues and meetings and without a direction to move forward, it will rob creative energy from your organization or team.

Break Down

As a leader, you can walk away from the meeting and look at the problems from the meeting and better define the problem and then begin to create ownership.

  1. The leaders do not behave as a team (Five Dysfunctions of a Team). 
  2. The project is late and there are financial impacts.
  3. It is not clear exactly why the project is delayed.
  4. It is not clear if or how the date can be met.
You have a team problem of trust and accountability. The team knew well in advance of this meeting about the issues. What are the barriers that keep them from getting through this? The team and not the project leaders alone owns the problem. Following the value to the customers is an organization problem. There are no points for being able to explain why we did not make it. There is only reward for delivery. 

Defining and assigning ownership

We need to make the date for our financial commitment. What can we do to make this happen? If we cannot make it, what can we make and what are the financial, customer and organizational impacts. Finally, this level of execution as an organization is not acceptable. We need to be better going forward. As a team, I want both of these areas solved. I will give you until the end of day tomorrow to provide the time line for addressing these matters.

I would love to hear your stories and comments.

A good book with stories about defining and getting others to own and lead change can be found in the book Switch.


  1. Define and own the problem 
  2. Follow your work to your customer(s)
  3. Practice continuous improvement
  4. Provide professional growth
  5. Build and practice teamwork
  6. Provide accountability



No comments:

Post a Comment