Reader Forum: Innovation

The quick, cheap path to innovation

An FCW reader says low-cost prototypes make it feasible to test new ideas

Recent changes to the technology landscape, such as cloud computing, lean/agile development processes, collaboration software and Web-oriented architecture, pose a dilemma for federal agencies: When should they adopt a new technology or process that appears to promise more effective or efficient services? And when should they hold back?

Although innovations offer the government an opportunity to provide new capabilities for less money, they also bring the risk of trying something new that might not work. However, we might face even bigger risks by failing to adopt cheaper, more secure and more user-friendly software and settling for a technology experience at work that is a generation behind what we can do at home. An emergent technology strategy allows the government to take advantage of opportunities while minimizing risks.

Such a strategy supplements a top-down, deliberate technology strategy to introduce new ideas to organizations. It arises from the successful tactical operations of the organization. We take small steps, measure the results and feed that information into the deliberate strategy. The approach allows for what Harvard Business School professor Clayton Christensen calls disruptive innovations — low-cost options that can move up-market to thrive.

For example, by building a cheap prototype of a system using free software such as Ruby on Rails, an organization can establish the value of a system and gain information from user feedback with minimal risk. It can measure successes and failures and adjust the strategy accordingly.

One constant request of mission managers in the government is that information technology projects deliver on time and within budget — with or without the use of new technologies. However, the process of inventing a new system is not predictable to a high degree of precision at the outset of a new project because there are often no analogous projects to use as a baseline for estimation. Susan Cramm, writing on her blog at the Harvard Business Review, suggests that many IT projects have “evolved beyond automating manual processes to changing how we think and behave” in unpredictable ways.

Cramm encourages us to adopt an incremental approach and treat the initial phase as an experiment in which we gather data on the benefits of the project and refine our cost estimates. That exploratory mind-set is needed to deal with new technologies and innovative solutions that use existing technologies.

It is much easier to take a small success, replicate it and scale it across an agency than it is to determine a prescriptive approach before implementation and bet the future on a single must-succeed project.

By using projects as laboratories from which we collect successful approaches and use them to enhance our deliberate strategies, enterprises can function as learning organizations that base decisions on real results.

When successful technologies and approaches emerge from project teams, it is not appropriate to declare victory and mandate homogeneity across the enterprise. Adopting an emergent technology strategy within a larger deliberate structure provides a way to pursue the successful innovations that will ultimately elicit superior performance from the government.

Editor’s note: McKnight wrote this article to expand on a comment he posted in response to a column by Michael Daconta ("6 tech trends government IT managers should be wary of"). If you are interested in contributing an opinion piece, please contact John Monroe.

Featured

Reader comments

Mon, Sep 21, 2009 Rich

So your solutions is to continue government waste with bloated management because they won't be needed anymore if you use an agile methodology? I think this article calls out the need for thinner management and maybe fewer layers. Why do you need to keep existing participants in the food chain? This is truly the problem with government. Either they need to adapt and become some sort of scrum master (pick your term), developer or find some place else to work. This may be an intimidating thought, but it's reality. If the "front end" people aren't providing any real meaning to the product because things are always changing, then it's obvious that they need to find a different way to help the project.

Thu, Sep 17, 2009 Jay Godse Ottawa, Canada

The thought of using agile methodologies to achieve effectiveness are heartwarming. Unfortunately, they are unlikely. Government IT projects have to go through a complex tendering process. This means that you need hordes of people at the front end of a project to write proposals, spell out terms of contracts, etc. Because this overhead is high, these folks prefer bigger projects. Because they "need" bigger projects, every feature must be specified up front, without real knowledge of what is actually needed. The folks doing this work have a vested interest in keeping it that way. If a new way of things cuts development costs in half, it only follows that project management costs also have to go down. If you need fewer developers, you need fewer layers of management and subcontracting, reducing the amount of money available for those folks. The net effect is that it is these trusted project & contract management teams that have the most to lose by adopting agile methods. They aren't going to hurry things along. Along with these agile methods, you have to figure out a way to give existing participants in the food chain (project managers, contract managers, developers, operations) a piece of the action by aligning their interests with those of the government IT group. That's a tough one.

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above