Service focus or product focus?
Neil Ward-Dutton of Macehiter Ward-Dutton had a post recently entitled “Rethinking IT projects? Think service, not product, focus.” He called out a frequent mantra of mine, which is that we need to get away from the typical project-based mentality and toward a product-based mentality. While Neil agrees that we need to get away from the project-based mentality, he questioned whether a product-based mentality is the right approach either. Instead, he advocates a service-based focus, where “service” in this case is more akin to its use in ITIL and IT Service Management (my interpretation, not his).
If you dig into his post, and if you’ve been following my own posts, I think you’ll find that we’re essentially saying the same thing, but perhaps using different terminology. Neil states:
The trouble is that taking too literal a view of IT delivery through the lens of product management can prevent you from reflecting reality the way that “customers” (regular business people in your organisation, and quite possibly those external customers that ultimately pay all the salaries) see it.
I couldn’t agree more. I’m a huge advocate for usability, user centered design, etc., so anything that involves assumptions on what the user needs rather than going out and actually involving the customer is definitely red flag in my book. Personally, I don’t even like to use the term customer when talking about IT delivering solutions to the business where the business is the end user. The business and IT should be partners in the effort, not a customer/supplier relationship.
Futher in the post, Neil makes the comment:
If you take too much of a product management centric view, the danger is that you focus all your energy creating the right kind of development and deployment capabilities, without thinking of the broader service experience that customers need and expect over the lifecycle of a long-term commitment. IT operations is where the rubber meets the road, and where customer expectations are met or dashed. Too simplistic a focus on product-style management for IT delivery perpetuates the development-operations divide and squanders a great opportunity.
Personally, I don’t view what Neil describes as good product management. If your definition of product management is simply a chained sequence of development activities, you’re missing the boat. Only through excellent operational management and customer interaction can you make appropriate decisions on what those subsequent activities should be. It’s not all about development. I think this point was made very well by Dr. Paul Brown in his book, “Succeeding with SOA: Realizing Business Value Through Total Architecture” which I was fortunate enough to review with Dana Gardner. He made very clear that projects are only successful when they deliver the promised business value. This value doesn’t come when the software is deployed into production. It comes after it. It may be one month, it may be one year. I’ve been involved with a number of projects that defined the project mission statement in terms of “delivering something by such-and-such date for $$$.” While meetings dates and budget are very important, they don’t define success. Delivering business value defines success, and the effort needs to continue to ensure that happens even if there are no development activities occurring. This brings in Neil’s notion of service, and it is absolutely a critical component to success.
“Personally, I don’t even like to use the term customer when talking about IT delivering solutions to the business where the business is the end user. The business and IT should be partners in the effort, not a customer/supplier relationship.”
Using the term “internal customer” to refer to end-users in a business unit is a pet peeve of mine. It sets up the wrong relationship and the wrong expectations. “The customer is always right” is a good thing to keep in mind–we just need to remember the customer is the person buying products/services from the company, not the business person within the company.