Jun 042015

Recently, I published a five-part series of videos about application lifecycle management (ALM), summarizing a lot of what I’ve learned about the subject. Probably the two most important points are the following:

  1. ALM is a strategy, not a framework, a methodology, or a bunch of tools.
  2. Software innovators, from IT departments to Silicon Valley start-ups, need to overcome their confusion over what a strategy really is.

The videos already make the arguments behind these two points, so I won’t repeat them here. Instead, I’ll focus on a practical issue, knowing the difference between a real strategy and an imitation of one.

Many software companies define their strategy as a series of initiatives. Some representative examples include, Build mobile apps, Everything must integrate with our new product, or Support our efforts to break into this new market. The larger the company, the more products in its portfolio, and the greater its ambition, the more initiatives it’s likely to pursue.

There are many common problems defining company or product strategy in these terms, and most of them take the form of strategic disconnects. Say that you are leading the development effort in a product team. How do you know which initiative among several deserves the most attention? Should you be giving only cursory support to the new product with which you’re integrating, or does the company’s fortunes depend, to a great extent, on the new product? Is your team’s part to play in the new market limited to the occasional support request from a salesperson, consultant, or help desk technician, or do you need to plan on significant changes to your product to meet the unique demands of this market? The extent to which you, as the team leader, cannot answer these questions, is the amount of strategic disconnection that exists in your software company.

The same problems exist in IT departments when IT strategy devolves into a collection of initiatives. Add up Harden cyber-security, Rationalize our tools infrastructure, Increase cycle time, and Use more infrastructure as a service, and you get…What? Some of these campaigns sound like opportunistic efforts to increase efficiency; others might be reactions to recent events, such as an embarrassing data breach. While these efforts might be necessary, to reduce costs and risks, they’re not enough, on their own, to help the IT department reach its objectives…Assuming, of course, the IT department has clear objectives.

The absence of a “grand strategy” for software innovation is often at the core of an organization’s woes. For corporate IT, defining itself as a partner with the business, versus a utility, or overhead to be outsourced, is the barest of beginnings.

I usually cringe when I hear someone else bring up Apple as a model for other software innovators to emulate. The analogies often don’t work. IT organizations won’t be making iPhones. ERP software companies won’t have the luxury of building systems as simple as a music player. Therefore, it’s a special occasion when I use the A-word in a blog post:

If you want to innovate as effectively as Apple does, have a real strategy from which all decisions, at all levels, flow.

Apple suffers from few strategic disconnects. We all know what Apple’s grand strategy is: Design very appealing products that provide people with capabilities they never had before. Your entire music collection in your pocket. Put a world of mini-applications on the same device that you use as you phone. Ditch the laptop for something you can hold in one hand. Apple’s successful ventures have left little doubt how what happens at each level of activity contributes to this strategy. Whether the Apple Watch succeeds or fails, the physical design, software architecture, supply chain decisions, partner programs, and other efforts needed behind the Watch’s success fit within the same strategic framework.

The flow of information isn’t merely a series of directives going down the chain of command, but also up. Initial UX feedback for a product like the Watch, for example, might have a powerful impact on the product strategy as a whole. The Watch itself serves Apple’s grand strategy — or doesn’t, as some critics have argued. Either way, it’s clear what that grand strategy is.

ALM, therefore, is simply a way of expressing the multi-level nature of software innovation strategy. It lives above the level of a methodology, such as Agile. It lives below the grand strategy of the organization, helping to fit software into that strategy. You can diagnose how well ALM strategy is working by assessing the flow of value through the innovation process.  That’s a lot more demanding than pushing a bundle of initiatives. and a lot more rewarding.

I’ll have more to say about ALM in future blog posts. In the meantime, enjoy the videos, and by all means, feedback on them is welcome.


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>