Envision the end state and set a course (with flexible options over time). There was nothing wrong with the ECSS vision and its assessment of problems to be fixed and opportunities to be pursued. The bigger the program and the change, however, the bigger the leadership requirement. And if it's a big change, the CEO must lead -- leadership can't be totally delegated to the CIO. Additionally, the CIO needs to serve as the chief integration officer. To paraphrase Tiger Woods, don't take a golf shot if you don't commit to it 100%.
Set the criteria for how to chunk portions of the work -- by enabling implementation iterations, for instance -- much the same as in an Agile software development. The idea is to create a process that will achieve the vision based upon scope factors that include the following:
-- Number, complexity and size of processes/systems.
-- Mission (business) impact of processes/systems.
-- Costs versus benefits of the chunks, or iterations.
-- Change management difficulty (from users, leaders, and incumbent contractors to Congress).
-- Timing relative to other affected processes/systems/organizations (e.g. changing politics/missions that drive changes in priorities).
Use a hybrid contract strategy, with firm fixed pricing where requirements are nailed down and other types of contracts or task orders where the requirements aren't certain. Use a structured methodology, but don't let it use you. In the end, find the balance between true risk and reward for the scope and speed of the implementation.
Less is more, especially in the sense that government program management cannot become bureaucratic. Strict, 100% completion "waterfall" methodologies for major process reengineering and associated IT development will shoot down the best program. Lack of speed will also kill a program, as it did for ECSS. The entire government or industry team must clearly see that they are on the same flight.
Core mission or business capabilities requirements must drive the processes that are enabled by the IT implementation. They must also meet compliance requirements along the way, not just in the final tests. It's not about the software -- that's just a tool. Process automation isn't enough either; it is only part of the solution. An IT program's success is all about the mission/business value delivered by implementing improved processes. That means a holistic approach, in which documentation, training, etc., are given appropriate emphasis.
When ECSS crashed, it didn't take all the progress on data management with it. The Air Force learned a great deal about the importance of logistics data and the location of its authoritative sources. Those efforts must continue, regardless of the IT approach.
For enterprise-level, transformative IT programs, the CIO also needs to recognize that collaborating with the system integrator on strategy and tactics is critical to the program's success; technology and products take a back seat.
While IT infrastructure still needs significant improvements, implementing smaller "chunks" will make that process possible through continuous iterations. This isn't really a technology problem; it's more of about collaboration, how to use the technology, and the governance of standards, security and performance.
Federal CIOs can still meet mission requirements and capabilities and still create tremendous savings -- as in billions of dollars -- but only by learning these important lessons and reestablishing the confidence to get back on board and launch the needed modernization/transformation.
Bold visions are competing with practical budget realities for federal IT leaders. Our latest annual survey looks at the top IT priorities. Also in the new, all-digital Tech Priorities issue of InformationWeek Government: IT leaders are making progress improving the efficiencies in their IT operations, but many lack the tools to prove it. (Free registration required.)