Products, not Projects

I’m sure the person who asked Benjamin Mitchell that question truly believed that “faster, better, cheaper” was valuable. I’d imagine that person values his or her work and considers anything that enhances that work to be beneficial. Unfortunately, that’s not always the case. If I create something that fails to meet your needs, my ability to do so “faster, better, cheaper” is supremely irrelevant. From the customer’s viewpoint, value will come from the capabilities that your efforts enable, not from the work itself. The product is the value, not the project.

It’s no secret that I’m skeptical of emergent architecture. Solving various small problems in isolation is not the same as providing a coherent solution to the overall business issue. In fact, focusing exclusively on lower level details may impede our ability to solve the larger issue:

Intuition does not adapt quickly to new situations and resists changes in scale. A retail cashier who is exceptional at serving customers and processing purchases finds new, perhaps overwhelming, challenges in managing the store. The cashiers natural intuitive ability to diligently manage a single customers purchases is overwhelmed when presented with many customers and many purchases. The culprit is the complexity of detail. Often referred to as an inability to “see the bigger picture”.

Gary W. Kenward , “The Systems Perspective”

Just as a system is more than a collection of components, the product is more than a series of projects. Tom Graves, in the slides for his BCS-EA 2012 presentation noted (slide #8):

Products always imply a service…

  • Whom do you serve, and how?
  • How will you know you’ve served?
  • How will you know you’ve served well?
  • Who decides?

The answer to the first and fourth questions, are obviously “the customer”. Questions two and three, however, can be trickier. Feedback is required to answer those. The advantage of frequent incremental delivery lies in the fact that feedback can be gained, both by the development team and the customer/product owner:

We all know the world is not flat, and Scrum is not a linear process. But some Scrum teams use feedback only to improve the process, and forget to apply it to the product. User stories are consequently turned into software without learning from the stakeholders and adapting the backlog. This wastes a massive opportunity: to ensure that the right product with the right features is created.

Roman Pichler, “The Scrum Cycle”

If process improvement is emphasized to the point of excluding product improvement, the feedback is wasted. Each release should be seen as an opportunity to reduce the divergence between the product delivered and the product desired. The smaller the divergence, the greater the value.

Focusing on the product aspect, which meshes well with DevOps practices, enhances application lifecycle management by tying budgets to business value:

Using a product management approach, the organization now has budgets for product teams instead of new development or maintenance. Budgets are no longer lumped together, but are instead dedicated to specific product lines. Each product team needs to make the case why their product needs funding based on the business value that it generates compared to total life-cycle cost. Using this approach, organization can now make business decisions as to which products to innovate on and which to cut or retire.

Fadi Stephan, “You Build It, You Run It”

This kind of holistic approach encourages customer participation in the process, setting up a virtuous circle of increasing value, increasing ownership and increasing satisfaction. Products with a high level of customer satisfaction (not to mention those that work on the teams developing those products) tend to do better over time than those without.

What do you do when you find yourself in quicksand?

Danger! Quicksand

What do you do when you find yourself in quicksand?

Climb out? Dive in deeper? Or flail around and hope it gets better?

More and more, corporate IT finds itself on the horns of a dilemma. The business wants more, delivered faster and cheaper, but IT’s budget for new development is constrained by support costs (as much as 75-80 percent). What is delivered often comes slower and at a greater cost than what would be available from an external provider. Ironically, this fact is often pointed out by the very chargeback systems that were designed to help control IT costs.

According to a study by Gartner and Financial Executives Research Foundation, Chief Financial Officers are already playing a greater role in technology decision making. A recent article on CIO.com highlighted a report written by The Economist Intelligence Unit for Dell Services in which two-thirds of CIOs consider their operations aligned with the business. Less than half of their CxO peers agree.

Before discussing how to resolve the dilemma, it’s useful to first look at how not to resolve it. Gojko Adzic, in his May 31 post How To Solve “Not Enough Time”, took on the issue of barriers to process improvement:

Many problems mask themselves as “not enough time”. Not enough time to test properly, not enough time to automate testing, not enough time to clean up code, not enough time to investigate issues or coordinate on what we’ll do… “Not enough time” is a pessimistic statement – we can’t do anything about it. Time flows at the same speed regardless of our intentions or actions. We can restate the problem into something more useful – “too much work”. Now that’s something that can be solved nicely.

It comes down to three steps:

  • kill software already made that isn’t needed.
  • kill software in making that won’t be needed
  • kill software that was not successful

The very first comment in response:

Doesn’t spending time to kill software that wasn’t useful require more time? If we have too much work now, do you really expect me to take on more work to kill unnecessary stuff?

In other words, “I can’t save myself because I’m too busy drowning”.

Addressing the issues facing IT today requires positive action. The cavalry will not come riding over the hill and save us, we must do it ourselves. Doing so will require a fundamental shift in the way IT views itself in relation to the business.

Three concepts are key to transforming IT’s role in the enterprise:

  • Customer Focus: The job of IT is not to provide technology, but to use technology to provide value. Doing so will require understanding the needs of business, both as individual units and as a whole. Fostering the partnership between business and IT must be made a top priority.
  • Alignment and Execution on Strategy: A coherent strategy that is clearly communicated and gains definition as it traverses the levels of the organization is most likely to ensure that efforts are neither wasted nor contradictory.
  • Active, Collaborative, and Innovative Governance: Providing greater value for less cost requires actively managing the enterprises’ technology portfolio. IT is uniquely positioned to provide both data and expertise to insure that optimal value is generated from technology investments and expenses, whether from internal or external providers.

Aspects of customer focus have been the topic of a number of posts. In “Holding Back the Tide”, I outlined the danger of being seen as the “Department of No”. This same theme appeared in “Deja Vu All Over Again”, detailing the prevalence of business users bypassing IT via cloud services. This is not to say that passively granting all wishes is the way to proceed; doing so can mean failing the enterprise as a whole which is equally your customer. Actively working with customers to try to find solutions that work for all concerned is far more likely to be successful than a curt denial.

TechRepublic’s recent “Good governance means reconsidering personal agendas” perfectly captured the essence of strategic alignment with this statement: “It means that the entire organization creates a partnership toward the common goal of laser focus on business outcomes”. Effective leadership develops a unified strategy and then ensures that the strategy filters down to the various components of the enterprise so that all are pulling in the same direction. This is not the same as micro-managing. Each unit sets the outcome to be attained by its constituent parts, each of which determine the best way to execute within the constraints they’re given. This provides both flexibility and coordination.

As I noted above, IT uniquely possesses the expertise needed to help insure that IT operations are aligned enterprise strategy and are both efficient and economical. This puts corporate IT operations in a dual role: coordinator of services and provider of services. It is a role that should be familiar: unless your enterprise builds its own servers, runs its own communications backbone, etc., some part of the IT role is already outsourced and managed. It is in the interests of both IT and the enterprise to have IT expand this across all areas. Rather than attempting to prevent use of mobile, cloud, etc., IT needs to be facilitating and managing so as to provide the best service to both individual units and the enterprise as a whole. This requires understanding the strengths and weaknesses of different options (in-house development vs. outsourced, owned infrastructure vs. cloud-based capacity, internally hosted applications vs. software as a service, etc.) and being able to provide guidance as to which option best fits the situation at hand. It requires being prepared to support the options chosen, regardless of whether those options are provided by IT or merely facilitated by IT.

Promoting the facilitator role is the missing ingredient for many enterprises. Chargebacks can be a very effective tool in understanding where the money is going, but are insufficient on their own. If the business has no official option to use another provider, then the chargeback is merely an insult. Giving them control is key to turning the business into a partner in the process instead of an adversary.

Effective Application Lifecycle Management and architecture need to be at the heart of the governance effort. Funds and staff can be freed up by culling redundant systems. Good architectural practices will help ensure that new development meets the needs of the business, and that existing applications avoid deteriorating. Promoting configurable applications that can be shared across the enterprise while still meeting the unique needs of disparate business units can also help in getting the most value out of both development and infrastructure.

Another extremely important consideration is tailoring the governance to the circumstances. One-size-fits-all schemes that attempt to impose the same process on all systems lead to unnecessary expense. Obviously the enterprise accounting system will be tightly controlled. If, however, every initiative is subject to the same restrictions, then innovation will be stifled. Taken to the extreme, this can lead to real cost issues: would you want to tie up a developer, tester, and project manager for every content change to the corporate web site? Low-maintenance, relatively self-service tools and services (collaboration, content management, reporting and business intelligence to name a few) can both increase customer satisfaction and lower costs.

There is no magic solution to the issues corporate IT is currently facing. The practices above can provide real value, but implementation cannot be a cookie-cutter process. Each organization’s circumstances and history impact on how and whether a given practice can be applied. What is universal is that inaction will not work. Flailing about and hoping that things will improve means that you sink deeper into the quicksand. At some point, your problem will be over, but not in the way you want.