Principles, Processes, and Practices of Project Success

Introduction To The 5 Immutable Principles of Project Success

The Five Principles for increasing the probability of success for any project are:

1. What does Done look like?

Successful projects deliver business or technical capabilities to solve problems, accomplish a mission, and provide a service. Those paying for the project bought this Capability, not the work effort, cost expenditures, documentation, test results, or processes that delivered the Capabilities. These are all needed, but they are not the Value of the project.?For success, the project must deliver tangible beneficial outcomes, assessed in units of measure meaningful to the decision makers.

2. How Do We Reach Done as Planned?

First, we need a Plan. Plans are strategies for success. Strategies are hypotheses. Hypotheses require tests to confirm their validity. These tests are the outcomes of the work ? in the Schedule ? measured against the needed Capabilities of the buyer. The Plan has to state these upfront. Otherwise, we’ll never recognize Done.

3. Do we have enough time, money, and resources to reach Done?

A resource-loaded schedule is required to ensure our Plan has the proper probability of success.

4. What impediments will be encountered along our way to Done?

For project success, we must apply Tim Lister’s simple concept ? Risk Management is How Adults Manage Projects. All risk comes from uncertainty. Uncertainty comes in two forms ? (1) reducible (epistemic) and (2) irreducible (aleatory).

Reducible risk is addressed with risk buy-down activities, paid for by the customer. Margin – cost, schedule, and technical margin- address irreducible risk.

5. What units of measure are used to confirm our progress to plan toward Done?

Progress in planning for successful projects is measured as the physical percent complete, not by the passage of time or the consumption of money. I am working on products at the planned time, for the planned cost, and compliant with the planned measures of effectiveness and performance measures.

That’s the Five Immutable Principles of project success. I’ll be posting in the coming weeks about the details of each of these Principles and their Processes and Practices. All are needed to increase the Probability of Project Success.

What Does Done Look Like?

With the Five Immutable Principles in hand, let’s start with What Does Done Look Like? To answer this question, we need units of measure to define what this means.

This first principle, when missing, is a primary root cause of project failure. Projects many times start with the notion of requirements gathering without the understanding of how each requirement is traceable to the capabilities needed to accomplish the project mission.

Starting with what Done looks like in units of measure meaningful to the decision-makers lays the foundation for project success. [1] These units of measure start with the Effectiveness and Performance of the project outcome and their ability to accomplish the mission, fulfill the business goal, or solve a problem. As well Technical Performance Measures (TPM) and Key Performance Parameters (KPP) are used to define further what Done looks like.

The document containing these four measures is a Concept of Operations (ConOps), a Statement of Objectives (SOO), or a business or technical strategy document. The ConOps documents the characteristics of a proposed system from the viewpoint of those using the system. It communicates the quantitative and qualitative system characteristics to all stakeholders, including those who will develop the project's deliverables.

These measures are defined as:

• Measures of Effectiveness ? are operational measures of success closely related to the achievements of the mission or operational objectives evaluated in the operational environment under a specific set of conditions. MoEs are stated in units meaningful to the buyer, focus on capabilities independent of any technical implementation, and are connected to mission success. MoEs belong to the End User.
• Measures of Performance ? characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. MoPs assure the system has the capability and capacity to perform and are used to assure the system meets the design requirements to satisfy the MoE. MoPs belong to the project. They are developed by Systems Engineers and analyzed by project management and project controls.
• Key Performance Parameters ? represent the capabilities and characteristics so significant that failure to meet them can cause reevaluation, reassessment, or termination of the program. KPPs have a threshold or objective value, characterize the major drivers of performance, and are considered Critical to Customer (CTC). The acquirer defines the KPPs during the operational concept development phase of the project.
• Technical Performance Measures ? determine how well a system is satisfying or expected to satisfy a technical requirement or goal. TPMs assess design progress, define compliance to performance requirements, identify technical risks, are limited to critical thresholds, and include projected performance.

These measures are connected in an example of a public safety surveillance system.

Without these measures defined, validated, and confirmed to be feasible, we’re lowering the Probability of Project Success (PoPS) before we even start.

Next week, let’s build the Integrated Master Plan and Integrated Master Schedule to implement the deliverables to fulfill the Capabilities, MOEs, MOPs, TPMs and KPPs.

What’s Our Plan to Reach Done as Needed?

Now that we have the description of Done in units of measure meaningful to the decision makers ? Measures of Mission Effectiveness, Performance, Technical Performance, and Key Performance Parameters, what’s the Plan to show up on time, on budget, having delivered the needed Capabilities for success?

First, let’s clarify some words. A Plan is a set of actions to achieve something in the future. Plans are strategies for accomplishing those achievements. Strategies are hypotheses that need to be tested to confirm that we’re headed in the right direction continually. The Plan defines the direction and the capabilities produced by the project along that direction.

The Schedule defines the work needed to move the project along the path toward Done, the order of that work, the outcomes of the packages of work, and the Technical Performance Measures used to assure the results meet the requirements.

A credible Plan and Schedule means there is a model of cost, schedule, and technical performance of the deliverables that can be assessed to assure there is a probabilistic confidence sufficiently high to assure those funding the project they will get want they are paying for.

Together these form the Performance Measurement Baseline. Constructing the PMB requires knowledge of the business requirements, skill in developing the Work Packages that produce the deliverables for these requirements, and discipline in assembling the cost, schedule, and relationships between the Work Packages. The discipline requires the most focus for the planners and program controls staff. With this discipline, the development of a credible baseline is possible.

There are three elements to the Performance Measurement Baseline.

The Technical Performance Baseline is the requirements flow down and traceability map for each deliverable in the program.

• A critical performance measure of the Technical Performance Baseline is the stability of requirements. The expected technical achievement for the actual progress is compared using periodic measurements or tests, starting with the Technical Performance Baseline.
• An important aspect of the Technical Performance Baseline is defining the units of measure for each deliverable that defines what “done” looks like at each incremental maturity assessment.

The Schedule Performance Baseline is the sequence of Work Packages and Planning Packages that produce the products or services from the program. This baseline contains the schedule margin needed to protect the delivery date from the reducible and irreducible uncertainties in the project. What these mean, how they’re derived, and how to use them will come in the risk management post. But for now, any project without risk management and schedule margin is late and over budget before it starts.

The Cost Performance Baseline is the “authorized time-phased budget?at?completion used to measure, monitor, and control overall cost performance on the program.” This budget is held in the Control Accounts, the Work Packages, and Planning Packages owned by the Control Account Manager.

With these three PMBs integrated into one, we can now ask what resources are needed to start the execution of the project.

Risk Management

I going to skip the 3rd Principle of resource management for now. Risk management is the next principle. The only premise about risk management comes from Tim Lister.

Risk Manage is How Adults Manage Projects

If risk management is how adults manage projects, here are some principles (sub irreducible principles) of project management.

These five principles are simple and obvious but difficult to implement. The reason they’re difficult is that most people shy away from risk. Managing in the presence of risk does not come naturally.

It is a learned behavior. And once learned it has to be practiced. But before it can be learned and then practiced, “managing in the presence of risk” must become part of the business culture.

Some cultures do this better than others. NASA is better than others. But even NASA has moved a risk-adverse culture in the past decades.

1. Hoping that something positive will result is not a very good strategy. Preparing for success is the basis of success.
2. Single point estimates are equal to 50/50 guesses in the absence of knowledge of the standard deviation of the underlying distribution.
3. The connection to value can only be made by connecting the cost, schedule, and technical performance of the effort to produce the product or service.
4. Risk management is not an ad hoc process that you can make up as you go. A formal foundation for risk management is needed.
5. Identifying risks is a good use of time.

Each of these 5 principles must be addressed by the risk management process.

Continuous Risk Management is based on the underlying principles, concepts, and functions of risk management. It provides guidance on implementing it as a continuous practice in projects and organizations.

Risk management is used to continuously assess what can go wrong in projects (i.e., what the risks are), determine which of these risks are most important, and implement strategies to deal with these risks. These principles are based on proven practices confirmed through research, field testing, and direct work with clients.

Risk identification is an ongoing activity that takes place during the routine program workflow. Project activities such as programmatic and technical meetings, telecons, reviews, and other forms of communication often bring to light program risks. When this occurs, we record and analyze the risk on a Risk Information Sheet. The process outlined below helps the program team identify and cope with program risks throughout the life of the program.

• The team identifies a list of potential risk items. Not all items identified are accepted. Risks can be current problems or potential future problems.
• A Risk Mitigation plan with action items and due dates is developed for each accepted risk item.
• The team meets regularly (every 2 weeks, for example) to assess risks and add new risk items, if necessary. See the Status section on Risk Information Sheet below.
• Risks are closed when all the actions to close the risk have been taken. Some risk items are closed quickly; others are open for a long time. Some are considered watch items, and the action plan kicks in once certain negative events happen.
• Action plans include second sources of some items, requirements redirection, different technologies, etc.
• Closed risks remain the base for future learning.

Continuous Risk Management, when performed successfully, provides several benefits:

• Prevents problems before they occur – identifies potential problems and deals with them when it is easier and cheaper to do so – before they are problems
• Improves product or service quality – focuses on the program’s objectives and consciously looks for things that affect quality throughout the program lifecycle.
• Enables better use of resources – allows the early identification of potential problems – proactive management – and provides input into management decisions regarding resource allocation.
• Promotes teamwork – involves personnel at all levels of the program.

Measuring Physical Percent Complete

With Done defined in units of Effectiveness (MOE) and Performance (MOP), with a plan for reaching Done at the needed time, for the needed budget, with the needed capabilities. With the risks mitigated or margin in place to increase the probability of success to arriving at Done, we need the means to measure progress toward Done now.

But before we can have a useful measure of progress to plan, we need a target for that performance. This was done in the first and second principles. What does Done look like in units of measure meaningful to the decision makers? We can use these targets to measure our progress by defining them up front.

From our first Principle, the meaningful measures progress to plan to start with the MoEs that tell us what the customer thinks Done looks like in their units.?The MoPs characterize physical or functional attributes relating to the system operation that the customer agrees are critical to the system's success and will be implemented by the provider.?MoPs tell us what the system needs to achieve to meet the MoEs. Certain MoPs are critical enough to program success that they are labeled Key Performance Parameters (KPP).?All performance measures must be translated into the engineer's language to measure progress.?Technical Performance Measures (TPM) represent that translation.

These Technical Performance Measurements take place within a performance measurement system to provide decision-makers with specific performance information on physical progress and budget expenditures compared to the execution plan.

Physical percent complete requires tangible evidence, not the usual tap-dancing assessment of “done-ness” we see many times. Physical percent complete means directly linking cost, schedule, and performance. It is an objective measure with tangible evidence of progress.?We’ve all had the experience of a control account manager (e.g., the lowest practical level of management control) determining the percent complete by eyeballing the work effort.?This assessment often differs from what is actually being performed on the program for the same work.?

This disconnect between the reported measures of progress and the actual measures of “done-ness” is a clear sign that program performance measurement gaps are going to materialize before the Program Manager can take corrective action.

This completes the quick survey of the Five Immutable Principles of Project Success.

The next series of posts will put these principles to work along with the Processes and Practices, so success can start to be achieved. All these moving parts are connected in the following way…

Capabilities-Based Planning

One of the root causes of project failure is the apply the First Principle of the Five Principles of project success …

What does Done look like in units of measure meaningful to the design makers?

With the Five Immutable Principles of Project Success in hand, let’s start applying them through some Practices and Processes that implement those practices. There are 5 Practices needed to implement the Five Principles.

The first Practice is to define the needed Capabilities produced by the project. If we’re looking for the units of measure meaningful to the decision makers, they come from the Concept of Operations (ConOps). The ConOps described the user's operational needs, desires, visions, and expectations without being overly technical or formal.?The CONOPS facilitates a shared understanding of ideas, challenges, and issues on the possible solution strategies to the?problem at hand?without addressing the technical solution or implementation. ConOps is the first step in developing system requirements. Without ConOps, the requirements have no place to live.

The ConOps contains the conceptual view of the system and illustrates the top-level functional threads in the proposed system or situation. The CONOPS defines critical, top-level performance requirements (MOP) and business or operational objectives (MOE) stated qualitatively or quantitatively (including system rationale for these objectives).?

The ConOps is based on Systems Engineering analysis of criteria:

• Program risks - reducible and irreducible uncertainties that create these risks.
• Customer desires - in the form of business, technical, or operational capabilities.
• Funding constraints - how much money do we have, when can we spend it, and what's our management reserve?
• Market considerations - who's going to buy this? What's our competition?
• Technology considerations - what limitations do we have?
• Nature of the system to be developed – what are the basic processes of the system?

The objective of the ConOps is to:

• Provide end-to-end traceability between operational needs and captured source requirements.
• Establish a high-level basis for requirements that support the system over its life cycle.
• Establish a high-level basis for test planning and system-level test requirements.
• Support the generation of operational analysis models (use cases) to test the interfaces.
• Provide the basis for the computation of system capacity. Validate and discover implicit requirements.

The tangible value of the ConOps is ...

• The means of describing a user's operational needs without becoming bogged down in detailed technical issues that shall be addressed during the systems analysis activity.
• The mechanism for documenting a system's characteristics and the user's operational needs.
• The place for users to state their desires, visions, and expectations without requiring the provision of quantified, testable specifications.
• The mechanism for users and buyer(s) to express thoughts and concerns on possible solution strategies.
• Uses tools and/or techniques that best describe the proposed system from the user's perspective and how it should operate.
• Is written in the user's language.
• Produced with graphics and pictorial tools as much as possible, since a CONOPS should be understandable to different types of stakeholders.
• A detailed description of the operational environment gives the readers an understanding of the assumptions, constraints, numbers, versions, capacity, etc., of the operational capability to be used.
• The place where descriptions, such as a data dictionary, are in an appendix or incorporated by reference.

5 Processes That Implement the 5 Immutable Principles of Project Success

There are five processes needed to implement the 5 Principles of Project Success. These processes represent a sequence of activities that increase the maturity of a project or program's programmatic and technical aspects. The plans that result from these efforts describe the increasing maturity of the product or services that are the deliverables from the program.

These five processes are:

1. Identify Needed System Capabilities ? Define the set of capabilities (business, operational, or technical) needed to achieve the program objectives or a particular end state for a specific scenario using the Concept of Operations (ConOps). CONOPs is a verbal or graphic statement, in broad outline, of an assumption or intent in regard to an operation or series of operations, mission, or system.
2. Establish Requirements Baseline – defines the technical, organizational, and operational requirements that must be in place for the system's capabilities to be fulfilled. Define these requirements in terms isolated from the implementation details. Only then bind these requirements with the technical alternatives.
3. Establish Performance Measurement Baseline – build a time-phased network of scheduled activities describing the work to be performed, the budgeted cost for this work, and the organizational elements that produce the deliverables from this work. Define the technical performance measures showing how this work proceeds according to the technical and programmatic plan.
4. Execute the Performance Measurement Baseline – execute the Performance Measurement Baseline Work Packages while assuring all performance assessments represent measures of Physical Percent Complete.
5. Continuous Risk Management – identify, plan, and budget risk mitigation or retirement activities to assure impediments to progress are handled.

These five process areas must all be present in some form for success. Skipping any process area or performing the process area out of order Capabilities, Requirements, Baseline, and Execution, with Continuous Risk Management, lays the foundation for a Troubled Project.

Each process area builds on the previous area to increase the fidelity of the actionable information needed by the decision-makers. This method is independent of any specific development of engineering process – iterative, incremental, and linear processes are all equally effective.

These Five Processes are related in the following way

With the Concept of Operations in hand, we need to identify the needed Capabilities needed to achieve the project’s objectives or some end state for a specific scenario in the business. Using ConOps, we need to define the details of who, where, and how these scenarios will be accomplished, employed, or executed.

Here are the Process activities, their outcomes or deliverables, and the tangible benefit to the project that define what Capabilities are needed to fulfill the business or stakeholder's ConOps, Mission, or Vision.

10 Practices That Implement the 5 Processes and 5 Principles

With the 5 Processes, let’s look at the Practices that implement those processes. These Practices are focused on using Earned Value Management processes, Risk Management processes, and general government program management processes. Here’s the summary of these practices, and they are related.

The 10 Practices of Project Success guide the application of the Processes from the last post. These Practices encompass the entire life cycle of a project or program, from inception and the discovery of the business or system capabilities, through requirements elicitation, to the creation of the Performance Measurement Baseline (PMB), to the execution of this baseline.

The Practices provide several feedback loops to ensure that subsequent activities provide measurable information to correct gaps in previous activities. This iterative and incremental approach to program management assures the periods of assessment for corrective actions are appropriately spaced to minimize risk while maximizing the delivered value to the program.

The Principles, Processes, and Practices can be the basis of conventional Lean, and Agile program management methods.

The illustration below is the 10 Practices of Performance–Based Project Management?. Each Practice is developed in detail later in this handbook. For now, understanding the dependencies between the principles is important.

Let’s look at some of the details of each Practice

1. Capabilities Drive Requirements - Use these Operational Concepts (OC) to describe how the system achieves the beneficial outcomes before any commitments are made to the implementation.
2. Requirements Identify Technical and Process Deliverables - Derive the system requirements for each system capability. Could you make sure a requirement exists for each system capability needed to fulfill the mission of the system? Test requirements by answering the question, “why do we need this feature, function, service, or capability?”
3. Work Packages Describe Production of Deliverables -Work contained in the WP produces a single or small number of deliverables. Use performance measures at the Work Package level to assess the progress of the increasing maturity of the deliverables produced by each WP.
4. Master Schedule Sequences Deliverables - Arrange Work Packages in an unconstrained Activity Network. Define the Exit criteria for each WP that describes what “done” looks like and what technical maturity is needed to proceed to the next WP.
5. Progress Measured as Physical Percent Complete
6. Work Authorization Assures Work Packages Produced Planned Progress - Executing the Work Packages (WP) in the agreed sequence assures the program proceeds as planned.
7. Apply Earned Value Management to measure progress to plan - This post is too short for this topic, but OMB A-11 Part 7 describes how and why Earned Value Management is applied to Federal acquisition.
8. Technical Performance Measures assures progress to plan is delivered - TPM is a measure describing the technical attributes to fulfill the capabilities.
9. Performance Feedback adjusts the work sequence - Adjust the Work Package sequence using feedback from the performance measures to maintain compliance with the Measures of Effectiveness (MoE), Measures of Performance (MoP), and Technical Performance Measures (TPM).

Now for the Hard Part

With the Principles, Practices, and Processes in place, we need to pull all these together into a coherent program management process. Let’s review the Five Immutable Principles. I’ll use charts here instead of words since a Big Visible Chart is a powerful conveyer of information in ways words can never accomplish ? especially in the project management paradigm. Reports and spreadsheets can be read and then ignored. A large chart appropriately placed on a wall in the work area, showing the projects' current status, the work efforts' performance, and the expected outcomes is hard to ignore.

Let’s start with the Five Principles and answer to what degree of fidelity do I need to answer these questions, depending on the complexity of my project. Let’s have 4 levels ? minimal, minor, major, full up government compliance.

The needed Capabilities can be defined across these 4 levels.

The requirements baseline of the technical and operational requirements that implement the needed Capabilities can be defined in 4 levels.

Putting this work and plans on baseline can take on 4 levels as well.

Executing the planned work in the planned order can have different meanings.

Managing the risks from the project uncertainties can have levels of implementation as well.

Each of these processes supports the five Principles. Each can be tailored to meet the needs of the performing organization and the customer. Determining what level is needed for each process is part of the governance process for the project.

Increasing the Probability of Program Success (PoPS) requires asking and answering the 5 Immutable Principles. This is necessary but not sufficient. Health Factors are needed to calculate the probability of program success for success program. These health factors provide objective and quantifiable measures for comparing and evaluating the likelihood of success for a program.

This evaluation and comparison starts with determining the factors and issues that adversely impact the success of the program execution:

Program requirements

• Parameter requirements – progress toward defining capability requirements and meeting those requirements
• Scope evaluation – stability of capability requirements (scope or quantity) from the previously established baseline and the impact of requirements changes on program cost and schedule.
• Concept of Operations (ConOps) – Progress toward developing and using the CONOPS to inform program requirements and strategies.

Program resources

• Budget – sufficient current-year funding for the planned work
• Manning – stability, and adequacy of technical and managerial staff

Program planning and execution

• Cost and schedule estimating – Status of cost and schedule estimating activities, the confidence level associated with the current cost, and schedule estimate.
• Cost and schedule performance – measures of physical percent complete against the plan.
• Subcontractor performance
• Technical maturity – Identifying and tracking Critical Technology Elements to ensure sufficiently mature technologies.
• Program risk assessment – assessment of technical and programmatic risks, the risk handling processes, and the risk retirement plans embedded in the Master Schedule.

Managing Risk As an Opportunity

With uncertainty comes opportunity. But if a project manager is consumed with managing the risks, there is little time to manage the opportunities. Good risk management is not about fear of failure but about removing barriers to success. This is when opportunity management emerges.

Although risk management, as defined in PMBOK, is useful, a better paradigm to manage both risk and opportunity is “Managing in the Presence of Uncertainty.” Uncertainty is created when risks appear along the path to success. With uncertainty comes opportunity. If the project manager is busy managing the risks, there is little time to manage opportunities ignoring half the management in the presence of an uncertainty equation.?

Some useful definitions for risk/opportunity management:

• Risk – a potential problem or threat that could affect a project’s ability to meet its operational capability and performance, technical, cost, schedule, financial, or other objectives.
• Risk Management – the continuous, proactive process of identifying and assessing program, and risk, defining appropriate risk handling strategies and plans, and monitoring those actions to completion.
• Opportunity Management – the identification of opportunities to help attain project goals and the identification and implementation of actions to capture those opportunities.

What is the Intention of Risk Management?

Actively managing risks can increase the probability that a project or program will have a successful outcome. This motherhood statement makes it clear that risk management is part of successful project management as a strategy. Risk management is not an event performed along the way but a continuous process.

Many books, papers, articles, and professional associations describe how to manage risk. One phrase a project manager uses is risk buy down, that is, the buying of information to reduce risk. The purchasing of this information can be explicit: buy a report comparing three products considered as an off-the-shelf solutions rather than analyze them as part of the project. Or, spend money building a prototype to test the structural integrity before committing to manufacturing. Or, pay for a public survey of constituents before rerouting a bicycle path.

The Umbrella of Program Governance

All of the topics – Principles, Processes, and Practices ? in this post belong under the Governance umbrella.

Governance is about decision rights, and those rights are focused on four processes areas:

1. Strategic oversight and planning — board and executive management level activities that increase the effectiveness of core business functions and their outcomes.
2. Business level planning and budgeting — management translation of strategies into business plans and allocation of capital, programs, projects, and operational effectiveness initiatives.
3. Operational effectiveness execution — value-creating implementation of plans and strategies, measures in units traceable to strategic initiatives.
4. ?Monitoring and control — project and program performance measures, corrective actions, and forecasting

Each of these process areas is driven by a larger umbrella of the Management of Change as the basis of all program operations and development:

Change Requests – add, change, delete – are the lifeblood of a firm's product and service offerings

• Defect corrections to existing baselines
• External changes
• Customer requested changes
• Product improvement and performance changes

Management of any change is required to maintain the following:

• Service level agreements
• The integrity of the code base for software systems or the integrity of the physical design for bent metal systems
• Operational integrity of the IT infrastructure

Management of Change is the overarching principle for everything we do.

With this governance model, the Immutable Principles, and their Processes and Practices, you are now ready to Increase the Probability of Program Success.

With this Governance model, the next question is, what’s the Value of Governance for project management and for the customer applying the Five Immutable Principles of Project Management?

Here’s a starting framework to answer that question:

The role of Program Governance is to …

• Connect project performance measures with business performance measures through policies, practices, procedures, processes, and tools.
• Measure and manage the spend for the value produced from project work, including software development, infrastructure, customer support, testing, quality assurance, validation, and other support functions.
• Make sure that organizations and individuals participate in our product development and sustainment processes through performance reporting and variance analysis against the planned performance of cost, schedule, and technical outcomes.
• Increase the maturity of product development, release, and sustainment processes to transform the organization and increase all work activities' effectiveness.

The Frame of operations for these governance models is to …

• Align the processes of project or service development, testing, quality assurance, release management, and operations with the business needs.
• Provide predictable, consistent processes that meet customer expectations.
• Enable efficient and effective delivery of products and services.
• Enable measurable, improvable processes that can be tuned for accurate delivery and overall effectiveness of?the product or service offerings.

Governance fills the gaps that naturally form between business and technical domains and between management and strategy. Technology and business are readily visible to senior management in traditional IT operations. The visibility into the “white space” activities between technology and business is missing. Managing these gaps is the role of IT Governance.

• The “alignment gap” appears when IT investments are not traceable to business strategy.
• The “execution gap” appears when those tasked with delivering IT products and services don’t have a clear “line of sight” to the corporate strategy.
• The “innovation gap” appears when IT leadership and staff are not connected to the needs of the market, emerging technologies, and investment strategies for future needs.

This structure of Governance, using the Principles, Processes, and Practices of program management, is now the basis of Increasing the Probability of Program Success.

[1] “Technical Measurement,” INCOSE-TP-2003-020-01