Resurrecting the program that perished

re-imagine, re-establish, and drive results



Projects and programs can fail mid-stream. When they do, they can be killed and quickly abandoned. The reasons for failure may be related to poor timing, poor management or poor delivery, but the purpose of these programs may still be sound – and valuable to the organization if implemented correctly. When it's time to revitalize a program, and it's your responsibility to bring it back to life, what do you do? In this white paper, I will share a case study of how we breathed new life into an enterprise architecture (EA) program that perished within a federal bureau that I will refer to as the Bureau of Government Services (BGS). With this new life came a renewed focus upon customers, solving their problems, and driving results – enabled by sound program management practices.

The first part of the paper will describe BGS and the circumstances under which the program perished. Next follows an explanation of why the Project Management Institute's (PMI®) The Standard for Program Management – Second Edition was leveraged. Then, I describe how our team used project management practices to work closely with stakeholders to re-imagine and re-establish how valued services would be delivered, giving new meaning to EA. Lastly, I describe the state of the program today, its value and the role project management practices play.


The EA program operated within the information technology organization within BGS, which was largely focused upon delivering tools and information that served the bureau's global mission. For many years BGS operated an enterprise architecture program that focused upon delivering Office of Management and Budget (OMB)-compliant diagrams and detailed reports that illustrated and explained the path to a new, better, technology-empowered future for BGS. EA's role was to satisfy mandates within the Clinger-Cohen Act of 1996 (Department of Defense, 2006), support business case development, and communicate long-term IT goals within BGS. But then things changed.

The bureau was faced with political and mission-oriented emergencies that required rapid decision-making and quick delivery. Transformation plans and diagrams, while compliant, had no practical value to IT stakeholders, business stakeholders, or partners because they were now off plan and had to react quickly. The then CIO had to make decisions how best to respond to new, unfunded demands. His choice: terminate the EA program and reallocate funds to delivery, and so passed the EA program.

For more than four years, the EA program within BGS had been abandoned. Its only remnant: a 300 page report on the future architecture for BGS. During those four years, a new CIO arrived with a vision to transform the BGS IT organization. His strategy to do so included reintroducing EA to actively engage and guide stakeholders through the transformation. While the compliance aspects of the EA program would still need to be met through data collection, diagramming and report writing, the CIO introduced a new requirement. The program would need to actively engage in change – not just describe it. To be successful, this bureau needed to:

  • radically change the meaning that EA had for stakeholders,
  • give EA new purpose centered around the operational goals of stakeholders,
  • offer technical resources to clarify issues, broker solutions, and guide technical and non-technical people to shared goals, and
  • deliver consistent service founded upon best program and project management practices.

It was time to resurrect the program that perished.

Applying the PMI Standard for Program Management

The Standard for Program Management – Second Edition, published by the PMI in 2008, describes generally accepted, good practices to establish and operate a program. It presents five-phases that characterize the full life cycle of a program (PMI, 2008):

  1. Pre-Program Preparations,
  2. Program Initiation,
  3. Program Setup,
  4. Delivery of Program Benefits, and
  5. Program Closure.

Our team referenced and employed the standard to revitalize the BGS Enterprise Architecture Program. To be successful at BGS, it was clear from the beginning that a new kind of program service model had to be employed. Our first step to accomplish this was to re-imagine how program services would be positioned and executed. Our next step was to re-establish the EA Program, but in a very different form, to operate and deliver value to stakeholders. Lastly, the program had to deliver results. Not just near-term improvements, but sustained service delivery over the long run. Exhibit 1, below, illustrates how the PMI's Program Management life cycle related to these objectives.

Program Management Phase Crosswalk

Exhibit 1 – Program Management Phase Crosswalk

Pre-program Preparations are focused upon understanding the environment in which the program will operate, influencers, program drivers, and expectations held by program stakeholders. This information is required to engage in the process of re-imagining a program's offerings. Armed with this knowledge, one can engage in a creative dialog to re-imagine the program operating model and shape program services to meet stakeholder needs.

Program Initiation elaborates upon what is learned during Pre-Program Preparations. More detail is captured and planning is initiated that will support the re-establishment of the program. What is important to remember here is that new meaning often requires nuanced changes to traditional EA Program services. While compliance was still a policy-driven requirement for the EA Program, it was not positioned in a way that was burdensome to key stakeholders. Program Initiation activities support the process of re-imagining by adding more specificity to the new value proposal. In addition, Program Initiation activities provide the groundwork for re-establishing the program through the creation of a high-level roadmap.

Program Setup further elaborates upon the analysis and planning captured in earlier phases. To re-establish the program, Program Setup activities produce the finer-grained plans. The activities collectively result in the development of a Program Management Plan and associated schedule. Execution of program-level processes is ready to begin at this point. In the Program Setup phase, the new service capabilities are initiated and value generation begins.

Delivery of Program Benefits and Driving Results are one and the same. In this phase, the new model for delivering value is executing. Program activities, benefits, and successes are reinforced through ongoing communications to break down lingering resistance to program activities. Here, communication plays a significant role in promoting the value to participants within the new service model.

Re-Imagining the Program

“You can make your pictures and reports, but I need to get real work done.”

At BGS, the lingering memory of the former program drove the need to re-imagine how to position the EA Program. As a result, Pre-Program Preparation practices were focused upon establishing a radically new meaning for EA in the minds of stakeholders – one that they valued. The stigma associated with the former EA Program and the fact that the organization operated without EA for five years had to be overcome through a creative process in which stakeholders helped shape the new program. The new program had to contribute to “real work.”

When I refer to the meaning of a program I refer to how individuals or groups of individuals perceive the program, its services, and impacts upon individuals’ or groups’ interests or needs. (Verganti, 2009) If a stakeholder has a positive perception of the program, that person will be more likely to accept the initiation of the program and support or consume the program services. If, however, the program is perceived negatively, there will be resistance to supporting the program. Pre-Program Preparation practices facilitated re-imagining the program through the following activities.

Pre-Program Preparation

Understanding program benefits

Benefits of the new program could not be dictated. They had to be formed through a dialog. Establishing the dialog at BGS was the first step in demonstrating a service-oriented program. Rather than taking an approach in which we declared “We're here so deal with us,” we asked questions and sought to understand stakeholder pain points and needs so that we could later craft our program to address them. We demonstrated that the EA Program was there to serve their needs.

Dialog with stakeholders was informed by research and analysis. Many resources were tapped for vital information that would inform a productive dialog with stakeholders. They include:

  • Strategic plans
  • Annual plans
  • Prior program products and plans
  • Agency Web sites
  • The code of federal regulations
  • Investigator General and Government Accountability Reports
  • Internal assessments
  • Newspapers
  • Associations, and
  • Contractors and partners

Developing a plan to initiate the program.

Armed with a full understanding of environmental factors, program goals, stakeholder goals, and knowledge of organizational weaknesses and pain points, a high level plan of action was developed. The plan made clear that the EA program manager, or Chief Enterprise Architect, had a full grasp of issues that the program needed to address. While still a high-level roadmap, the plan served as an indicator to stakeholders that the program was taking on positive meaning.

Defining and aligning program objectives

Through informal and formal meetings with stakeholders, one can define program objectives that resonate with program stakeholders. BGS program objectives took the shape of highly collaborative interactions with business units to facilitate progress. The EA program was not one that would drop a monolithic report on one's desk and declare they have the answer. Rather, the EA Program staff would be partners in the evolution of organizational capabilities to meet organizational goals.

Developing a high-level business case

Here, BGS painted a picture of a new operating model. A way of doing business that was grounded in collaboration, sharing of ideas, and joint identification and definition of standards and practices. The benefits statement was not one of financial savings, rather it was one in which shared goals could be established and project transparency was the rule. The cost? The cost was inclusion of the EA program team as facilitators and as technical reviewers of proposed changes. In this model, the EA program operated not as a compliance enforcer or of a reporting agent. The EA Program functioned as a catalyst for information sharing and decision-making.

Agreeing to checkpoints to ensure that the program remains on track

The final element of Pre-Program Preparation is the establishment of reviews to ensure that the program is performing. Several mechanisms were put into place. First, the Chief Enterprise Architect would routinely meet with senior stakeholders informally to ensure that they were happy with the services that they were receiving. Second, the Chief Architect would convene formal group discussions with stakeholders to capture feedback. Finally, performance metrics were established that the program would track to demonstrate value. Some metrics included issues resolutions facilitated, costs avoided through architecture reviews, and customer satisfaction ratings.

Program Initiation

The Program Initiation phase extends the preparation accomplished in the first phase. Program Initiation drills down into program specifics. The key output of this phase is a program charter that makes clear that the EA Program is targeted on the right value proposition and has a clear vision and means to deliver results.

Overall Results

Stakeholders at the Bureau of Government Services didn't want to be told what to do. They wanted to be empowered. Enterprise Architecture programs, while full of strategic potential, are often employed as a compliance reporting activity required by the Office of Management and Budget (OMB). EA products required by OMB are typically long architecture blueprints that are cumbersome to reference and often end up as shelf-ware.

By leveraging research, conducting analysis, and closely collaborating with stakeholders to identify how EA can serve the organization, EA was imbued with a new meaning that replaced the stigma attached to the former, failed program. Executing Pre-program Preparation and Program Initiation activities led to the creation of a charter that was both shaped and endorsed by stakeholders -- one that had meaning.

Re-Establishing the Program

BGS needed a deeper understanding of how the Enterprise Architecture Program was going to work. While a charter made clear the vision, goals, objectives and constraints, it did not make clear how the EA Program was going to provide value. Much of what the EA Program was going to do was well defined within the Federal Segment

Architecture Methodology (FSAM). This methodology outlined a series of processes, products, and goals associated with planning analysis, and reporting; however, it did not fully meet the objectives specified by stakeholders.

The FSAM was geared to delivering a report that contained analysis, recommendations, and a roadmap. It did not make clear how the EA Program would serve to facilitate change beyond the definitional role. The Program Setup phase was executed to more fully elaborate upon the charter's scope.

Program Setup

The BGS bundled the charter and plan into a unified document. This plan made clear what and how services would be delivered, why they were of value to the organization, how they would be monitored. Finally, it provided an annual schedule of activity milestones. Specifically, the plan addressed program:

  • Integration Management,
  • Scope Management,
  • Time Management,
  • Communications Management,
  • Risk Management,
  • Procurement Management,
  • Financial Management,
  • Stakeholder Management, and
  • Governance.

Tailored to the scope and scale of the BGS organization, these knowledge areas were addressed within the plan. Another perspective was supplied, too, that characterized the services to be offered by the EA Program. They included: Strategic- and Program-level Planning, Capital Planning and Investment Control Support, Outreach and Training, Governance Support, and Enterprise Reporting.

Overall Results

Two service areas, Outreach and Training and Governance Support, would serve as the elements most valued by BGS. Through these two services, the program could connect people and information through process in a way not available in the past. Outreach and Training would enable information sharing, information repository creation and management, and awareness. Governance Support would take the form of organizer and facilitator of technology review, selection, and integration. In this role the EA Program would become an active participant in decision-making, problem resolution, and technology leadership.

Driving Program Results

“This is exactly the information that we need. Let's get this out to all of the teams so that they can implement it”

Delivery of Program Benefits

Long gone are the days of data calls, reports from on high and obscure diagrams with little useful application. The Enterprise Architecture Program is an active, participatory organization that executes projects to deliver insightful analysis, useful patterns and approaches for technology modernization, and resolutions to issues that stall major projects. This program, resurrected from years of inactivity, now exemplifies how enterprise architecture should engage with stakeholders to deliver value.

Today, stakeholders see value more in EA personnel than in the reports. Knowledgeable EA practitioners personify architecture use through their interactions with people. These same interactions enable EA practitioners to engage at a level where they no longer need to perform data calls, thereby hiding burdensome compliance drills that once plagued BGS.

The program management plan outlines what, how, and when the EA Program will deliver value to the Bureau of Government Services. The Chief Enterprise Architect and his management staff execute the plan to facilitate transformative improvements across the organization. Program management processes provide the necessary rigor to deliver consistent results. Process adherence drives the ability to capture program metrics, which quantitatively characterize the contribution of the program to BGS and other stakeholders.


The PMI Standard for Program Management offers good practices that, when executed within the context of an organization's culture, constraints, and operational needs, can guide you to bring renewed value from a once failed program. The tools and techniques described within the standard helped us to re-imagine the potential of a failed program, engage stakeholders to imbue a revitalized program with new meaning and deliver real value to stakeholders on a daily basis.


Department of Defense (2006) Chief Information Officer, Desk Reference,Vol 1, Foundation Documents Retrieved from

Project Management Institute. (2008) the Standard for Program Management – Second Edition. Newtown Square, PA: Project Management Institute.

Verganti, R. (2009) Design-Driven Innovation: Changing the Rules of Competition by Radically Innovating What Things Mean. Boston, MA: Harvard Business School Publishing Corporation.

© 2010, Peter Wilson
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington DC



Related Content

  • Project Management Journal

    The Three Secrets of Megaproject Success member content locked

    By Shenhar, Aaron | Holzmann, Vered Past studies have often voiced concern that important megaprojects have repeatedly failed due to extensive overruns, misunderstanding of expectations, or both. In this article, we contend that this…

  • PM Network

    Tapping Out member content open

    By Greengard, Samuel Offshore oil rigs are going offline. Depressed prices, rising operating costs, aging equipment and, most importantly, tapped out wells have all contributed to a perfect storm: the need to…

  • Project Management Journal

    Innovation Resilience Behavior and Critical Incidents member content locked

    By Oeij, Peter | Dhondt, Steven | Gaspersz, Jeff | Vuuren, Tinka van Project teams carrying out innovation projects are investigated during critical incidents. Earlier, a Team Innovation Resilience Behavior (IRB)-scale was successfully applied to quantitative survey…

  • Project Management Journal

    The Successful Delivery of Megaprojects member content locked

    By Locatelli, Giorgio | Mikic, Miljan | Kovacevic, Milos | Brookes, Naomi J. | Ivanisevic, Nenad Megaprojects are often associated with poor delivery performance and poor benefits realization. This article provides a method of identifying, in a quantitative and rigorous manner, the…

  • PM Network

    Worth the Risk member content open

    By Jones, Tegan Every project faces risks that could push it off track. But not all risks are created equal. This year's PMI Project of the Year finalists navigated hurdles that threatened to disrupt entire…