[For the first part in this series, click here.]
Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was….[drumroll]…five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.
Unfortunately, not everyone understands the plight of the poor developer. Executives get frustrated when teams cannot give them accurate estimates. Customers get frustrated when companies are slow to deliver what appear to be relatively trivial changes. As one software industry executive with whom I spoke recently said, "Ten years ago, you could not explain to anyone's satisfaction why a major software release took dozens of months. Now, customers are even less patient."
As the airline example I cited at the beginning of this post illustrated, software development isn't the only obstacle to execution. However, software development teams can't afford to add any further obstacles. Poor execution does more than trip up company initiatives like a customer loyalty program. The customer's relationship with the company also suffers, in one obvious way, and one less obvious one.
When companies fail to execute, the content of the relationship degrades. Customers get unhappy, frustrated, annoyed, outraged, cynical, and suspicious. Back in the bad old days of Comcast, the company set up a customer forum. Unfortunately, Comcast failed to adequately staff the forum with employees who could respond to questions and complaints, so the forums devolved into a kind of group therapy for customers. (Sometimes primal scream therapy.)
The moral of this cautionary tale goes beyond just the obvious: Don't irritate your customers. The other part of the lesson learned is: Don't promise a different type of relationship with the customer, and then fail to live up to that commitment. The discussion forum wasn't just a platform for customer dissatisfaction; it was also a source of that dissatisfaction. Comcast teased its customers with the community site, and then ignored it.
The transparent company is founded on a different sort of relationship with the customer, the sort that Comcast failed to deliver. A discussion forum is just one possible way to build this relationship. The forum is less formal than calling customer support, more open to other customers than the typical sales or support call, and more permanent in its results. Other users don't eavesdrop on your calls to customer support, but they'll see every response you give in a discussion forum.
If this type of relationship seems daunting, it's worth pursuing if for no other reason than to remove the competition from the picture. The more transparency you provide into the company, and the more effective you are at delivering value to the customer, the less reason there is for the customer to get distracted by bright, shiny things that competitors dangle in front of them. It's easy to see why it's easy for competitors to wind up on the sidelines. As our own research has shown, customers want to be understood more than they want to be impressed. Having a salesperson who understands the customer's needs and can suggest products or services is way more valuable than whatever deals get struck on a golf course between C-level executives, or snazzy demos at the launch event.
The picture to the right shows how this dynamic works. It takes dedication, skill, and effort to draw in customers this way. It also takes software development.
How did Comcast climb out of the deep hole it had dug? Software played a key role, as this blog post describes. Continuing to use the support forum as a benchmark, there needed to be dashboards depicting responsiveness in the forums, better analytics about customer activity on the site, connections to the CRM system, and all kinds of other tools that wouldn't exist without a dev team building or customizing them.
The analysts in the Application Development & Delivery team have been talking a lot recently about the choice between packaged and custom applications. (And we'll continue to discuss it at IT Forum, later this month.) From one perspective, the choice is less significant than it looks. Software development will always be necessary, especially if you embrace the transparent company model. Reports, workflows, and integrations don't build themselves. The odds that any packaged application vendor will be able to delivery exactly what you need is relatively low. Over time, you'll be changing those requirements, as you discard experiments that didn't work, think of new tools that you might want to use, and roll out these systems to more employees. The probability that a packaged application vendor will keep pace with these changes is practically zero.
Software development isn't just an aid to becoming a transparent company, it's a requirement of it. The transparent company is a good rationale for software investments, including changes to the development and delivery process (Agile, Lean, high-performance teams, etc.), which never come at zero cost. The transparent company is also a good benchmark for measuring the success of these efforts. Metrics are important, but so too is a vision of what success looks like.