Five Immutable Principles of Project of Digital Transformation Success

Editor's Notes

• #2: Digital Transformation means transforming legacy systems to ones focused on the digital experience of the customer. This is a transformation of business and organizational activities, processes, competencies and models to leverage the changes and opportunities of a mix of digital technologies and their accelerating impact across society in a strategic and prioritized way, with present and future shifts in mind. While digital transformation is predominantly used in a business context, it also impacts other organizations such as governments, public sector agencies and organizations which are involved in tackling societal challenges such as pollution and aging populations by leveraging one or more of these existing and emerging technologies. From “Digital Transformation: Online Guide to Digital Business Transformation,” https://www.i-scoop.eu/digital-transformation/
• #3: First, Digital Transformation is driven by rapidly-changing technologies. Its successful adoption depends on a sound strategy. Businesses that have successfully embraced Digital Transformation do not adopt individual technologies to solve their individual problems. They have a defined strategy and clear objectives for digitalization in place that aim to guide the transformation of their overall business, instead of ad hoc functions. The ability to digitally reimagine the business is determined by a clear strategy supported by leaders who foster a culture able to change and invent the new. While these insights are consistent with prior technology evolutions, what is unique to digital transformation is that risk taking is becoming a cultural norm as more digitally advanced companies seek new levels of competitive advantage.
• #4: The Customer Bought Outcomes No matter who the customer is, a commercial firm deploying and enterprise IT solution, to a government agency, it is the outcome of the project that was paid for. The work needed to produce this outcome, the materials that support the development of this outcome, all collateral activities from the project are not what the customer paid for. They paid for the beneficial outcome from their investment in the project. Performance–Based Project Management® starts with defining what that outcome is in terms of the capabilities provided by the project. These capabilities are the starting point for the project’s success. They are defined in Measures of Effectiveness. These Measures of Effectiveness (MoEs) are quantitative measures that provide some insight into how effectively a product or service is performing. MoE’s are derived from stakeholder expectation statements. MoE’s are deemed critical to the mission or operational success of the system. For example a MoE that defines a capability is: “95% of all work will be completed within 15 business days or the negotiated deadline.” This MoE is a description of what DONE looks like for the project. The project provided this capability.
• #5: While PMI provides a framework for managing projects, there is a larger framework needed to successfully manage a digital transformation project. Here’s a framework from Booze Allen Hamilton from the past, used for software intensive system of system work
• #6: The five immutable principles of project management are: Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now. Done must be defined in Measures of Effectiveness ,Measures of Performance, Technical Performance Measures, and Key Performance Parameters that must be met or exceeded for the project to succeed. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.
• #7: The five process areas of Performance–Based Project Management® are: Identify the capabilities needed to fulfill the mission, vision, business case, or any other forward looking description of the project. Identify the technical and operational requirements needed to enable the capabilities to be fulfilled. Define the cost, schedule, and technical performance measures of the work activities needed to implement the requirements. Determine how the work activities will be measured to assure their planned performance is being achieved. Identify and handle the impediments to progress for the project.
• #8: Projects consist of a collection of problems and needs living in a specific situation and context, with a customer seeking a solution. Performance–Based Project Management® provides a framework for addressing each of these elements in a cohesive and consistent manner, while providing visibility to the project’s performance in units of measure meaningful to the decision maker.
• #9: The five process areas of Performance–Based Project Management® are related to each other in the following manner. Identify Needed Capabilities to achieve the program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measures of Effectiveness (MoE) meaningful to the customer. Define The Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer. Define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology. Build The Performance Measurement Baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work effort, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance plan. Execute the PMB’s Work Packages in the planned order, assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. Perform Continuous Risk Management for each Performance–Based Project Management® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.
• #10: When we say deliverable what do we mean? We certainly don’t mean the work effort or the cost absorbed during that work effort. We mean something tangible that benefits the customer. This tangible outcome must be assessed by the Measures of Effectiveness (MoE) that is a quantitative measure that provides insight into how effectively a product or service is performing. This product or service must provide the customer with a capability to do something tangible, something measurable, something that benefits the business or mission. The deliverable must be capable of being measured in some way as it moves from left to right in the schedule. As it increases in its maturity. The deliverable must be testable in some form. Testable Requirements are the starting point. The deliverables are produced through Work Packages – “units of work.” These Work Packages are resource loaded, have specific periods of performance, and produce a tangible, measurable outcome that can be traced to the requirements and further traced to the needed capabilities.
• #11: With these five process areas, the next level of detail is show here. These are a repeat of the Performance–Based Project Management® processes. A statement of intent is the starting point for the successful application of each process area. This statement is provided in the form of a question. What are the needed capabilities? What are the technical and operational requirements? What is the cost and schedule? What are the periodic measures of performance? What are the impediments to progress? By asking and answering these questions at every juncture of the program, the participants gain visibility into the performance of the program in ways not found in other approaches to program management.
• #12: When we start with Capabilities, we now have a description of what Done looks like for the project. Technical and Operatonal Requirements don’t say that in any units of measure meaningful to the decision makers. Capabilities do. They can state an outcome that is measurable in business terms. Some accomplishment for the business.
• #13: Transforming the System Capabilities into System Requirements begins with a narrative description of the needed Capabilities in some form meaningful to the customer. This sounds like a tautology – a Chicken or the Egg problem. But discovering the system requirements is difficult in the absence of some higher level description of the needed “Capabilities” of the desired system. The concept of a “Capability” is a capacity or potential: Provided by a set of resources and abilities. To achieve a measurable result. In performing a particular task. Under specific conditions. To specific performance standards. These four steps result in a Concept of Operations (ConOps) for the resulting system. The ConOps describes the systems application to the problem domain and how the system will produce measurable value to the user in that domain. The ConOps is the story of how the system will work when it is delivered to the customer.
• #14: Here are some examples of capabilities. They appear obvious. But in many instances this approach is missing. The requirements are not the starting point for the solution. In the absence of the capabilities statement and the Concept of Operations the user community may have trouble envisioning how the system will benefit them when it becomes available. The tendency to start with the requirements should be avoided. Requirements need a home, a reason for being. These examples are from actual projects. They represent clear and concise statements about the need for the system, the use of the system for the business or mission purpose, and how the end user will benefit from the system.
• #15: Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but statements of what the system should provide in terms of “abilities.” For example there are four capabilities needed for the Hubble Robotic Service Mission: Do no harm to the telescope. Change the Wide Field Camera. Connect the external battery umbilical cable. Attached the de-orbit module for later use. How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?” Capability statements can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission. Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that are fulfilled by the program. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means. Success means providing the needed capabilities, on or near schedule and cost. The concept of CBP recognizes the interdependence of systems, strategy, organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments
• #16: Requirements are the necessary attributes defined for an item prior to the efforts to develop a design for the item. System requirements analysis is a structured, organized, methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for the design or selection of those resources. Requirements elicitation acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources. The basic process decomposes a statement of the customer need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement which all other requirements and designs flow. There are two fundamental classes of requirements. The Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer. The Product Performance Requirements define the product specifications and how they are related to the process requirements.
• #17: Poorly formed requirements have been shown to contribute as much as 25% to the failure modes of programs and projects. Requirements engineering can be decomposed into requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Performance–Based Project Management® method concentrates instead on elicitation. This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques. This Performance–Based Project Management® method incorporates advantages of existing elicitation techniques while addressing the activities performed during requirements elicitation. These activities include fact–finding, requirements gathering, evaluation and rationalization, prioritization, and integration.
• #18: The first step is to separate “product” requirements from “process” requirements. The product could be a service as well, but the product (or service) is not the same as the process that delivers the service that may be enabled by the product. We can see there are several components of this separation. Later on in this session we’ll put this taxonomy to use with a process for requirements management. While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our efforts on important parts of requirements management, and reduce the overall effort of managing these requirements.
• #19: The time phased, budget loaded plan is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule and deliverables for each Work Package in the plan. 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. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. The concept of a Performance–Based Project Management® (P–B PM) is at the core are the units of measure of progress to plan. Deliverables are what the customer has paid money for. Deliverables contain the business capabilities, the associated value that fulfill the requirements of the business plan.
• #20: The critical success factor in building the Performance Measurement Baseline (PMB) is the decomposition of the system requirements into technical capabilities, then into deliverables that enable those technical capabilities, and finally into the Work Packages (WP)that produce those deliverables. The Principle of Performance–Based Project Management® using WPs includes: Defining the decomposed deliverables from the needed system capabilities in a Work Breakdown Structure or Feature Decomposition in a Product Roadmap. This decomposition process MUST be iterative and incremental. Assessment of the validity of this decomposition requires thought. The first decomposition is likely not the best approach. Estimating the duration and work effort for each WP. Duration and effort estimating is iterative and incremental, it cannot be a one–time effort. The initial estimate MUST be assessed after the assembly of the WPs into the Activity Network with inter–work stream dependencies. Only then can they be considered credible.
• #21: The time phased, budget loaded Plan is the primary assessment document for assuring the credibility of a program plan. This is called a Performance Measurement Baseline (PMB). The PMB is the baseline of the cost, schedule and deliverables for each Work Package in the plan. 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. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. The Technical Performance Plan is the requirements flow down and traceability map for each deliverables in the program. The Schedule Performance Plan is the sequence of Work Packages and Planning Packages that produce the products or services from the program. The Cost Performance Plan 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 Work Packages and owned by the Project Manager.
• #22: With the Performance Plan established, its execution becomes critically important. The execution process is called the “program rhythm.” This means the processes are performed in a repeated manner – at least on a monthly basis and many times on a weekly basis. This business rhythm must create actionable information for the program manager on a time scale that actually allows actions to be taken. These tangible, physical deliverables must be defined in the work packages created during the Planning process of Performance–Based Project Management®. The measures of physical percent complete can be applied on weekly boundaries in a variety if ways: To actually have weekly deliverables. Have apportioned milestones for each week. Have tasks that are one week long and record 0%/100% complete at the end of each week. In all cases, a measure of physical percent complete is mandatory if the program manager is to receive actionable information.
• #23: The focus of the Performance Plan execution steps is to physically assess the progress of the program in units reflecting the progress using three independent variables: Cost Schedule Technical Performance The traditional Earned Value Management approach uses three data sources, the budget (or planned) expenditures, the actual expenditures, and Value earned from the work captured from the Work. The comparison of budget versus actual expenditures indicates what was planned to be spent versus what was actually spent at any given time. The use of Value Earned indicates what was produced for that expenditure. With this approach the use of physical percent complete for the amount of work performed is a starting point. It does not indicate anything about the conformance to specification of the work produced for the amount of money spent. By adding Technical Performance Measures (TPM) to the analysis of Earned Value Management, the program manager can assess the actual progress of the program. Non–compliance with the planned Technical Performance Measures dilutes the performance measures of the program proportionally.
• #24: There is a big gap in many firms. The gap between what the Strategy says the firm is doing and the ability of the firm to achieve these outcomes. Having the Right Digital Transformation strategy, that describes the winning product or service, or an advanced technology that moves the firm to a better competitive position, can only be successful if solid execution can produce the needed outcomes. The Strategy must be able to deliver on the needed outcomes. Research shows the majority of companies aren’t very good at doing this. A Balanced Scorecard provides the means to translate high level strategy into actionable and measurable outcomes, while helping staff and others understand how they contribute to the results the firm is seeking.  Plans are of little use until they are properly executed. This execution process has specific steps that need to be performed in the proper order. Execution Is a Discipline ‒ No worthwhile business strategy can be planned without taking into account how to execute it. Execution is a systematic process of rigorously discussing how's and what's, questioning, tenaciously following through, and ensuring accountability.. Execution is the major job of a business leader. Many business leaders like to think that the top dog is exempt from the details of actually running things, that setting strategy from the mountaintop is enough. In reality, only a leader can make execution happen, through deep personal involvement Execution Must Be a Core Element of a Business Culture. Execution must be embedded in the reward systems and in the norms of behavior that everyone practices. Execution: The Discipline of Getting Things Done, Larry Bossidy and Ram Charan
• #25: Continuous Risk Management is based on the underlying principles, concepts, and functions of risk management and provides guidance on how to implement it as a continuous practice in programs and organizations. Risk management is used to continuously assess what can go wrong in programs (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.
• #26: Risk Management is how Adults Manage Projects ‒ Tim Lister. All risk comes from Uncertainty. Uncertainty comes in two types ‒ reducible (Epistemic) and irreducible (Aleatory). Reducible Uncertainty and its Risk can be addressed with specific risk reduction activities, funded by the program’s budget. Irreducible Uncertainty and its Risk can only be addressed with margin. Schedule margin, cost margin, and technical performance margin.
• #27: Risk is not a first order outcome. Risk comes from Uncertainty and Uncertainty comes in two forms. Research shows that the risk from irreducible uncertainty is the primary cause of project failure. This risk is only handled by margin Cost margin Schedule margin Technical performance margin This risk is Irreducible
• #28: Continuous Risk Management, when performed successfully, provides a number of 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 many effect 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.
• #29: The connections for continuous risk management all to be All in place and in operation for Risk Management to work. An important aspect of the Decision Analysis Process is to consider and understand at what time it is appropriate or required for a decision to be made or not made. When considering a decision, it is important to ask questions such as: Why is a decision required at this time? For how long can a decision be delayed? What is the impact of delaying a decision? Is all of the necessary information available to make a decision? Are there other key drivers or dependent factors and criteria that must be in place before a decision can be made?
• #30: Principles are the source of guidance for the Performance–Based Project Management® Practices. A principle is a “general truth, a law on which other are founded or from which others are derived.” [Webster] For the principles of program and project management to be effective they must : Express a basic concept Be universally applicable Be capable of straightforward expression Be self evident The 10 Practices of Performance–Based Project Management® guide the application of the process areas. 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 of Performance–Based Project Management® provide several feedback loops to assure that subsequent activities provide measurable information to correct gaps that exist in the 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.
• #31: 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. Establish Requirements Baseline – defines the technical, organizational, and operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from the implementation details. Only then, bind these requirements with the technical alternatives. 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. Execute the Performance Measurement Baseline – execute the Performance Measurement Baseline Work Packages, while assuring all performance assessments represent measures of Physical Percent Complete. Continuous Risk Management – identify, plan, and budget risk mitigation or retirement activities at assure impediments to progress are handled.
• #32: Here’s summary check list you can put in your notebook for the % Immutable Principles, Processes and Practices for increasing the Probability of Program Success (PoPS)
• #34: Here’s how the Principles, Processes, and Practices are connected.
• #35: Here are some starting resources for making strategies. There are 100’s of other resources, but Balanced Scorecard ha served me well for decades.