The fundamentals of IT program management

A CIO at a Fortune 500 corporation once told me that the single most important factor affecting the perception of the IT organization is its ability to successfully deliver programs. I absolutely agree.

Opinions vary on how best to manage IT programs in government, including the role of agencies vis-à-vis contractors, best practices, effective acquisition life cycles and the best way to improve the procurements that support the programs. I will address those areas in a series of columns, but let’s start with the fundamentals.

When I am involved in establishing a new large-scale, complex IT program or assessing the health of an ongoing program, I address five key elements. Each is critically important, and if any one of them is not being addressed appropriately, risk rises significantly and can lead to outright program failure.

Further, although it is critical to maintain constant vigilance regarding each element throughout a system’s design, development and implementation, most troubled programs make major mistakes right out of the starting blocks. Hence, I place tremendous importance on ensuring that a program properly addresses all five areas as it launches.

The first key element is ensuring that a set of mature management processes is used to run the program. There must be an appropriate system development life cycle, which lays out the approach or approaches that will be used to design, develop, test and deploy the system. For complex IT systems, such as HealthCare.gov, there might be different approaches for the various subsystems.

Modern development approaches, in particular modular ones, can help simplify and lower development risk. For instance, an agile methodology is appropriate for developing the user interface and business logic for customers to interact with a website. A more traditional development approach might be used for systems in which requirements and data specifications could be defined prior to development.

The program must also establish a robust set of project management disciplines, which include schedule, estimation, requirements, configuration and risk management processes. In complex IT programs that contain multiple subsystems, special focus should be 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 supported by a solid technical architecture. 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 system 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 substantially. There should be the proper use of off-the-shelf software components, whether they are offered by traditional software vendors or based on open-source technology.

There should also be overall simplicity 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 performance and scalability problems.

The third element focuses on organizations’ roles, commitment and governance. There must be a program governance model in place that recognizes the proper roles and authorities of the important stakeholders, which include the business (or mission) organization, IT, procurement and privacy, among others. For IT programs, the business organization must be intimately involved in defining requirements, making hard functionality 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 office (PMO) using management best practices to deliver large IT programs (delivering on the first 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 provide 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 program manager to include a requirements manager, systems architecture lead, test manager, deployment manager and others. For federal programs, my experience is that having government employees fill most of the leadership roles is necessary. Although contractor personnel can support a PMO, it is difficult to have them in leadership roles given the need to build strong and trusted partnerships with other government stakeholders.

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.

The fifth and final key element is developing the proper relationships with the contractor or contractors supporting the program. Most government agencies cannot execute large IT programs without outside support, and those relationships have both formal and informal aspects.

The formal aspect is the contract in which the scope of work, terms and incentives are codified. That is where the procurement organization, with the contracting officer or officers 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 management 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 environment 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 five areas and draw on my experience in effectively implementing them in government IT programs.

Note: This article was updated on March 21 to correct an editing error that omitted part of the second-to-last paragraph.