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.

 

Information Driven Projects

When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”

Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution.Continue Reading

Business Capability Model

Current group I am working in is responsible for functional architecture. In spite of the fact that I don’t have any practical experience, I have been asked to help define a practice in Business Capability Modeling.

I think the reason for that is that I have some practical insight into the requirements that functional architecture or functional systems design places on a business capability model.

The most core principle of functional architecture involves the semantics of units of work. In fact business capability modeling is about defining the semantics of units of work – so there is my connection point.Continue Reading

Functional Architecture Principles

Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.

Functional architecture has several aspects.  Continue Reading

Five Lessons Learned From Consulting Engagements

In a recent post about consulting engagements, I talked about some of the challenges with consulting organizations and their standard practices. I thought maybe some might benefit from some insight.  These are some specific suggestions for handling these kinds of challenges.

1) Consulting firms have “relationship” managers or “engagement” managers – these are people whose job on the project it is to ensure the customer is satisfied. It is their corporate mission to ensure that your company spends more money with them. They are sales people. They come to your project meetings, with a stated purpose of making sure that the project is smooth and successful. Their “other” purpose is to develop a deeper network in your organization, and to “discover” other opportunities for their firm to “help”. While they may have expertise, industry knowledge, and skills that help your organization, it is worthwhile to question whether they should be billable on your engagement.Continue Reading

Consulting Engagements

My current role is interesting. I am an internal IT consultant in a large financial corporation. As an internal consultant I am free to work on as many projects as I can juggle. My billing is only explicit when I work on capital projects. I spend more time talking than “working”. Most of my working is writing. Yes, making PowerPoint decks is considered writing.

Over the past year, most of my own internal consulting engagements have involved some coaching. Coaching leaders on the business side of our organization through projects with IT entanglement. Coaching IT leaders through adoption of new technology or practice patterns. Coaching project leads into positions of transparency and truth telling. Coaching different kinds of leaders through developing guiding principles that make all the little decisions easier. Interestingly enough, the coaching is not really what I was engaged to do. It simply flowed from my understanding of the needs of individuals in the project context to be successful.

Recently, I have been working with a number of external consultants. Teams, actually. Teams of consultants from big 5 firms. I have been attached to the same project as they have, and to them, I am a SME and a network adapter. I share my knowledge of organizational practice and my interpersonal network with them, so that they can get their deliverables accomplished.

What I often struggle with is the shallow depth of their analysis. Their engagements are short, usually in increments of 6 week intervals. They spend a lot of time collecting data but not really producing information. They have methodologies that I suppose would be effective if the data/information they were fed were appropriately scrubbed and semantically understood.Continue Reading

A taxonomy of software types

Generally, software falls into three classes; Apps, Tools, and Infrastructure.

The Breakdown

Apps – or applications as they were formerly known – are software built to help a user do some valuable activity, like check a bank balance or edit digital images. While the end user must learn how to use it, an app is useful without further development. Some apps are configurable, so can work differently for different users or organizations, but they are still focused on solving problems or delivering value related to some specific functional domain.

Tools – are software that are more general purpose, but with a specific flavor – that they are designed so that users of these can use them to “fashion” applications for themselves or other groups of end users. Tools express their own user experience, but are not always immediately valuable without some “fashioning”. Tools can range from Microsoft Excel to Sharepoint to web content management systems like WordPress, to giant ERP systems like SAP or Peoplesoft. Many business intelligence product fall into this category.

Infrastructure – are software that really has no end user experience. They are designed completely as a foundation for other software to be built upon. This would include any software whose primary interaction mode is through API (application programming interfaces) or CLI (command line interface) patterns. Products like databases, middleware, application servers, application frameworks all fall into this category.

So why is it so confusing to people? Because technology has its own functional domains. These classes are not mutually exclusive, in that for one user it is an application and another it is a tool. With add-ons, extensions, or plug-ins it becomes even more confusing, as these constructs blur the lines between tools and applications even further. Plug-ins for a tool, may be applications focused on one functional domain.Continue Reading

The Perfect Product Road Map

At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:

Capabilities and Adoption.

in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials.Continue Reading

Staff Forecasting for Software Delivery

One thing that IT managers – and many managers whose work consists of projects struggle with is staff forecasting. Project work can often require elastic staff scalability. I have more projects, or bigger projects, or tighter deadlines therefore I need to increase staff (elasticity) to a larger size to complete them on schedule. As a leader, I need to have practices in place that work equally well with larger organizations as with smaller organizations (scalability).

In observing how the construction industry scales to do projects there are lessons IT can learn, but they don’t apply directly.Continue Reading