Fixing IT — Products, Not Projects Revisited

Google “disconnect between IT and business” and you get 16.9 million hits in just under half a second. In the first page of results you’ll find names like Cutter, Forbes, Huffington Post, and Business Insider. These facts should make it clear that the problem is real and pervasive. Where did this disconnect come from and how do you remedy it?

In the first two posts of this series (“Fixing IT — How to Make a Monster (Customer)” and “Fixing IT — Taming the (Customer) Beast”), I discussed the systemic problem of customer service and how it might potentially be overcome. Another disconnect, one that I’ve touched on before, is IT’s focus on projects instead of products. Although this issue relates to customer service and customer-centricity, it has other impacts that cause it to warrant its own post.

Projects, a concept which seems to be the center of the universe for so many IT departments, are not the priority for most stakeholders; the resulting product is. For IT, unless you’re running a pure flow process where the product’s lifetime is a continuous stream of changes and additions, projects are the events/activities that result in the creation or enhancement of the product. They are what happens to the thing, not the thing itself. That being said, I’m not a fan of the #NoProjects viewpoint. Just because they’re not the most important concept doesn’t mean they’re not an important concept; it’s just that perspective and priorities are needed.

How often do you think of the construction of your home? While it was a project that took time, effort and money, in the end, you probably don’t care. I’d be willing to bet that you derive more value and satisfaction from the use of it than its construction (which generally only comes to mind if a problem surfaces). Likewise, with IT’s customers, they care about the result. In fact, they start to care about that result at the same time that IT is traditionally considering it “done”.

IT Projects which are “done” represent a dangerous situation. In many cases, the project team moves on and the system is consigned to “support”, meaning that those best qualified to fix issues are most likely unavailable. This degraded level of support erodes trust, acting like the grenade in Tom Graves’ “Playing ‘pass the grenade’?”:

What’s the ‘grenade’? Well, it’s kinda like a hot-potato — except that you’ll know when you have a hot-potato, because it burns everyone’s fingers somewhat in passing, whereas a grenade feels perfectly safe and ordinary and unimportant until it blows up in your face…

One of the “grenades” Tom lists is “so-called ‘customer-service’ whose design, either by default or by intent, denies those who need that service from receiving it”. In other words, poor service due to ignorance of our customers needs and concerns can cause as big a rift as that due to outright malice. This is important because, as Seth Godin notes in “Thinking lifetime (don’t break the chain)”, only “The traveling salesman, the carnival barker and the old-time businessman can hit and run”. For all others, their benefit lies in the lifetime of their relationship with the customer. Think of this lifetime as a chain, each link representing an exchange of value between you and your customer:

Think of the interaction at the deli counter or the pump or the bursar’s office or the alumni office or on the website from the point of view of the customer and the chain. Where are the moments where you might lose her forever? What are the key places where you need to intervene and invest in the relationship instead of milk it, or drag it through the mud? Assuming that your competitors are just as selfish and metric-driven as you are isn’t a great strategy, because you’re still losing when you break the chain.

Support is not a cost center, it’s a profit center. Treating customers with urgency and clarity and respect (maintaining the chain) is more urgent than ever…

Think lifetime, all the time.

Having a product focus, rather than a project focus, affects the architectural design and the development of the system as well. A tweet from Rebecca Wirfs-Brock sums up the issue: “One tension that always exists (especially agile design) is when&how to support variability in the prob with a flexible design solution”. With a product focus, the product is not done until the day it’s taken out of service. As Brenda Michelson tweeted, “if software is never done, architecture must allow equally for structure and next transition; flex don’t break”. With a project focus, the team can “hit and run”, making it a tempting proposition to over-rely on YAGNI.

Evan Bottcher, in “Projects are evil and must be destroyed”, observed;

Projects deliver exactly what they promise. Project teams have little incentive to invest in the long term operation and maintenance of the systems that they create. I’m not saying that the team doesn’t care or are intentionally acting irresponsibly, but when delivery pressure is applied the first things to be dropped from the project schedule will be the cross-functional concerns that make the system reliable, monitorable, deployable, and maintainable ongoing.

The DevOps tenet of a team supporting what they build is an excellent example of product focus in action. Working under those conditions, the team has a powerful incentive to grow and evolve the system over its entire lifetime. In essence, the team develops an ownership interest in the product that helps to cement their relationship with the system’s stakeholders. Ownership, particularly in relation to those stakeholders, is a word that you will hear more about in the next installment of this series of posts.

Originally published at genehughson.wordpress.com on April 26, 2014.