Capitol Management Consulting Services, Inc.
Follow on:

Portfolio & Program Management in an Agile Environment

Governance & Control in a Dynamic World

Over the past decade and a half, the Agile project management methodology has taken off and expanded from being used for managing software development projects to a generic framework which can be used in any IT and non-IT environment. However, as Agile has grown in popularity and use, many organizations have discovered there are a number of challenges involved with the Agile approach. In fact, the Agile framework’s greatest strength, the ability to quickly adjust in a dynamic environment, has become its worst enemy. While Agile projects are able to provide more meaningful project deliverables, organizations are now witnessing an increase in portfolio/program level misalignments and governance challenges. The focus of this white paper will be on the challenges organizations have found managing Agile projects in a Waterfall/Systems Development Life Cycle (SDLC) portfolio/program management environment.
Capitol Management Consulting Services, Inc. (CMCS) has found that while this is a wide-spread challenge facing its customers in the commercial, non-profit, and government sectors, there is a solution to their woes. With the support of its thought leadership team, CMCS has developed the VECTOR Framework which serves as a strategic planning and portfolio/program management framework suited to the unique needs of an Agile environment.

Agile and the Challenges It Presents to Portfolio and Program Management
Over the course of human history, mankind has created a variety of tools to assist with the execution of work. As the tools evolved, so did the processes by which work was completed. Starting around the time of the Industrial Revolution, tools and processes became increasingly automated and frameworks like the assembly line were developed to maximize the amount of output while minimizing variance. Over time, the nature of the work became increasingly complex with interdependencies between multiple moving parts, thus spawning the field of management.
For the majority of its life as a formal field of study, management followed a rigid, linear, and segmented approach, similar to the assembly line. Work was broken into a series of tasks which were completed in a set order with controlled amounts of concurrent work being done and minimal room for adjustment once down a path. However, as the field of management branched out into more industries and the availability of automated tools, computing power, and technology solutions increased, the way work was done also evolved. In the modern world, work is done quickly and cheaply with failure being an acceptable result as long as something is learned and the approach is corrected; the new mantra is “fail fast and fail cheap”. The business world has accepted the idea of controlled trial and error and evolving ideas as the process has become more affordable: The world has become Agile.
Born at the turn of century from the world of software development with the publication of The Agile Manifesto, the Agile project management framework was created to provide software developers with the ability to work more cooperatively with their business counterparts to shorten development cycles, allow for mistakes to be made and corrected quickly; and allow for greater flexibility to address user needs. The resulting approach made waves in the IT world and led to an increase in productivity and customer satisfaction while concurrently lowering overall costs. These successes inspired management teams from other parts of the business to learn about this new approach to project management and to develop ways to implement these same principles into their organizations.
The result is best captured in the following modified list of the twelve principles of Agile, as defined in The Agile Manifesto (

  • Our highest priority is to satisfy the customer through early and continuous delivery
  • Welcome changing requirements. Agile processes harness change for the customer’s competitive advantage
  • Deliver working product samples frequently, from a couple weeks to a couple of months, with a preference towards shorter timescales
  • Business and technical teams must work together daily throughout the project
  • Build projects around motivated individuals. Provide an environment and the support needed to complete the job and trust them to execute
  • Face-to-face communication is the most effective and efficient method of communicating information
  • Working product is the primary measure of progress
  • Agile processes support maintaining a sustainable pace of work. Sponsors, technical teams, and users should be able to maintain a constant pace indefinitely
  • Continuous attention to technical excellence and good design enhances agility
  • Simplicity – the art of maximizing the amount of work not done – is essential
  • The best solutions emerge from self-organizing teams
  • The team should reflect on how to become more effective at regular intervals, then adjust their behavior appropriately

While the Agile framework appears to be perfectly designed for the modern business environment, evidence gathered from actual implementations in organizations from a swath of industries says otherwise. From Capitol Management Consulting Service’s (CMCS’s) experience working with Federal clients there is a clear struggle to align their portfolio/programmatic budgeting and financial reporting obligations to the Agile framework. On the other end of the spectrum, CMCS’s commercial financial services clients have struggled to develop accurate ROI projections while staying on top of resource utilization. While there are a number of challenges with managing Agile projects at the portfolio/programmatic level, this white paper will focus on addressing governance and control at the portfolio and program management level.
Traditionally, most organizations are managed through the development and execution of strategic plans. The objectives defined in these plans transform into the organization’s portfolios and programs, which in turn ripples out to the projects. As a result, the governance and control structures used to manage portfolios and programs reflect the manner in which the organizational strategic plan is managed. At this time, the majority of strategic planning efforts are still managed using the rigid, linear, and segmented approaches which have been used historically. This same framework has trickled down to the portfolio and program management level on both the operational and governance and control sides. However, when projects are executed in support of these portfolios/programs, they are now often implemented using more Agile based project management frameworks. Due to these completely different and unsynchronized management frameworks, the source of a majority of the governance and control challenges facing organizations stems from trying to align projects with portfolio/programmatic goals.
The reason these management frameworks are unsynchronized stems from the fact that most strategic plans are developed during a single snapshot in time where changes to the environment are not actively considered and updates rarely occur. Historically, this was not an issue as the projects developed to support the implementation of these portfolios and programs were also developed, managed, and executed in a rigid, linear, and segmented manner. This allowed for better and easier synchronization between strategic plans, portfolios and programs, and projects. However, as more organizations began to adopt Agile practices and frameworks at the project level, the number of recurring challenges stemming from the misaligned frameworks rose. While Agile led to the successful completion of projects which met the immediate business needs of the organization, they did not always exactly fit into the portfolio/programmatic goals they were originally intended to address. This happened because while the projects adapted to fit the organization’s needs, as dictated by the business environment, the portfolio/programmatic goals of the organization remained static. Additionally, as Agile projects would develop over their lifecycle, the ability of senior management teams and Project Management Offices (PMOs) to manage budgets and conflicting scopes were hampered. With some projects managed in an Agile framework and others in a more traditional System Development Life Cycle framework, it became difficult to control redundant work and ensure all of the organization’s strategic initiatives were being appropriately staffed and funded.
In the end, organizations are struggling with how to govern and control the immediate benefits of working in an Agile or blended environment within their portfolios/programs. With this challenge in mind, CMCS developed the VECTOR Framework. VECTOR is designed to help clients manage the gap between aligning organizational portfolio/programmatic goals with the ever-changing needs of customers and stakeholders.

Developing the VECTOR Framework
The VECTOR Framework has been developed based on the experiences of the CMCS thought leadership team across multiple industries and functional verticals. It leverages best practices from the fields of strategic planning, portfolio/program management, project management, data-based decision making, change management, and kaizen/continuous improvement. Like other best practices, the VECTOR Framework is flexible enough to work across multiple industries and with organizations of any size. However, the success of the framework is based on custom implementations build around the development of appropriate supporting business rules, processes, controls, and tools.

Figure 1 – The VECTOR Framework
The figure above (Figure 1 – The VECTOR Framework) illustrates CMCS’s VECTOR Framework. The image starts from the top of the circle and continues around clockwise. The VECTOR Framework consists of six phases: Vision, Engage, Coach, Train, Observe, and Recalibrate. The cyclical framework is designed to facilitate continuous improvement and support the adjustment of portfolio/programmatic goals around feedback from the business environment while minimizing potential deviation from the organization’s strategic plan. Additionally, the framework does not define specific timeframes, which provides organizations with the freedom to drive change at whatever pace is most appropriate for them. CMCS has developed a set of formal deliverables which may be used once the framework is implemented. It is not necessary that all of the deliverables be formally created, but it is highly recommended that the thought exercises required to create these deliverables be completed as part of the process.

The following sub-sections define and outline the work to be done in each phase of the VECTOR Framework.

Each cycle of the VECTOR Framework begins with the Vision phase. During the Vision phase, key stakeholders, portfolio/program managers, subject matter experts, and the senior management team work together to define and/or update the organization’s portfolio/programmatic goals. The
portfolio/programmatic goals need to be completely defined by the end of this phase. Technical details, on the other hand, do not necessarily have to be defined at this stage. Decisions on direction and the level of detail required to define that direction should be driven by data and input collected from the customer and the organization’s projects. This will allow for the adjustment of existing portfolio/programmatic goals based on current information from the organization’s environment while concurrently minimizing the risk of “noise” driving to changes at the portfolio/program level.
By the conclusion of the Vision phase, all key stakeholders, portfolio/program managers, and the senior management team should have a common understanding of the organization’s direction and what is to be accomplished when the VECTOR cycle begins. It should be noted there may also be additional work around updating strategic planning documents.

During the Engage phase, the team developing the “vision” reaches out to the project managers, scrum masters, product owners, and project teams to inform them of the approved adjustments impacting their projects. This initial engagement serves several purposes including: initiating the work, updating functional/operational requirements and assignments, updating communication channels, understanding the needs/wants/desires of those directly impacted by changes, and identifying early adopters.
At the conclusion of the Engage phase, the organization should have a clearly defined set of projects needed in the cycle and a projection on where they will be at the conclusion of it. Portfolio/programmatic and PMO schedules will be updated and used to provide data around how the proposed changes will impact the needs of various stakeholders. Meanwhile early adopters who can help champion changes can be identified and engaged.
The Coach phase can run concurrently to either the Engage or Train phase, but can also run independently between the two phases. During the Coach phase, project teams within the organization take the information gathered during the Engage phase and work within their project teams to determine how the requested adjustments will be implemented. With the Scrum Master at the helm coaching, existing project teams will develop and implement operational level plans to coordinate between themselves and other project teams to ensure their project’s success. For new projects which may be kicked off during this cycle, Scrum Masters will begin forming and norming their teams and establishing their teams operational models.
For non-Agile projects, the coaching phase will allow project managers to work with their portfolio/program manager to evaluate available options and decide on changes required to support the portfolio/program. This may include modifying existing delivery projections, training new/re-assigned team member(s), or even halting work temporarily or permanently.

The Train phase may run concurrent to the Coach phase or after it. However, the Train phase is meant to primarily focus on addressing the technical/functional needs of project team members. If the changes made to the project have resulted in the need for team members to learn additional skills, this phase serves as an opportunity to train, or bring new team members with those skill sets on board.

During the Observe phase the PMO and portfolio/program managers observe and collect data around how the organization and its people are reacting to the implemented changes. This information may be collected via applicable performance metrics, during brown bag project review sessions, through surveys, or by gathering feedback from key stakeholders, customers, and project teams. The PMO, with the support of its portfolio and program managers, provides to senior management updates on progress, and assurances that the team is monitoring for new risks and issues. The information collected during this time will be used later in the Recalibrate phase and during the next cycle of the VECTOR framework.

During the Recalibrate phase the PMO and portfolio/program managers take the data gathered during the Observe phase and determine what minor adjustments or tweaks should be made to the current approach to ensure the effectiveness of the transition. Typically, these adjustments are limited and remain within the original scope defined during the Vision phase. If larger, more overarching changes are needed, those changes will be pushed to a new VECTOR cycle.
Chronologically, the Recalibrate phase will take place concurrently with the Observe phase. The Recalibrate phase is considered complete once the duration of that VECTOR cycle is complete. Once the Recalibrate phase is completed, a new VECTOR cycle initiates, driven by legacy data and the observations and data collected from the VECTOR cycle which just concluded.
The Benefits of the VECTOR Framework
The VECTOR Framework provides organizations with a customizable, auditable, and scalable solution to the challenges they currently face at the portfolio and program levels. By implementing the VECTOR Framework, organizations can address the root causes of their problems resulting from the desynchronization between traditional portfolio and program management frameworks and Agile project management frameworks. At the same time, VECTOR allows organizations to continue running projects using either the traditional SDLC or Agile project management frameworks while addressing governance and control reporting requirements.
However, the larger benefit is that the VECTOR Framework allows for more agile operation at an organizational level. By keeping in the spirit of “fail fast and fail cheap” approach, the VECTOR Framework allows organizations to adjust the work and structure of their portfolios and programs to their evolving business environment. The VECTOR Framework frees organizations’ portfolios and programs from being bound to a solution or approach which may be obsolete by the time all the related projects are completed. Instead, PMOs and portfolio/program managers can focus on addressing their customers’ current needs.
For additional detailed operational information on the VECTOR Framework and how it can be implemented within your business, please visit, or send us an e-mail at