Project Management Institute

Applying domain authority — How to uncover hidden risks in large programs

img

Deloitte Consulting LLP

When it comes to delivering strategic programs successfully, today's program management offices (PMOs) do not succeed consistently. According to the PMI's Pulse of the Profession® Report entitled Enabling organizational change through strategic initiatives (2014), only 52% of strategic projects/programs successfully reach their goals.

Traditional PMOs typically focus on delivering programs on time and on budget, without measuring business benefits. Many leading organizations are starting to shift to a higher-value approach with PMOs that focus on delivering strategic outcomes. One such approach that complements traditional program management is the results management office (RMO).

The central theme of this paper is to illustrate how program managers can leverage the principles of domain authority, a core concept of the RMO approach, to uncover hidden risks in large programs. In the first part of this paper, we introduce the concept of the RMO. Subsequently, we delve deep into domain authority. In addition to defining the key tenets and subfunctions of domain authority, we share a real-life implementation case study and discuss lessons learned.

The Results Management Office (RMO): Key Concepts

Definition: An RMO is an extension of the PMO that provides a framework for achieving the successful delivery of program objectives through an increased focus on strategic outcomes. An RMO addresses the limitations of traditionally designed PMOs by directly linking technology program operations with broader organizational goals, to enable program success better.

The RMO approach takes the traditional PMO functions of scope, schedule, cost, issue, and risk management to the next level through:

  • A deeper understanding of an organization's business objectives and alignment of a program's goals with those of the overall organization;
  • The incorporation of domain-specific knowledge to achieve integration;
  • An emphasis on the importance of organizational dynamics and human factors in program success.

Structure of an RMO

An RMO has four key functions: program strategy and mission alignment; domain authority; organizational readiness; and program management. These functions are built on the following four principles of success:

  • Consider how the program will matter to the business five years from now (program strategy and mission alignment);
  • Get people who really know the business and enabling technology, and let them drive (domain authority);
  • Engage your key stakeholders at the very beginning, and don't let go (organizational readiness);
  • Build on a foundation of sound program management discipline (program management).

Each of these functions has a number of key subfunctions, as illustrated below:

Key Functions of the RMO

Exhibit 1: Key Functions of the RMO

Differences between the RMO and PMO

The RMO possesses individual characteristics that differentiate it from the traditional PMO. The PMO focuses on execution of the program, while the RMO focuses on value and outcomes delivered to the organization by the program. An RMO has clear and strong executive management support, understands the organization's top objectives, aligns the program's objectives accordingly, incorporates program-specific or domain knowledge, and emphasizes the importance of organization dynamics and human factors in achieving program objectives. In addition, the RMO can more effectively manage the traditional PMO activities, including risk, schedule, cost, and scope management. The figure below provides a summary of how the RMO can extend the traditional focuses of a PMO.

Key Differences Between the Traditional PMO Approach and an RMO Approach Program Delivery

Exhibit 2: Key Differences Between the Traditional PMO Approach and an RMO Approach Program Delivery

In the next section, we will introduce and dive deep into the key tenets of domain authority—one of the four core functions of the RMO.

Introduction: Domain Authority

Success in large transformational programs is often dependent on effective collaboration between business and technology teams. Being the vanguard of program success, the PMO is often accountable to engage the right subject-matter experts (SMEs) and spark collaboration. However, in reality traditional PMOs frequently abdicate this responsibility to other departments or choose to play a backseat role. As a result, they become hapless bystanders when collaboration among important stakeholders falls apart and hidden risks reveal themselves late in the game.

The goal of domain authority is to engineer unprecedented levels of collaboration across the organizational silos and equip the program with the right leadership which can deliver a functionally and technically integrated solution. In the RMO, the domain authority function provides an extra edge to the program managers to help uncover hidden risks early in the program.
Next, we look at the key subfunctions of domain authority.

Deep Dive: Domain Authority

Subfunctions of the Domain Authority

Exhibit 3: Subfunctions of the Domain Authority

Solution Planning

What is solution planning?

  • Solution planning brings together expertise across the organization to develop the overall solution approach necessary for the program to achieve its objectives.
  • It defines the target end-state vision and the interim states visions needed to enable a smooth transition to the end state.
  • The key stakeholders in solution planning are the business sponsor, the technology sponsor, the chief enterprise architect, and critical members of their teams.
How Solution Planning Helps in Identification and Mitigation of Hidden Risks

Developing a program roadmap and a solution plan allows the early identification of high-level risks to the program. The program teams and departments involved gain early visibility into the implementation, enabling them to provide specific feedback on risks and concerns. Solution planning allows stakeholders to understand the risks and develop appropriate mitigation strategies, even before the beginning of the implementation. Solution planning also helps identify cross-program dependencies and high-level constraints to program schedule, resources, and costs.

Action Plan for Program Managers

img Identify key solution-planning stakeholders and determine their influences, expectations, and impact.

img Create a forum for the stakeholders to collaborate and collectively agree on the solution being developed.

img Work with program leadership to develop a program charter and program roadmap, documenting high-level requirements, constraints, assumptions and risks; use these to drive solution planning.

img Utilize the program roadmap (that identifies key milestones and inter-project dependencies) to monitor and review the active projects and evaluate progress towards project goals.

Without solution planning, key stakeholders, including program teams, are not aligned on the implementation phases of the solution. Miscommunication and misunderstanding of the transition and target state could negatively impact stakeholder buy-in and thus slow down program planning and delay approvals. Absence of a solution-planning function leads to unmitigated risks that may surface too late in the program to recover from.

Requirements Management

What is requirements management?

  • Requirements management focuses on eliciting high-level business requirements and decomposing them into specific functional or technical requirements that can be used to direct project teams. It also tracks bidirectional traceability of requirements from project to program to enterprise levels.
  • If there are changes made to baselined requirements, this function helps ensure that the changes are communicated throughout the program and its components.
  • The key stakeholders who should be engaged for requirements management are SMEs from the business and technology, solution architects, and critical members of their teams.
How Requirements Management Helps in Identification and Mitigation of Hidden Risks

By engaging the right SMEs for decomposing high-level business requirements and establishing traceability, program teams are able to validate that program needs are being met. They can identify missed requirements early, thereby reducing risks associated with scope creep. This function also provides the RMO the ability to consider the overall integrated solution when making scope and change control decisions. This reduces the risk of conflicting decisions that may not be identified otherwise.

Action Plan for Program Managers

img Identify key stakeholders who understand and provide requirements and build a working relationship among them.

img Establish program standards for requirements management—solicitation, analysis and specification guidelines, format (use cases, shall statements), repository (e.g., structure, attributes, traceability, linking), and quality.

img Develop and maintain a shared program repository for storing business requirements. Utilize tools that support traceability of requirements.

img Identify and allocate to projects any enterprise and program mandatory requirements (e.g., accessibility, baseline security requirements, privacy).

img Identify, track, and resolve cross-project requirements dependencies. This can be achieved by making sure dependencies were debated and priorities were agreed upon at the time of requirements definition.

Examples of What Can Happen When Requirements Management Is Not Considered

As a discipline, requirements management is not new. Traditional PMOs certainly do their bit to engage requirements managers and business analysts to document and manage requirements. The key difference in RMO, when it comes to requirements management, is how strongly this function is integrated with program governance. Too often, in a traditional PMO, business results and anticipated value from large program are lost as the individual programs focus on their specific requirements and make local decisions on scope and schedule. Undefined or partially defined requirements lead to a solution that does not meet the needs of the organization and often requires expensive fixes after implementation.

Technical Integration

What is technical integration?

  • Technical integration validates that the subcomponents built by individual projects in a program fit together to create the overall solution. It advises project teams on technology integration-related issues and provides them enterprise standards and guidelines on integration.
  • It coordinates with project teams in development and implementation of data and technical interfaces.
  • The key stakeholders who should be engaged for technical integrations are technology SMEs, infrastructure engineers, middleware SMEs, solution architects, and critical members of their teams.
How Technical Integration Helps in Identification and Mitigation of Hidden Risks

The technical integration function helps develop a detailed integration approach and plan based on solution requirements. Involving this function across all phases of the program delivery lifecycle can help identify issues throughout the lifecycle. PMs can use the integration program plan to identify deviations from it and flag integration risks. Once identified, the technical integration function helps develop or review mitigation approaches that align with organizational and program standards. The function also works closely with the development teams to conduct data and technical interface design and manage integration testing, thus providing coverage for issues that may come later in the delivery lifecycle.

Action Plan for Program Managers

img Identify key technical integration stakeholders and engage them early in the program lifecycle.

img Enforce integration guidelines and standards.

img Set up checkpoints on a periodic basis to ensure compliance with integration standards and guidelines and facilitate adoption of middleware tools within the team.

img Facilitate the resolution of technical issues and challenges within and across programs.

img Communicate the importance of integration to projects teams and obtain their buy-in.

img Allocate budget, resources, and schedule for performing adequate integration testing.

Examples of What Can Happen When Technical Integration Is Not Considered

Typically, integration across programs is considered during implementation and not during planning the overall program. When the PMO and integration teams work in silos, integration issues are not identified often and/or early, resulting in inconsistent fixes that require rework after implementation.

Business Process Management

What is business process management?

  • The business process management (BPM) function coordinates program-wide, end-to-end analysis, design, and integration of applicable business processes. It also measures the realization of the business goals defined in the program charter.
  • The key stakeholders who should be engaged for BPM are the business sponsor, business subject matter experts (SMEs), process engineers, solution architects, the change management lead, and critical members of their teams.
How BPM Helps in Identification and Mitigation of Hidden Risks

By understanding and documenting business processes, key stakeholders are able to understand the current state and future state view of day-to-day operations better. It improves the specificity of requirements and integration points, thus creating a more effective solution that aligns with the vision of the program. In certain programs, optimizing the business processes, while building the enabling technology, may extend the life and use of the solution.

Action Plan for Program Managers

img Identify key BPM stakeholders and initiate the conversation around business process optimization.

img Educate project teams on the importance of business process design and their role in achieving planned business process change.

img Plan for program-wide process analysis to determine opportunities for optimization.

img Maintain a repository of process documentation.

img Identify cross-project process dependencies and constraints and utilize SMEs to mitigate risks.

Examples of What Can Happen When BPM Is Not Considered

Technology is only an enabler of business process. When business processes are not analyzed and understood by the program team, the result is weakly aligned solutions, poor adoption, or even failed programs.

Solution Architecture and Engineering

What is solution architecture and engineering?

  • Solution architecture and engineering focuses on making sure the solution that is being developed is consistent with the enterprise architecture (EA) and engineering standards of the organization. This function should be tightly integrated with the PMO from the very beginning of the program.
  • During the planning stages, the overarching guidelines and EA governance policies will be referred to and agreed upon by the project team. During implementation, this function will provide periodic validation that the solution development and implementation is following the expected standards.
  • Functional staff across the organization—from process engineering/re-engineering, information management, platform infrastructure and engineering, and application design—would be some of the key stakeholders of this function, decomposing them into specific functional or technical requirements that can be used to direct project teams. They would also track bidirectional traceability of requirements, from project to program to enterprise levels.
How Solution Architecture and Engineering Helps in Identification and Mitigation of Hidden Risks

Solution architecture and engineering brings in SMEs who provide deep, technical expertise to the RMO. Without this function, the solution development may veer off course. Without the guidance of architectural standards, the resulting solution may be inconsistent with the standards of the enterprise. By keeping the EA function engaged before, during, and after implementing the solution, the RMO gains crucial expertise in identifying hidden technical risks.

Action Plan for Program Managers

img Identify key architecture stakeholders and enable them to monitor the solution's alignment to EA and other enterprise standards.

img Set up design review checkpoints to validate that the logical and physical design is consistent with the solution architecture and program roadmap.

img Communicate to validate the project teams understanding of the overall solution architecture and the team's role in designing and building to the solution to achieve target-state architecture.

Examples of What Can Happen When Solution Architecture and Engineering Is Not Considered

If solution architecture and engineering is not adequately engaged in developing and implementing the program solution, then the end product may have a number of technical deficiencies. Too often, programs are structured around fragmented technical teams, some of whom may be outsourced vendors. These teams struggle to collaborate and develop a solution that is properly integrated, functionally stable, and meets the standards of the enterprise. Solution architecture and engineering is the glue that holds these fragments together. Without them, the end product may have a number of deficiencies (e.g., problems integrating with other enterprise systems, performance and scalability issues, security flaws, and the like). Based on the organizational policies, the solution may not be approved for deployment by the EA function.

Technical Quality and Standards

What is technical quality and standards?

  • This function is responsible for coordinating and/or establishing technical and business standards that will be followed by the implementation team.
  • It also establishes and identifies quality management roles and responsibilities, defines quality assurance and quality control processes, and establishes guidance for quality checkpoint reviews.
  • The key stakeholders who should be engaged for this function are the quality center lead, the enterprise governance lead, the enterprise architect, and critical members of their teams.
How Technical Quality and Standards Help in Identification and Mitigation of Hidden Risks

The adoption of a common set of application, data, interface, and infrastructure standards helps to reduce architectural inconsistencies as well as to ensure a smoother “build-test-deploy” solution. Checkpoints defined at different stages of the program lifecycle are used to verify that the solution built is in alignment with the standards set by the program. Artifacts are checked against the standards and guidelines to identify any design issues. These issues are raised to appropriate functional groups to be resolved in a timely fashion.

Action Plan for Program Managers

img Collaborate with the process and standard owners to establish the appropriate standards and quality management procedures to be applied to the program.

img Communicate and enforce quality standards.

img Define quality checkpoints.

img Monitor and enforce quality of program and project deliverables and of other artifacts throughout the program lifecycle.

Examples of What Can Happen When Technical Quality and Standards Is Not Considered

The PMO is accountable to deliver a solution that meets the quality expectations of the key stakeholders. Following enterprise quality standards is key in defining and implementing the solution. If these standards are not followed, and adequate validation is not performed, the resulting solution may not meet the quality expectations of the stakeholders. For example, if the performance and scalability standards are not followed and not validated, the end product (e.g., a consumer-facing website) may not be able to handle the expected volume load of users after implementation.

Case Study: Implementing Domain Authority at a Governmental Tax Agency

Background

This large governmental tax agency processes millions of tax returns from individuals and businesses on a technology platform that was not designed or developed to handle this volume or complexity. In an effort to modernize its 1960's platform, the agency introduced a new technology program that intends to provide a technical solution, enabling flexibility to adapt to the changing regulatory, financial, and security landscapes. Taxpayers can expect faster refunds and more accurate processing of complex tax returns. The agency can be more prepared to fight security threats and stay in compliance with legislative mandates and financial requirements.

In order to successfully execute and deploy the solution, this agency realized that it needed to transform its program delivery function. It needed a high-performing, results-focused organization that would drive collaboration and accountability across all the departments involved in the implementation. It defined a new operating model that describes the functions, behaviors, processes, and interactions needed among the departments in the agency. Using this newly defined operating model, it was able to deliver large programs such as this one.

Program Management Challenges

Before the transformation, the agency faced critical challenges that added risks across all areas of the program:

  • Documented requirements had various levels of detail, which created difficulties during analysis and decomposition, thus resulting in misinterpreted requirements.
  • The agency lacked processes for developing integrated technical solutions at the enterprise or program levels, resulting in siloed systems that were not well integrated.
  • Cross-program communications were often ridden with organization barriers, making risk monitoring and mitigation difficult.
  • Programs outlasted the duration of the technology chosen, which resulted in obsolete technology.
  • Decision making was technology-driven, not value- or risk-driven.

Organizations involved in solution delivery had multiple priorities and protected their home turf instead of working collaboratively to find the best solution to achieve shared commitments.

—Project Manager

Domain Authority Implementation

The following facets of the program management operating model helped the agency overcome the challenges it faced with collaboration and risk management:

Program documents were used to guide the execution; these did not become “shelfware.”

The PMO created a program charter, a solution architecture, a program roadmap, and a program management and integration plan that outlined the program vision, the timelines (with clearly defined transition states), measurable success factors, and the roles and responsibilities of the organizations involved. Combined with the procedures laid out in the operating model, these documents became central to all program meetings and decision making. Program decisions were tied back to the vision of the program and aligned to requirements of the overall solution. Conflicts were resolved by collaboration with delivery partners and reference to the agreed upon roles and responsibilities. Key program decisions were not made in silos but were managed and approved using the structure defined in the operating model (by program managers, executive oversight team, governance board and advisory councils that supported the program). Decisions were made by evaluating the degree of risk and understanding their long-term value to, and impact on, the organization. They were not just focused on overcoming program constraints and deadlines.

The true potential of executive leadership and advisory councils was leveraged.

The program governance board, executive oversight team, and advisory councils were not used just to ceremonially kick off and conclude program phases. The advisory councils became a forum to discuss risks and review mitigation strategies associated with each risk. Since these advisory councils consisted of members who had visibility into multiple concurrent programs in the organization, they were able to identify interdependencies between this program and other programs or initiatives within the agency.

  • An executive oversight team was formed with members from the PMO, business, and IT organizations within the agency. This provided the ability for the PMO to voice opinions and concerns over organizational decisions that impacted the program.
  • The chief technology officer and the commissioner were committed to the success of the program. They actively participated in monthly program meetings. Program executives and delivery partners discussed the risks, challenges, key decisions, and alternatives, and they helped each other in breaking down barriers
  • An architecture and engineering review council (AERC), led by the chief architect and chief engineer, provided a forum to review technology decisions and risks. Major technical alternatives were reviewed by this council before final approval from the governance board.
  • An enterprise testing authority conducted new types of integration, performance, and solution assurance tests that were not part of the normal test procedures. Applicable integration tests were completed, defects were tracked, and test results were communicated to all stakeholders. This greatly reduced the rework and delays that would be caused by late identification of integration defects and issues
Deliverables were reviewed with a program lens.

The deliverable review process, which was called the integration review process, discussed the integration points and alignment with other deliverables, reviewed the dependencies with other programs, and validated the collective fitness for their purpose with overall program goals. It helped identify integration risks early in the lifecycle of the program, thus reducing the effort and time taken to address them. It helped maintain consistency across the program and compliance to enterprise and technical quality standards defined by the program.

PMO resources were dedicated for solution assurance.

The PMO defined additional roles and functions within its organization beyond the typical program management responsibilities. By doing so, the PMO was able to monitor and validate that the technology platform was well integrated and would meet the needs of its consumers today and for the long term.

What were the outcomes of the change?

Today, the agency is marching toward achieving the target-state vision for critical core systems. It has completed Phase 1 of the transition and is well prepared to begin the execution of the next phase of transition. Taxpayers are seeing faster refunds, and the business users at the agency can finally trust the financial reports coming out of the new technology system.

It added the following roles:

  • Chief architect, who was responsible for setting the overall technical direction;
  • Chief engineer, to ensure that only state of the art agency compliant programming languages, tools, and infrastructure were used;
  • Business modernization office, to liaise with multiple business users to align program requirements so the business spoke with one voice;
  • Program office management of integration and interdependencies among programs.

Lessons Learned

Some of the key lessons learned from implementing domain authority at the agency and other large organization include:

Solution assurance is as important as program compliance.

Delivering a program on time and under budget is commendable only when the program objectives are truly met. Taking steps to set up control processes and validate that all program objectives have been met is as critical as doing budget reviews.

Line of authority helps, but it is not the only solution to drive consensus.

Having dedicated resources in the PMO who can drive consensus and collaboration among the enterprise team definitely simplifies cross-organization communications. But a strong matrix, where the non-core PMO resources are borrowed from enterprise teams and do not directly report to the PMO, can also be leveraged for collaboration. This can be made possible by clearly defining the roles and expectations at the start of the program and obtaining the necessary buy-in from key leaders in the organization. For example, the chief engineer and chief architect in the case study mentioned were “borrowed” from the IT organization. The personal commitment of the commissioner and the CTO helped shape the shared commitment of all delivery partners and was critical in breaking down barriers that enabled the organizations to be successful.

Risk management does not stop with the mitigation plan.

Risk management begins with identifying the risk but does not end with just documenting the mitigation plan. Every risk mitigation plan should be reviewed by an SME who can truly evaluate the effectiveness and the impact of the mitigation plan on the overall solution and organization. Remember, a risk cannot be mitigated unless it is identified. It is the role of the PM to keep open channels of communication with the team to bring risks forward regularly

Meet to review risk and issues, not progress and status.

Program review meetings with program managers should focus on risks and issues and not on reviewing status reports. Meet often for shorter durations to drive collaboration among program teams. During these meetings, create an atmosphere of trust and confidence for project managers to share key implementation pain points, and work together as a team to resolve these issues. Lessons learned are more valuable during the implementation than after it.

Know your gaps and embrace them.

All requirements may not be captured before the beginning of the design phase. Critical program roles may not be staffed when desired. Key stakeholders may not sign off on a deliverable in a timely manner. It is the role of the PMO to understand these gaps and communicate them with an open mind. The PMO should work collaboratively with the key stakeholders to resolve them instead of documenting them and moving on.

Conclusion

There is more to collaboration than having a program plan with the right resources allocated. Through this presentation, our effort has been to establish a foundational understanding of domain authority and its umbrella organization, the RMO.

Within the RMO, the domain authority empowers program managers to break barriers and sustain collaboration across well-established silos. The mandate of domain authority is to create and sustain a well-orchestrated team effort that aligns the program solution to what the business really needs. It achieves that through a set of cross-functional capabilities that are traditionally outside the realm of program managers. Program managers do NOT take over these subfunctions; instead they find ways to integrate these into the delivery structure of the program seamlessly.

References

Project Management Institute (2014). Enabling organizational change through strategic initiatives. PMI's Pulse of the Profession® Report. Newtown Square, PA: Author.

Additional RMO Resources

WSJ CIO Journal: HCSC Manages to Results, Delivers Value
Link: http://deloitte.wsj.com/cio/2013/07/16/hcsc-manages-to-results-delivers-value/

PMOver: Transforming the Program Management Office into a Results Management Office
Link: http://www.deloitte.com/view/en_US/us/ba173000a210e110VgnVCM100000ba42f00aRCRD.htm

2011 PMI Global Congress: A New Approach for Enabling your IT Program to Achieve Results
Link: http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101334400

CIO Insight Magazine: Reinventing Program Management
Link: http://www.cioinsight.com/c/a/Project-Management/Reinventing-Program-Management-590438/

2013 PMI Global Congress: The Results Management Office: Moving from Process to Outcomes
Link: http://marketplace.pmi.org/Pages/ProductDetail.aspx?GMProduct=00101514200

As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.

This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication.

Copyright © 2014 Deloitte Development LLC. All rights reserved.
Member of Deloitte Touche Tohmatsu Limited

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014, Deloitte Consulting LLP
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA

Advertisement

Advertisement

Related Content

Advertisement