Program/Project Management

Program Management Improvement Accountability Act – Now What?

By: Neil F. Albert

At the end of 2016 the Program Management Improvement Accountability Act (PMIAA) was passed into law (Public Law No: 114-264).  Its purpose is to improve the program management practice in government agencies.  The law establishes as additional functions of the Deputy Director for Management of the Office of Management and Budget (OMB) requirements to:

  • adopt and oversee implementation of government-wide standards, policies, and guidelines for program and project management for executive agencies;
  • chair the Program Management Policy Council (established by this Act);
  • establish standards and policies for executive agencies consistent with widely accepted standards for program and project management planning and delivery;
  • engage with the private sector to identify best practices in program and project management that would improve federal program and project management;
  • conduct portfolio reviews to address programs identified as high risk by the Government Accountability Office (GAO);
  • conduct portfolio reviews of agency programs at least annually to assess the quality and effectiveness of program management; and
  • establish a five-year strategic plan for program and project management.

However the Department of Defense (DOD) is exempt from such provisions to the extent that they are substantially similar to: (1) federal provisions governing the defense acquisition workforce; or (2) policy, guidance, or instruction of DOD related to program management.

Why Is This Important? 

For me this law raises several important questions. Does the government lack good program managers?  Are agencies missing a critical capability to ensure program success? Do government PMs have the knowledge and tools to manage their programs?  So many questions come to mind as to why this law was put in place, and by reading its intent, it appears that by adding more policies, standards, and oversight, we are going to make PMs more effective.

We cannot afford the many program failures we have had due to cost and schedule overruns and/or technical inefficiencies.  However, in my opinion, by putting all the requirements of this law in place program management improvement will increase only marginally if at all.  Instead what it will do is what government always does to solve its problems  – establish a new set of rules and regulations and have people in oversight positions ensure that everyone follows them. In other words, the problem is not with PMs lack of policies or standards, it is with the government bureaucracy, culture, and environment. The program manager needs the training, knowledge, experience, authority and responsibility to see the program successfully through its acquisition stages.  The way our Federal agencies are managed today, this is a challenge.

There are numerous reasons for government program management failures even with the best managers in place. The most notable ones are predominantly in the Department of Defense.  But there are plenty of failures across government to prove that something needs to be done to improve government program management results.

From my perspective, it needs to start by changing the way PMs in each agency are selected, trained, and managed. More importantly, PMs could be more effective if the requirements and acquisition processes were more closely aligned.

In 2011, I was part of a study completed by the Defense Business Board (DBB) to identify best business practices that could improve the intake and development of uniformed PMs. But the study really applies beyond those in uniform and could be extended to all federal PMs.

For years, the federal government has attempted to reform and improve the efficiency and effectiveness of its acquisition process (including Program Management).  Many PMs, senior officials, and others who were interviewed for the DBB study believe that PMs spend the majority of their time going from meeting to meeting and answering the same questions amongst the various offices. There are “checkers checking checkers” throughout the program management process, which is both inefficient and ineffective.

Most Federal agencies with large procurements face the same issue. In other words, PMs spend too much time managing the politics and the “process” rather than managing the business aspects. This creates problems in recruiting and maintaining experienced PMs. The new law appears to be putting on more processes which will further hinder the PMs from doing their job.  The only way to change this trend is to make an environmental and cultural change.  We need to give the Program Manager the freedom to do their job without the hindrance of politics and process.

What Needs To Be Done

  1. Selecting The Right Individuals

Key to ensuring effective program management is selecting the right individuals. By identifying the key traits necessary for effective program management work, the government can use that information to screen candidates.  Just because you fly F-22s does not necessarily make you a good F-22 Program Manager. For major acquisitions PMs need experience managing programs, bringing a real understanding and appreciation of what needs to be accomplished as a PM. In today’s environment, recruiting individuals with special skill sets (e.g., IT/Software/Cyber) is a priority. But this can only happen if government agencies build a culture and tradition that places program management as a career destination not just a stopping point.

  1. Training Is Critical

Understanding the practices, tools, and approaches to program management can be attained by attending PM development courses at universities, rotating across programs, or through mentorship. By being on an effective program management team, members will gain appreciation for the diversity of the job, and potential for growth. And through increased training time, PM team members will gain experience and situational awareness needed to manage.  Those with high-potential in the acquisition force could be given a tour in industry to gain business savvy on how industry does business.

  1. Giving Authority And Responsibility To Manage The Processes

What hurts the government program management field most is how they are managed, specifically, the PMs lack of authority and responsibility to make key acquisition decisions due to the bureaucracy and cultural traits found in government.

On the other hand, their industry counterparts have authority and responsibility because suppliers support a strong program management function with increased PM tenure, continuity and business acumen.  Industry PMs are typically in a line function and have career aspirations and planned destinations. Unfortunately not all PMs in government understand the business dynamics that drive suppliers and affect performance. With this additional acumen, they could be more productive and able to communicate with industry on a level playing field.

By aligning the requirements, resources, and acquisition processes more closely, PMs do not have competing goals.  The DBB study suggested that to accomplish this, it is necessary to make sure that those who are responsible for the requirements process and funding are also responsible for the acquisition process (i.e., the program manager). To accomplish this it is necessary to extend the capability/requirements process deeper into the acquisition process so that the cost and capabilities trades can be made earlier in the acquisition phase. This means redefining and expanding the PM role so that it is an effective integrator of requirements, resources, and acquisition. For example, the PM should be able to challenge the requirements that might be closely met by a reasonable cost/benefit trade off. Ultimately this will strengthen the program manager’s ability to challenge scope and requirement changes that increase schedule and cost.

What Will Work

The government spends almost $500B a year on acquisition.  Since the 1980s we have been trying to change the issues that drive poor program performance which lead to program failures.  Yet no matter what is done, we end up with the same results time after time. We do not need a law to make PMs more effective, we need the government’s bureaucracy to get out of the way of PMs who are looking to successfully meet the goals and intent of the programs they manage.  We need to build a culture and tradition in government for PMs who both do the right things and do things right without bureaucratic and political interference. Maybe this Act will help achieve that – maybe.

Richard Spires: Without strong Program Management; IT organizations are at risk

Program Management – Key to an IT Organization’s Success

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.

1. Mature Management Processes. 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.

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.

2. Solid Business and Technical Architecture. 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 organization 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.

3. Proper Governance Model. 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 organization, IT, Procurement and Security, 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.

4. Proper Contractor Relationships. The fourth key element is developing the proper relationships with the contractor or contractors supporting the program. Many organizations 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.

5. Skilled Employees – the right people, with the right skills, on the right projects. Executing elements one through four 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. I have found it critical that employees for the organization fill most of the key leadership positions on a program. 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 stakeholders. Given the importance of have a set of skilled and experienced staff to run a program, it is crucial that an IT organization have the culture and make the investment in developing such staff. It is the number one priority for creating a successful IT organization.