A Customer Who?

In this series I am exploring the notion of viewing interdepartmental relationships within a company as “customer-provider” relationships.  In this post I want to tackle the question:

Who is my customer?

Internal departments may do work on behalf of real clients of the company, but never have contact with those clients. There may be customer reps that “front” the real clients that are one kind of customer. Departments that do work in the middle of a value chain can see the departments up and down “chain” from them as customers. Other internal corporate customers may be people or department who rely on information created during the work that a department does.

Other departments whose work is more “corporate” have more challenges imagining their customer. HR, Accounting and Finance, Audit, Risk, Regulatory Compliance may fall into this category.

A third group of department has work with project-shaped components and may include IT, facilities, process engineering, organizational design, change management, and other internal consultancies.

When thinking about my customer, one thinks through the list of people, roles, and departments that consume, benefit from or whose work depends on the results of my work. These customers may or may not be people that I have any real contact or connection to.

A customer is someone who…

  • Pays for the result of my work
  • Consumes the result of my work
  • Adds to the result of my work
  • Depends on the result of my work

So to understand my customers, I need to understand the RESULTS that my work produces.  Then I look for individuals, departments, processes, or functions that have one of those relationships to those results.  Also understand, that the results of my work may not mean only the finished product, but there may be some byproducts of my work that are interesting, and there may be some intermediate products that are interesting. Byproducts may include things like “reporting” or “metrics” – and those may have different customers than the finished products.  In addition, intermediate products like plans, designs, and work schedules may have some customers as well.  Intermediate products often relate to “adds to” relationships – especially quality assurance or planning functions.

So far, this conversation has been about direct customer.  Direct customers are pretty easy to understand.  However, indirect customers are often the reason for doing things a certain way.  Their needs often change our processes.

An Indirect Customer is someone who…

  • Benefits from the result of my work (even though they may never see it)
  • Has a direct customer relationship with one or more of my customers.

Some people think about indirect customers first, especially when they are the clients of the firm.  In the context of the work that I am doing, I try to focus on direct customers, and let my direct customers inform me of their customers’ needs and how they are working to meet them.  For indirect customers, it is a team effort, with everyone in the value chain working together that matters.  Without the team, I am just as likely to make things worse as I am better.

Customers and Value

My team’s value is determined by our customers.  If I want to optimize my team, I need to consider my customers.  In the simplest example, if I produce more than my customers consume, I have excess inventory.  I got paid the same as if I had produced exactly the amount they consumed, but I did more work and now I need to pay for storage.  If my process is in the middle of a value chain, and it is not the bottleneck, going faster is not better.  However, if my process is the bottleneck today, and the next step in the chain can only consume 10% more than my current output, if I produce 20% more, I increased capacity by 10% and created a new bottleneck down stream.  If I reduce cost at the expense of peak output, when peak output is required, I have become a drag on revenue.  If I save 10% cost, but lose 5% revenue due to output constraints, my savings is not realized. Optimizing my team’s value depends on understanding my relationship to many customers.

 

Human OS, Stupid and Lazy, Leadership, Story Scope

Upgrade to the Human Operating System – BusinessWeek

I read this article, and it seemed to me to say for organizations in general, what Agile has done for software development teams.  Moving from a command and control – process/factory model, to a model that allows/incents/expects humans to invent, analyze, innovate, figure out.  Is it possible that we are finally ready to tranform organization structure from its industrial age roots into an information age – service orientation.  How many organizations say “our people are our most valuable resource” – but act like they have FTE’s – (HR/Manager speak for “universal man widgets”). 

Seth’s Blog: Stupid and lazy

I highly recommend that you evaluate every difficult thing that is on your plate, and decide whether it is lack of talent/skill/knowledge or simply lack of motivation that is getting in your way.  I hate this evaluation, because it always comes out the same.  Arrgh! 

Seth’s Blog: The difference between management and leadership

This short post was a huge shot in the arm for me this week.  Management is about constraints, leadership is about movement.  Movement and constraint are opposing forces.  Dang!  Now that I am not in a staff management role (first time since ’04) this is much easier to see.

Stories, Epics and Themes | Mike Cohn’s Blog – Succeeding With Agile®

Mike Cohn is pretty much “the man” on user stories.  I have had conversations with lots of agilists about stories epics and themes (story scope).  What nobody (including Mike) really wants to get into is whether stories are about business capabilities or software capability.  IMHO – when it comes to “requirements” for software – everything (not just agile) craps out on this divide.  And it is a critical division because all the value is on one side, and all the work is on the other.  Hmm.  Never the less – I thought this was one of the best posts on story scope I have read in a long time.