by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
FCW : March 15, 2014
26 March 15, 2014 FCW.COM given to the integration management processes to be used throughout the life cycle of the program, again to lower overall delivery risk. The second element is ensuring a solid business architecture sup- ported by a solid technical archi- tecture. The business architecture describes the overall process of what the system must do to support the desired business or mission outcomes. There are many failure mechanisms for programs, but I am surprised by how often there is not a solid high-level business architecture in place early in a program s life. That absence typically leads to major requirements changes during system development, testing and deployment. Further, there should be an effort to simplify, to the degree possible, the business processes and determine the minimum required capabilities for an initial system launch. That approach can greatly reduce program risk. Having a solid technical architecture in place, especially for a complex sys- tem with a number of subsystems, is also absolutely critical. If subsystems can be "bought" or repurposed from other systems that meet requirements, the government ought to do so. Buying rather than building lowers risk sub- stantially. There should be the proper use of off-the-shelf software compo- nents, whether they are offered by tra- ditional software vendors or based on open-source technology. There should also be overall sim- plicity in the technical architecture because integration of dozens of off- the-shelf components creates its own set of technical complexities. Problems with the technical architecture tend to show up late in the development life cycle during integration and end-to-end testing, typically resulting in perfor- mance and scalability problems. The third element focuses on orga- nizations roles, commitment and gov- ernance. There must be a program governance model in place that recognizes the proper roles and authorities of the important stake- holders, which include the business (or mission) organization, IT, procure- ment and privacy, among others. For IT programs, the business organization must be intimately involved in de ning requirements, making hard functional- ity trade-offs, and being a champion for the program with stakeholders both inside and outside the agency. The IT organization must ensure there is a capable program management of ce (PMO) using management best prac- tices to deliver large IT programs (deliv- ering on the rst key element above). In addition, there should be a formal program governance board in which executives from all the key stakeholder organizations meet regularly to support the program manager. Transparency and good communications among the stakeholders are critical for success. So many programs falter because the stakeholders are pulling the program in different directions; however, an effective governance structure will drive stakeholder alignment and pro- vide clear and informed decisions to guide the program manager. Executing elements one through three successfully, however, is not possible without a set of skilled and experienced employees leading the program. That goes beyond the pro- gram manager to include a require- ments manager, systems architecture lead, test manager, deployment man- ager and others. For federal programs, my experience is that having govern- ment employees ll most of the leader- ship roles is necessary. Although con- tractor personnel can support a PMO, it is dif cult to have them in leadership roles given the need to build strong and trusted partnerships with other government stakeholders. The fth and nal key element is developing the proper relationships with the contractor or contractors supporting the program. Most gov- ernment agencies cannot execute large IT programs without outside support, and those relationships have both for- mal and informal aspects. The formal aspect is the contract in which the scope of work, terms and incentives are codi ed. That is where the procurement organization, with the contracting of cer or of cers being part of the team, needs to work closely with or even be embedded as part of the PMO to make sure contracts are structured to best support what the program is seeking to achieve. The informal aspect is the manage- ment of the contractors via the PMO. I always look for a program in which the contractors are well integrated into the program and clearly understand their role and the roles of others, and there is open and candid communications among the parties. That type of envi- ronment will enable team members to identify issues early, share and discuss innovative ideas, and make informed decisions. In subsequent columns, I will dive deeper into each of those ve areas and draw on my experience in effectively implementing them in government IT programs. ■ CIOPerspective Richard A. Spires has been in the IT eld for more than 30 years, with eight years in federal govern- ment service. Most recently, he served as CIO at the Department of Homeland Security. He is now CEO of Resilient Network Systems.
March 30, 2014