Wednesday, February 23, 2011

Maybe it is time to define "customer" in IT Projects

IT projects and methods seem to big on the word "customer" these days...

Common definitions of:

customer - one that purchases a commodity or service

purchases - the acquisition of something for payment

So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.

I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.

Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.

However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.

So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.

But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.

IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.

7 comments:

John Owens said...

Hi David

Thanks for the post.

Your definition of "customer" is leading you to what, in my opinion, is the wrong conclusion.

A person who "purchases a commodity or service" is a Purchaser.

A Customer is "any party to whom another party provides a commodity or service against standards defined by the party receiving that commodity or service".

This definition makes it quite clear that all IT systems will have a customer. One of the key success factors for any IT project is, right at the outset, to "identify the customer".

Without knowing who the customer is you can never identify the customer requirements and so you can never fulfill them!

So, not only does every IT project or system have a customer, every one requires a customer in order to be successful.

One other thing, the customer is not the "user"! But that's another story.

Regards
John

David Wright said...

John,

I know already that we will agree to disagree, so a few points for conversation:
1) I don't trust definitions that use the word or its root in the definition.
2) Where did you get your definition of customer? mine is from Oxford and Webster dictionaries
3) I obviously disagree with your definition, so I also disagree with the term "customer requirements". A Business will have Business Requirements.
4) Business Requirements outlast the people involved when a system is developed or purchased. So, you need a method for identifying requirements that are Independence of personal desires. People come and go, but systems go on for years and years.

Now, if you want to use the term "customer" to refer to a unit in an organization that will use the software over time, as opposed to individual persons, there are still people involved, especially the manager of that unit. So, how do you avoid the detrimental behavior of such a manager if he is treated as a customer rather than a team member?

Laura Brandenburg said...

Hi David,

I see your point. And maybe if IT had historically been better and coming together with the business to collaboratively solve problems, we would have side stepped the customer-provider dichotomy. However, I see that thinking of business sponsors and stakeholders as customers can encourage a lot of good behavior in IT and can actually lead us toward collaborating more fully and effectively. As an interesting side note, it seems that the best companies are finding new ways to collaborate directly with their "real" customers (per your definition) and brining them into the product lifecycle. Perhaps this is another model IT teams can take and learn from as well.

Jon Kerner said...

We need to eliminate the idea of the IT customer. It creates the expectation of "the customer is always right" without any obligation on the part of the supposed customer.

Intelligent IT decisions are based on thoughtful governance mechanisms. They support agreed upon service expectations or strategic priorities, determined by what is best for the business.

There are many roles that non-IT staff can play when engaging with IT. Examples include sponsors, partners, and process owners. All carry an expectation of accountability and shared responsibility. The role of customer has no such expectation. It simply assumes IT will take orders.

David Wright said...

Laura,

The past bad behaviors of IT merit a variation on this topic, that being who is the "owner" of IT Projects... you may be able to guess my thoughts on that, but I will collect them and do another post for that.

You also make me think about if a company can use the terms "customer" and "supplier" to help its teams understand how to better work together, but avoid the pitfalls I have described. I am sure there examples of it that could be pointed out to us all and, if so, I always "power to you" , don't mess with something that works for you. But I suspect those companies would be in the minority (admittedly based on only my own experience), and the problems caused by getting this wrong are normally not worth any benefit that may be expected.... (look for more on this in my next post).

Laura Brandenburg said...

John,

You wrote: "It creates the expectation of "the customer is always right" without any obligation on the part of the supposed customer.

I happen to believe in the heresy that the customer is not always right. I am a business owner and believe me, there are plenty of people out there who are not my ideal customer and I choose not to do business with them. But I agree, I'm in the minority here which is not all that unusual. :-)

TDK Technologies said...

David,

Excellent post and an argument which I think can be extended to include IT project outsourcing as well. I've attempted to do so here: Aligning the Interests of IT and Business: An Approach to IT Project Outsourcing.

It's a bit more difficult from an IT consulting firm's perspective to avoid terms like "client" and "customer", but letting “the customer is always right” mentality dominate the relationship between IT and business can certainly lead to undesirable results. We just recently turned down a project because instead of our proposed solution a client wanted a patch of an existing system which wouldn't solve the underlying problem. It certainly looks better from a cost perspective but that sort of approach isn't in the best interest of their organization, or ours for that matter.

Best Regards,

James Dickman
TDK Technologist

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.