The challenge of developing a capability

China has deployed its own aircraft carrier. The vessel is a rehabilitated Ukrainian carrier that China purchased in 1998. Unfortunately, China does not have pilots who have practiced landing a plane on an aircraft carrier, nor do they have any planes that are capable of landing on an aircraft carrier.

What’s the point? That it’s a lot more difficult to develop a capability than it is to build something. The obvious recent example from technology is the launch of Apple’s Maps application. Apple developed an iOS app that has all of the features one would expect from a cutting edge mapping application but they lack the capability to keep their own set of world maps accurate and up to date. For more on this, check out David Talbot’s article on the challenges involved in building a legitimate mapping application. As it turns out, most of the work is in building that capability.

The United States has been working on aircraft carriers for over 100 years. Not only can we build aircraft carriers, but we can also build the right planes, train the pilots, and train the rest of the crew of the aircraft carriers, many of whom also have very specialized skills. The US Navy also has the logistical capability to send an aircraft carrier most anywhere in the world along with the attendant fleet of ships to support and protect it. (For more, see the Wikipedia article on carrier strike groups.) China may have an aircraft carrier, but how long will it be before they have the equipment and expertise to conduct a pitching deck exercise?

From a software development perspective, it’s worth thinking about capabilities when you’re talking about projects. As I mentioned the other day, I’m currently working on analytics. It’s easy enough to set up Google Analytics on your Web site, but developing the capability to understand the reports and incorporate the analysis into your product plans is much more difficult.

That’s only the tip of the iceberg. There are other, specialized third party analytics tools, and from there, custom analytics software and data analysis. Beyond that, there’s the statistical math required to draw accurate and useful conclusions from the data you’re gathering, and spreading an understanding of how the math applies throughout the organization. There’s also the task of changing people’s approach so that they rely on data rather than anecdotal evidence when making business decisions.

Often it’s the case that the larger (or older) an organization is, the tougher it is to add a capability in the first place. It’s harder to teach 100 developers to use Test Driven Development and rely on continuous integration rather than traditional QA testing than it is to teach 5. It’s also harder for larger, older, or more conservative organizations to rely on a new capability that has been developed. It often happens that organizations put a lot of work into developing a new capability but they never really get comfortable enough to let it replace an old one.

If nothing else, when you’re discussing projects, it’s worthwhile to ask yourself whether the project leverages an existing capability or requires developing a new one, and planning accordingly. If a new capability is required, both the effort and the risk of failure rise significantly. I’d be willing to bet that Chinese aircraft carrier is never put into active deployment.