Archive for the ‘Customer Service’ Category
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.
Beth Gold-Bernstein had a great post entitled, “The Second S in Saas” that outlined her experience in trying to get a backup restored from an online survey site.
This is clearly important when you’re dealing with external service providers, but I’d like to add that it is equally important for the services that you build in house. The typical large enterprise today is rife with politics, with various organizations battling for control, whether they realize it or not. SOA strikes fear into the heart of many a project manager because the success of their effort is now dependent on some other team. Ultimately, however, success is not defined by getting the project done on time and on budget, success can only be determined by meeting the business goals that justified the project in the first place. If something goes wrong, what’s the easiest course of action? Point the finger at the elements that were outside of your control.
I experienced this many times over when rolling out some new web service infrastructure at an organization. Teams building services were required to use it, and whenever something went wrong, it was the first thing that was blamed, usually without any root cause analysis. Fortunately, I knew that in order to provide good service for the teams that were leveraging this new infrastructure, I needed to be on top of it. I usually knew about problems with services before they did, and because the infrastructure put in place increased visibility, it was very easy to show that it wasn’t the new infrastructure, and in fact, the new infrastructure provided the information necessary to point to where the problem really was. Interestingly, this infrastructure was in the middle, between the consumer and the provider. Arguably, the teams responsible for the services should be looking at the same information I was, and be on top of these problems before some user calls up and says it’s broken.
If you simply put services into production and ignore it until the fire alarm goes off, you’re going to continue to struggle in achieving higher levels of success with SOA adoption, whether you’re a SaaS provider or a service developer inside the enterprise.
Back in December, I posted some kudos to my local Apple Store at West County Mall in Des Peres, MO. Back then, during the week before Christmas, they replaced one of the fans in my MacBook Pro in about two hours, when I was expecting to be without for a week. This fan issue was a known problem with the first generation of MacBook Pro’s with the Intel chips. Anyway, the other fan in it started rattling away recently (thankfully while it was still under warranty), and I took it in this past Saturday at 5:40pm. They told me it would be about 5 days. I let them know that I use it for work and would be traveling on Tuesday morning, so if there was anything they could do to get it done by then, that would be great (I have an older Powerbook that I was prepared to use). Well, at about 10:40am on Sunday morning, the call came in that everything was fixed. Once again, whether it’s a case of extremely conservative estimation or someone going over and above to get it fixed, I’m a happy customer. My MacBook Pro is quiet as a whisper again and I’m thankful to the techs at the store. I talked with a few of the guys there, next time I need to remember to get their names to publicly thank them.