« Quote of the Day | Main | Quote of the Day »

October 18, 2021

Compendium of Works to Increase Probability of Project Success

This collection of presentations, briefings, journal and conference papers, essays, and book content has been used to increase the Probability of Project Success (PoPS) written and applied over my career in the software-intensive system of systems and other business and technical domains.

These materials have been applied during a client engagement across a wide range of firms and domains, presented at conferences, published in journals and newsletters, books or chapters in a book.

Screen Shot 2020-11-30 at 10.59.48 AMFor each engagement, there are multiple domains, technologies, and processes as shown here (click on the picture below and the MindManager app will show you all the details)

Screen Shot 2021-08-01 at 3.15.08 PM

Download Things I know about and practice.html (2800.7K)

 

Table of Contents (Click the Name to go to Section)

The lastest items are at the top of the section

Presentations and Briefings

The following material comes from my speaking and writing for conferences, workshops, and materials developed for clients. The overarching theme is focused on defining what Done looks like in units of measure meaningful to the decision-makers, assessing progress toward Done and when that progress does not meet the needed progress, identifying the conditions and actions of the root cause of those gaps, and taking corrective or preventive actions to close those gaps.

Those units always start with Measures of Effectiveness and Measures of Performance. Without those, progress to plan can only be measured with the passage of time and consumption of the money.

While many of the presentations have similar titles, the content is focused on a specific set of processes and practices, while the principles are the same, since they are Immutable. The latest additions are at the top of the list.

Business, Technical, Systems, Risk, and Project Management

Management Processes

Managing projects in the presence of uncertainty means making decisions about cost, schedule, and technical performance, all risk-adjusted, from the uncertainties that create risk. Here are presentations and papers on how to manage in the presence of uncertainty, in a variety of domains. 

Project Performance Management

Project Performance Management means making decisions about cost, schedule, and project performance parameters (technical performance, measures of effectiveness, measures of performance, risk, schedule, margin management, resources), used to Keep the Program GREEN. 

Planning, Cost, and Scheduling

Planning, Cost, and Schedule management is the foundation of good project management. Plans are strategies for successfully delivering the needed capabilities created by the project. Scheduling is the sequencing of the work needed to implement the Plan. Both Plans and Schedules must be risk-adjusted with specific actions to reduce the reducible (Epistemic) risk and provide the margin for the irreducible (Aleatory) risk. The handling activities and margin must be included in the Integrated Master Schedule, with a budget for the reducible risk activities in the Performance Measurement Baseline.

IPMC/EVM World College of Performance Management (CPM) Workshop Materials

PMI Workshops and Conferences and PMSummit

PMI

PM Summit

AACE / ICEAA

Electronic Document Management / Product Data Management in Process Safety Management

These presentations focus on process safety management, document management, and change control

Client Presentations, Talks, Interviews, and Brown Bags

  • Managing Cost, Schedule, and Technical Performance Risk at Y-12, Increasing the probability of project success at Oakridge Y-12 Processing Facility
  • Assessing Enterprise Project Risk, the probability of success P(s) has four simple metrics - Requirements, Resources, Planning Execution
  • A Guide for Capital Managers: Five Immutable Principles of  Project Success, Safran Software Solutions is a unified project management expert and provider of world-class project management and risk management tools. This e-book speaks to how to be successful for all projects, no matter the domain with Immutable Principles of Success, not just capital projects, but all projects.
  • NES Jira Project Management Procedures, Program management procedures for Enterprise Agile projects in the presence of Federal and State compliance.
  • Calculating Physical Percent Complete on an Agile Project, Developing software using Scrum still needs the ability to determine the Estimate to Complete (ETC), the Estimate at Completion (EAC), and the Estimated Completion Date (ECD) when there is a fixed deliverable date, a fixed budget for that software, and a minimal set of Features and Capabilities on that date for that budget.
  • Agile Lifecycle, Product Roadmap, Release Plan, and Responsibilities, Capabilities, Features, Stories, and Subtasks, The core concepts of a Release-Based development lifecycle for NES projects. The lifecycle starts with the Product Roadmap, showing what Capabilities are provided in what order, in what Epic, to deliver the needed business value, on the needed dates, for the needed cost, with the needed Features.
    The Features and Stories that implement these Capabilities are traceable to the Product Roadmap to show Physical Percent Complete from starting at the Story flowing to a Capability to deliver a needed Capability developed for a State Public Health Insurance System.
  • A Workshop for Product Owners, Scrum Master, and Team Members for Improving Team Performance - The Scrum Master and the Product Owner is critical to the success of agile development teams using Scrum. Making changes to the process, improving team member's actions, and empowering members to perform Scrum activities correctly, to increase the probability of project success conducted for a Major Federal Agency, moving all the applications to a FedRAMP compliant Cloud.
  • A Gentle Introduction to Deliverables Based Planning - Traditional project management starts with the identification of the tasks needed to deliver the solution.
    Deliverables Based Planning starts by defining what “done” looks like, how we would recognize “done” when we encounter it, and what effort is needed to deliver “done”.
    By defining accomplishments and criteria first, the effort needed to deliver can be easily identified
  • Using CMMI as a Framework for Organizing Software Development Processes
  • Showing How to Increase the Probability of Project Success - All projects ‒  Traditional and Agile ‒ operate in the presence of uncertainty that creates risk. Five Immutable Principles and their supporting Processes and Practices can be used to increase the probability of success in the presence of these uncertainties.
  • Herding Cats with Glen Alleman: Episode 79 an interview by  PM for the Masses
  • Top Habits of Successful Project Managers 
  • Event-Based Scheduling a brown bag speaking to the problems of the project and their fixes
  • WSRI Agile Program Management Process, Applying Agile principles, practices, and processes to the CODE program. Building the Release Plan for each program event and the deliverables for that review. DARPA, Wright State Research Institute.
  • Using a Cross Walk File to Manage Givers and Receivers, a presentation to the Joint Space Cost Council at Ball Aerospace and Technologies Corporation, Boulder, Colorado, 21 September 2017.
  • From Needed Capabilities to Project Deliverables - On Time, On Budget, On Specification - the best communication inside and outside the project is a Big Visible Chart. 
  • From WBS to Integrated Master Schedule, a step-by-step guide to increasing the Probability of Program success starting with the WBS, developing the Integrated Master Plan and Integrated Master Schedule, risk adjusting the IMS, and measuring progress to plan in units of measure meaningful to the decision-makers.
  • Managing Government Grant Projects at Arizona Public Service The principles of project management found in the PMI PMBOK® are applicable to government grant projects – there are just a few more details that need to be looked at.
  • How to Build a Credible Concept of Operations and Use it to Derive Capabilities and Features, A Concept of Operations is a user-oriented document that describes system characteristics for the proposed system from the User's perspective. The CONOPs also describe the user organization, mission, and objectives from the integrated systems point of view and are used to communicate overall qualitative and quantitative characteristics to the stakeholders. 
  • IMP & IMS Getting Both Rights is Paramount, the WBS is the starting point for program success. The Integrated Master Plan tells us how the increasing maturity of the deliverables will be assessed. The Integrated Master Schedule tells us the order of the Work Packages needed to produce this increasing maturity. The Control Account Plan defines the authorized scope, budget, and period of performance of the work that produces the deliverables defined in the WBS, assessed in the IMP, and sequenced in the IMS.
  • Getting the WBS Right is Paramount, the WBS is the touchstone of all work activities, cost, schedule, and technical performance on the program. It describes technical, process, and programmatic deliverables over the life of the program. It describes how these deliverables are related through a well-formed tree structure defined in MIL-STD-881D. It describes how costs are assigned to work and how these costs roll up to their parents in the Control Account Plan and CLINS to the Performance Measurement Baseline.
  • Building the Perfect Schedule, You can't tell the players without the scorecard. The perfect schedule tells you what Done looks like when the work to reach Done needs to be performed, identifies the risk handling work needed to increase the probability of success, and the measures of physical percent complete to keep you going toward Done.
  • Event-Based Scheduling, Failed or underperforming projects are more common than not. Learning how to address one of the problems found in projects is the subject of this Brown Bag talk, 10 November 2006
  • Time Management According to Stephen Covey, habits are like a cable: We weave a stand every day and soon it cannot be broken. March 6, 2003.
  • The Simple Problem of Schedule Performance Indices, knowing how our project is performing means knowing how our Cost, Schedule, and Technical Performance is performing according to Plan.
  • An Introduction to IMP/IMS, in 2003, the Federal Government revised its acquisition policies with a procurement strategy focused on process improvement and acquisition reform implemented by Performance-Based Management, 17 Oct 2004
  • Building the Perfect Schedule, A two-day workshop, based on DID 81650, assembles a credible PMB to increase the Probability of Program Success (PoPS) for a defense contractor. August 23rd and 24th, 2011.

Project and Program Management Symposium (PGCS), Canberra, Australia

Agile Project Management

Managing agile projects have many of the same principles as traditional projects and have principles much different from traditional projects. Knowing what Done looks like on Agile projects is emergent but at the same time the needed Capabilities have to have some definition otherwise the developers won't know what to develop. A product road and a release plan contain the information about done. 

Risk Management 

Risk Management is Project Management for Adults - Tim Lister

  • "Managing Risk with Deliverables Based Planning," The  purpose of risk management is to make decisions, not sit around and admire the risk, from Rockwell Collins Risk Management Manual
  • "Building a Risk-Adjusted Engineering Estimate and Executing the Risk-Adjusted Product Roadmap," agile projects, like all projects, operate in the presence of uncertainty that creates risk. Estimates are required to make any credible decisions while spending other people's money in the presence of uncertainty.
  • "Risk Management Guidance," The management of risk is a critical success factor of any project or program
  • Two Chapters in The Practitioner's Handbook of Project Performance: Agile, Waterfall, and Beyond
    • Principles of Risk Management - all programs are affected by cost, schedule, and technical risks, credible by reducible and irreducible uncertainty
    • Practices of Risk Management - the practice of effective risk management starts with the needed discipline to produce a risk-informed actionable information
  • Risk Management Process, The Risk Management Process for the Defense Threat Reduction Agency program to produce an Ebola Anti-Virus for the US Army. This process uses Risk Radar from Mitre Corporation.
  • Risk Management Principles, Risk Management is essential to the success of all project work. Information about key project cost, performance, and schedule attributes are often unknown until the project is underway and changes are occurring during execution.
  • What is Risk?, Cost and schedule growth for federal programs is created by unrealistic technical performance expectations, unrealistic cost and schedule estimates, inadequate risk assessments, unanticipated technical issues, and poorly performed and ineffective risk management, all contributing to program technical and programmatic shortfalls.
  • Continuous Risk Management, Risk management is essential for the success of any significant project. Information about key project cost, performance, and schedule attributes is often unknown until the project is underway. 
  • Uncertainty and Resulting Risk on Project Management, It’s popular to talk about risk in straightforward approaches to managing risk. Like a step-by-step approach to making a list of the risk, assess the probability of occurrence and the impact of the risk were to occur. Then make a 5 × 5 chart with Green, Yellow, Red colors for the likelihood and consequences of any single risk and be done with it.
  • Informing Program Performance with Programmatic and Technical Risk, This guidebook provides hands-on guidance to program managers for identifying, managing, assessing, and suggesting corrective actions for program performance and programmatic risk impacts,  PARCA, 8 June 2015.
  • Five Easy Pieces: The Essentials of Managing Programmatic Risk, Managing the risk to cost, schedule, and technical performance is the basis of a successful project management method, 10th Annual Rocky Mountain Project Management Symposium, Denver Colorado, April 2000.
  • Managing in the Presence of Uncertainty and Resulting Risk This briefing shows how naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. Event-based uncertainties (Epistemic) require the capture, modeling of their impacts, defining of handling strategies, modeling the effectiveness of these strategies, and the residual risk, and their impacts of both the original risk and residual risk on the program
  • Programmatic Risk Management, Program Planning and Controls Workshop, A not so simple introduction to the complex but critical process of building a credible schedule, Denver, Colorado, Program Planning and Controls Workshop, October 6 and October 14, 2008.
  • Handling Risk on High Technology Programs, Risk Management is a Profession, Risk Management is Program Management, Risk Management is How Adults Manage Projects, Managing Risk goes hand-in-hand with Managing People, Processes, Vendors, and the Client - Without Metrics, you're just another guy with an opinion - Stephan Leschka, Hewlett Packard
  • Applying Risk Radar to High-Risk Technology Projects - Risk Radar® is a risk management tool. Here's how it's applied in space and defense example
  • Integrating Risk and Earned Value, the notion of integrating cost, schedule, technical performance, and risk is possible in theory. In practice, care is needed to assure credible information is provided to the Program Manager. Pikes Peak Regional Chapter, Project Management Productivity Tools Symposium, Feb 28, 2009.
  • Managing in the Presence of Uncertainty Requires Making Decisions with Models of that Uncertainty, Monte Carlo Simulation, and some related approaches can be the basis of making informed decisions in the presence of uncertainty.
  • Applying Risk Management to Increase the Probability of the IMS, The effectiveness of risk management depends on the people who set it up and coordinate the risk management process to do their job properly. EVM World 2015
  • Building a Risk Tolerant IMS: Using Earned Value to manage the risk of a project in terms of "risk-adjusted physical performance" Using Earned Value to manage the risk of a project in terms of  "risk-adjusted physical percent complete.
  • Integrating Risk with Earned Value, The notion of integrating cost, schedule, technical performance, and risk is possible in theory. In practice, care is needed to assure credible information is provided to the Program Manager, Pikes Peak Regional Chapter, Project Management Productivity Tools Symposium, February 28th, 2009.
  • Building a Risk Tolerant IMS, Informing the Program Performance with Risk to Increase the Probability of Program Success (PoPS), Safran Risk Roadshow, McClean, VA June 23, 2015.
  • Increasing the Probability of Program Success using Risk+, A workshop on the principles and practices of Risk+ and increasing the Probability of Program Success
  • Managing Schedule Risk, Hope that risk can be programmed out of a project schedule is a false hope. However, you can manage uncertainties by understanding the risk type they represent and addressing each in an appropriate manner.
  • Risk Management in Five Easy Pieces with Apologies to Jack, Risk management is essential for any significant project. Certain information about key project cost, performance, and schedule attributes are often unknown until the project is underway.
  • Managing Risk as Opportunity, With uncertainty, comes opportunity. But if a project manager is consumed with managing the risk, there is little time to manage the opportunities.

A four-part series in the management of programmatic and technical risk:

  • Managing Risk and Opportunity - 1st in a Series, if a project manager is consumed with managing risk, there is little time to manage opportunities. Good risk management is not about fear of failure, it is about removing barriers to success. This is when opportunity management emerges.
  • Managing Schedule & Cost Risk - 2nd in a Series, The notion that risk can be programmed out of a project schedule is a false hope. However, you manage uncertainties by understanding the risk types they represent and addressing each in an appropriate manner
  • The Risk Tolerant Master Schedule - 3rd in a Series, Traditional approaches to planning, scheduling, and managing technical performance is not adequate to defend against these disruptions. This paper outlines the six steps for building a risk-tolerant schedule, using a field-proven approach.
  • Risk Management is How Adults Manage Projects - 4th in a Series, risk management is essential for the success of any significant project. Information about key project cost, performance, and schedule attributes is often unknown until the project is underway.

Technical Performance Measures

TPMs are attributes that determine how well a system element is satisfied or expected to satisfy technical requirements or goals. TPM assesses design progress, defines compliance to performance requirements, identifies technical risk, and is limited to critical thresholds, including projected performance. The TPMs provide the assessment of Physical Percent Complete for informing Earned Value as well as showing the stakeholders that progress is being made toward a physical goal.

Integrated Master Plan and Integrated Master Schedule

The Integrated Master Plan and the Integrated Master Schedule are critical success factors for all projects. The IMP states how the delivered capabilities produced by the project are maturing in Measures of Effectiveness and Measures of Performance. The IMP is related to the other elements of success for all projects and shows what Significant Accomplished must be delivered for the project to make progress as planned.

PMB

Project Cost, Schedule, and Technical Performance Management 

All projects are driven by cost, schedule, and needed technical performance. These three variables are tightly coupled and managing all three at the same time is necessary for project success. As well all three have uncertainties, and some risk is present for them as well.

Product Development and Program Management Office

Enterprise IT and Embedded Systems

Enterprise project management is not the same as individual project management. There are larger risks, externalities, regulations, governance, portfolio, and corporate drivers for these types of projects. Success starts with a Strategy for the project. This strategy starts with a Balanced Scorecard stating why the project is being conducted, what the tangible outcomes are, who the stakeholders are, and how they are going to measure the success of the project. Next comes the governance processes for the project, the architecture of the project - possibly an imposed architecture from internal or external governance.

Earned Value Management + Agile Software Development = A Match Made in Heaven

The following materials were developed from work performed while managing Large IT projects in domains where Earned Value Management is used, starting on government programs subject to FAR 34.2, DFARS 234.2, and DOE G 413.10A. With agile software development becoming the standard approach in Federal and State governments as well as Enterprise IT systems, adding Earned Value Management provides visibility to Physical Percent Complete in units meaningful to the decision-makers. Those units are Hours and Dollars connected to the Measures of Effectiveness and Measures of Performance produced in exchange for the Hours and Dollars

Earned Value Management

Earned Value Management is found on all government programs greater than $20 Million, starting with flow downs from OMB A-11 Part 7 for civil agencies, FAR 34.2 for Department of Defense, and DOE G 413.3-10A for the Department of Energy. 

EVMS Training Materials

Client EVMS Presentations

  • Earned Value + Agile = Success, Increasing the probability of Program Success requires connecting the dots between EV and Agile Development, Northrop Grumman C4ISR Systems, McLean, VA

Agile Software Development

Integrating Agile and Earned Value Management

Earned Value and Agile software development are easily integrated and in some domains, this integration is mandatory. Here's is the processes needed to perform that integration.

  • Getting Started - The Basis of Success for Software Intensive System of Systems (SISoS) is Integration of Systems Engineering, Agile Software Development, and Earned Value Management to Measure Physical Physical Percent Complete for each Deliverable against the Planned Physical Percent Complete and take Corrective or Preventive Action to stay on plan to Keep the Program Green.
  • 0.0 - Executive Overview - Earned Value Management and Agile Software Development have much in common. Most important, is progress to plan measured by Physical Percent Complete with tangible evidence of working products at the end of the planned period of performance. For Software Intensive System of Systems (SISoS), agile development provides the tool for producing working software on frequent intervals needed for customer feedback to assure the program is going in the right direction.
  • 1.0 - EVM and Agile Must be Deployed Together to be in Harmony with Each Other - Program success depends on many things ‒technical and programmatic. Without program controls, the technical aspects of the program have no planning, risk management, performance assessment, and corrective actions needed to deliver the needed program outcome on the planned date for the planned cost.
  • 2.0 - Opening Background - These are the background material needed to establish the core principles of both Earned Value Management (EVM) and Agile Software Development (ASD), in this case, SCRUM. The PMB is one of the common data items between Agile and EVM, along with the Physical Percent Complete and the Capabilities Based Plan, which defines the Product Roadmap and contents of the Cadence Releases.
  • 3.0 - Start with the End in Mind - The integrated value proposition of Agile and EVM needs to be articulated upfront. And revisited when we get stuck and can’t answer why are we doing this?
  • 4.0 - Framing Assumptions - Framing Assumptions define and track key program assumptions that are made early in program development and throughout the program life. Framing Assumptions serve as a form of risk analysis to identify uncertainties that may or may not be recognized as such. 
  • 5.0 - Foundations of EVM and Agile - Earned Value Management and Agile development have much in common. the measure of Physical Percent Complete used to forecast future performance is a critical success factor in both paradigms. Bounded assessments of progress to plan is another. Estimating is bottom-up in both EVM and Agile. This integration provides actionable information to increase the Probability of Program Success (PoPS)
  • 6.0 - Performance Planning and Measurements on Earned Value and Agile Programs - Measuring performance in EVM is done as 748–C states by, objectively assessing accomplishments at the work performance level. Physical Percent Complete using 0/100 EVT does this best. Agile’s assessment of performance is Working Software at the end of each Sprint. These two methods are nearly identical.
  • 7.0 - Connecting the Dots Between EVM and Agile - Earned Value Management and Agile Software Development share a common theme –Progress to Plan is measured by Physical Percent Complete(P%C)In EVM, P%C is defined by compliance with Measures of Effectiveness, Measures of Performance, Technical Performance Measures and Key Performance Parameters and assessed through Quantifiable Backup Data. In Agile P%C is defined as Working Software
  • 8.0 - The Requirements Elicitation Problem - In traditional programs ‒technical and operational requirements are flowed down in the Statement of Work, Statement of Objectives, Concept of Operations, and other contractual compliance documents. In Agile, requirements emerge from the needed Capabilities, as the program progresses and working software is produced for the customer to use. These Emerging requirements have an impact on maintaining the integrity of the Performance Measurement Baseline.
  • 9.0 - Planning, Budgeting, and Estimating in Agile - In Agile, Story Points can be used as measures of effort.†In Earned Value there is no concept of Story Points, rather Dollars and Hours are the measures of effort and duration for the work. When using Agile on EVM projects, each unit of measure has value to the benefits produced through the integration, IF there is proper segregation of these concepts. 
  • 10.0 - Step by Step to Build and Execute the PMB - In Agile, the notion of the Performance Measurement Baseline (PMB) does not exist. For EVM programs we need a PMB for reporting and contract management. Adjustments to the notion of Release and Sprint planning are needed to integrate these two paradigms.
  • 11.0 - Dependency Management in Agile at Scale - With multiple Agile teams working on System of Systems development programs, dependencies will be a natural outcome. The complexity of arises from the parallel development streams and is unavoidable for any non–trivial development effort.
  • 12.0 - Risk Management and Agile Software Development - The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event-Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, the residual risks, and their impacts of both the original risk and the residual risk on the program.
  • 13.0 - Change Control - Change Control on Earned Value Management programs is much different than Change Control on Agile programs. Replanning, Reprogramming, and Rebaselining are all allowed in EVM. Agile does this continually, so adhering to EVM guidelines is the starting point for integrating Agile with EIA–748–C programs.
  • 14.0 Physically Connecting the Dots - With the processes described so far, we now need to define the Physical connectivity between the components of Agile, program planning, and control, Earned Value Management, and reporting.
  • 15.0 - The Dark Side - Both Earned Value Management and Agile have Dark Sides. Things that are not talked about in public. But when they are Integrated, each provides a solution for the problems of the other. Assess current and desired Maturity for Agile and EVM is the starting point for integrating these two processes.
  • 16.0 - Failure Modes of Agile and Earned Value Management Transformation - The root causes of Failure to Transform to an Agile Organization and Failure to Adopt Agile methods are two Critical Success factors that require corrective actions for any Agile at Scale initiative to be successful.
  • 17.0 - Maturity Models for Deploying Agile at Scale - Applying Earned Value Management to software development programs means establishing a governance foundation for that development effort. CMMI®is one place to start. So is Agile development. Both CMMI® and Agile have complementary processes that can be connected with Guidelines in EIA–748–D.
  • 18.0 - Root Cause Analysis - Root Cause Analysis is the method of problem-solving that identifies the root causes of failures or problems. A root cause is the source of a problem and its resulting symptom, that once removed, corrects or prevents an undesirable outcome from recurring.
  • 19.0 - Agile Contracts - FAR 15.201 and Agile Contract Uniform Contract Format provides guidance for agilely acquiring software.
  • 20.0 - Conclusion - Integrating Agile on Earned Value Management programs is straightforward, once the Bright Lines are established between the PMB and the Agile Release, Sprint, Story activities.

Agile + EVM Bibliography
A Full Bibliography of Earned Value Management and Agile Software development, with the individual sections for a single topic.
This bibliography is frequently updated from the research on Software Intensive System of Systems

  • Management Processes in Large Scale Project Domains, Complex systems usually come to grief, when they do, not because they fail to accomplish their nominal purpose. Complex systems typically fail because of the unintended consequences of their design … I like to think of system engineering as being fundamentally concerned with minimizing, in a complex artifact, unintended interactions between elements desired to be separated. Essentially, this addresses Perrow’s concerns about tightly coupled systems. System engineering seeks to assure that elements of a complex artifact are coupled only as intended. – Michael Griffin, NASA Administrator, Boeing Lecture, Purdue University, March 28, 2007
  • Project Management Frameworks for Agile Development - Agile software development is a set of principles for producing software in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and encourages rapid and flexible response to change.
  • Scrum Master, Product Owner, team, Releases, Features, and User Stories - User stories capture just enough information about a feature to facilitate a future conversation between the product owner and the team. User stories are descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
  • Agile at Scale for Software Intensive System of Systems - Agile at Scale includes the ability to apply Agile on teams of all sizes, on teams geographically distributed, on teams facing regulatory compliance, on teams addressing complex domains, on teams applying a complex technology, on teams where outsourcing is involved, and combinations of these.
  • Agile Development on Earned Value Management Projects - Earned Value Management is the technique assessing program performance with objective measures of Physical Percent Complete. These included Technical Performance Measures, Measures of Effectiveness, Measures of Performance, and Key Performance Parameters
  • Estimating Agile Complex System of Systems - The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a
    project’s targets are realistic enough to allow the project to be controlled to meet them ‒ Steve McConnell
  • Requirements Elicitation of Software-Intensive System of Systems - Agile requirements are developed iteratively and incrementally through collaboration between development and the stakeholder. Requirements start at a high level through envisioning of needed capabilities and details are explored on a just-in-time (JIT)  basis via Feature and Sprint modeling activities.
  • Systems Engineering and Program Management - Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. Successful systems must satisfy the needs of their customers, users, and other stakeholders.
  • Root Cause Analysis for SoS Projects - When mistakes occur, blame the process, not people. Root Cause Analysis is the means to fix the cause, rather than treat the symptom. § What allowed the mistake to happen? § What will prevent mistakes from occurring in the future? § Assume people continue to make mistakes, so build fault‒
    tolerance into your improvements.
  • Architecture for Agile Development Programs - Architecture provides the foundation from which systems are built and an architectural model defines the vision
    on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an organization, or for infrastructure such as the Internet that is shared by many organizations. Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of architecture.
  • Transformation of Agile Programs - Transformation to Agile requires a transformation for the organization as well. This starts with Continuous Delivery by optimizing the manner in which workflows through the product delivery system. This means bring agility to all areas of that delivery system, not just software development.
  • Testing Agile Programs - In the world of software development, the term agile typically refers to any approach to project management that strives to unite teams around the principles of collaboration, flexibility, simplicity, transparency and responsiveness to feedback throughout the entire process of developing a new program or product.
    And agile testing means the practice of testing software for bugs or performance issues within the context of an agile workflow.
  • Technical Debt - Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical Debt doesn’t include deferred functionality, except in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard).
  • Change Management on Agile Programs - Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a
    project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead, agilists will do just enough initial requirements envisioning to identify their project scope and develop a high-level schedule and estimate; that's all you need early in a project, so that's all you should do. During development, they will model in a just-in-time manner to explore each requirement in the necessary detail.
  • Risk Management on Complex System of Systems - Risk Management is essential for development and production programs. Information about key project cost,
    (technical) performance and schedule attributes are often uncertain or unknown until late in the program. Risk issues that can be identified early in the program, which will potentially impact the program later, termed Known Unknowns and can be alleviated with good risk management. (Making these decisions in the presence of Uncertainty ‒ reducible and irreducible ‒ requires making estimates) ‒ Effective Risk Management 2nd Edition, Edmund Conrow, AIAA, 2003.
  • Agile Maturity Model - Like all software development processes, the maturity level of the organization is a critical success factor.
  • Agile Portfolio Management - Agile portfolio management deals with how an organization identifies, prioritizes, organizes, and manages different products ‒ Luis Goncalves in Organizational Mastery: The Product Development Blueprint for Executive Leaders
  • Tools, Journals, Professional Societies - Here are tools, journals, and professional societies with resources for increasing the probability of project success.

Program Performance Management Using Essential Views

  • Essential Views of the Integrated Program Management Reports, when contractually required, DOD acquisition contractors are obligated to submit the IPMR's electronically IAW DID 81861. This data is necessary but not sufficient for successfully managing a program. This presentation is the overview of the Essential Views needed for that success

This 3-day workshop focuses on the Essential Views of program performance data needed to increase the probability of program success.

  • 0. Table of Contents, a three-day workshop on the Essential Views needed program success
  • 1. Introduction, This briefing presents the activities needed to develop the Essential Views that provide visibility to program performance. With a credible Integrated Master Plan / Integrated Master Schedule (IMP/IMS), Measures of Effectiveness (MoE) and Performance (MoP) can be defined for the Significant Accomplishments (SA) and Accomplishments (AC). With these measures, Key Performance Parameters (KPPs)and Technical Performance Measures (TPMs), and risk-adjusted IMS can be developed defining Earned Value Management data needed for the Integrated Performance Management Report (IPMR). These Essential Views provide the Government Program Manager the insight into program performance needed to increase the Probability of Program Success (PoPS).
  • 2. Concept of the Essential Views - the motivation for the Essential Views is to increase the probability of program success through the data provided to the Integrated Program Management Report (IPMR), through Leading and Lagging Indicators, and other elements of the Performance Measurement Baseline. “Lagging Indicators” are data contained in the IPMR. This data must be verified for its credibility before any “leading indicators” can be used. “Leading Indicators,” provide credible forecasts of cost and schedule, using the “Lagging Indicators” and other measures of effectiveness and performance.
  • 3. TSAS WBS, The Work Breakdown Structure is the starting point for developing all other elements needed for the Performance Measurement Baseline. The TSAS WBS is defined using the MIL-STD‒881C Appendix H for the UAV. From this, the details of the avionics subsystems will be used for the development of the Integrated Master Plan and Integrated Master Schedule.
  • 4. System of Systems, Complexity of Systems, and Cross-Cutting Functionality
  • 5. Integrated Master Plan and Integrated Master Schedule, Complexity of the Integrated Master Plan
  • 6. Build a Credible IMP, Building the IMP is a Systems Engineering activity. The Integrated Master Plan is the Program Architecture in the same way the hardware and software are the Product Architecture. Poor, weak, or unstructured Programmatic Architecture reduces visibility to the Product Architecture’s performance measures of cost and schedule connected with Technical Performance Measures.
  • 7. 6 Steps to IMP Development, This step-by-step process needs to be followed carefully. The IMP has constructed one Program Event at a time – Left to Right in time. To do otherwise allows confusion and disconnection between Program Events to occur and dilutes our focus on defining what Done looks like for each Program Event.
  • 8. Nuances to These Steps, Building the Program Event, to Significant Accomplishment, to Accomplishment decomposition is straightforward. For each Program Event, simply identify what are the needed Significant Accomplishments for the entry and exit criteria, and the Accomplishment Criteria for the Work Packages that produce the AC.
  • 9. Connecting IMP to Performance Measures, Assembling the IMS from the IMP appears to be a straightforward process – details the tasks that support the Accomplishment Criteria. But some critical steps must be done in the right order to end up with a risk-tolerant IMS.
  • 10. First Pass at Building the IMP, Many contractors all ready have work processes to do this. These steps are the guidance for contractors new to this process. With the RFP, the contract should be capable of the following steps to create the Integrated Master Plan and Integrated Master Schedule. We’ll build the IMP/IMS for the Government to compare the contractor's IMP in the proposal.
  • 11. Developing the IMS from the IMP, The Integrated Master Schedule (IMS) is derived directly from the Integrated Master Plan’s Accomplishment Criteria (AC). The IMS shows the order in which the Work Packages must be performed to assure the Accomplishment Criteria are completed within the defined Measures of Performance, the Key Performance Parameters, and the Technical Performance Measures.
  • 12. Scheduling Best Practices, Building a credible cost baseline is fraught with problems. Technical problems, process problems, political problems. But a credible cost baseline is needed for a Credible Performance Measurement Baseline. Developing the Basis of Estimate is the starting point.
  • 13. Developing the Cost Baseline, The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event-Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, and the residual risks, and their impacts of both the original risk and the residual risk on the program.
  • 14. Managing in the Presence of Uncertainty The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event-Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, and the residual risks, and their impacts of both the original risk and the residual risk on the program. The management of Uncertainty in cost, schedule, and technical performance; and the Event-Based uncertainty and the resulting risk are both critical success factors for the programs. Risk Management starts with capturing Event-Based Risks and their impacts, then with the modeling of the statistical uncertainty of the normal work.
  • 15. Connecting the PMB to the IPMR, All the program performance data in the DI‒MGMT‒81861 is historical. This past performance data – by itself – is like driving in the rearview mirror. What is needed is Leading Indicators that can be derived from this past performance data.
  • 16. Earned Value Management, Earned Value Management is the ‘best tool’ for managing large, complex acquisition programs. – Ashton Carter (USD, AT&L) 26 November 2009.
  • 17. Building the IMP for PDR, With the background information so far, let’s build the IMP for the TSAS program, along with the Risk Register the MoE’s, MoP’s, KPP’s, and TPM’s that must be discovered during each stage of IMP building.
  • 18. Avionics PDR, With this background, let’s get started with the PDR Significant Accomplishments and their Accomplishment Criteria. We’ll focus on the Flight Avionics Systems embedded in the TSAS UAV. This allows us to build a “real” IMP in our limited time, without all the complexities of the total system.
  • 19. Root Cause Analysis, PARCA – Performance Assessments, and Root Cause Analysis. The natural variances of a program need to be separated from the uncontrolled or possibly uncontrollable variances.
  • 20. Bibliography, Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. — Samuel Johnson
  • 21. Background, Here’s the background for how we got to where we are with this briefing.

Systems Engineering and Systems Management

Systems Engineering is the basis of the management of all complex projects. This is concept is rarely understood or applied in the Software Development world. Here's are resources that speak to this Critical Success Factor for all Software Intensive System of Systems

Journal Papers, White Papers, and Essays on Project Success

This is the collection of Journal articles, White Papers, and essays on a variety of topics I have written over the years related to Increasing the Probability of Project Success.

Journal Papers

Essays

White Papers

Mathematics, Science, and Computer Writings

Writings about topics outside those provided above, going back to 1974

  • A Mathematical Tour of the Electromagnetic Force, from Michael Faraday to Quantum Field Theory
  • Tell a Memorable Story, how to write a white paper, by telling a story in a three-act play
  • Proof of the Kepler Problem, can Kepler's equation be Proved and Considered a Law of Nature?
  • Pseudo-Science and the Art of Software Methods, A list of ways to debunk claims that are clearly pseudo-science.
  • Parameter Validation for Software Reliability, A method for increasing software reliability through parameter validation. Existing systems are examined and a proposed technique is presented to aid in the static parameter validation of RATFOR (A FORTRAN Macro Processing Language developed by Brian Kernighan of C and Unix fame), ACM SIGPLAN Notices, Volume 13 Issue 6, June 1978.
  • Exception Handling in CORBA Environments, Component-based software development introduced new sources of risk because independently developed components cannot be fully trusted to conform to the published specifications and software failures are caused by systematic patterns of interaction that cannot be localized to any individual component.
  • A Time Study in Numerical Methods, a 1974 paper assessing the performance between FORTRAN and APL in solving numerical integration, solutions to individual equations, Eigenvalue and related matrix problems, systems of linear equations, solutions to ODE, and solutions to PDE. This was done in graduate school as an exercise to determine the fastest way to model data from our experiment.
  • NIKE Software Functional Specification, a functional requirement specification for an In-Circuit-Emulator. This is an example of how to describe a product, in this case, software and hardware, in simple terms through the functional behavior of the product.

 

Posted at 12:19 PM in Agile, Architecture, Balanced Scorecard, Books, Business, Capabilities, Capabilities Based Planning, CAS, Compendium, CompendiumCollections, Decision Making, Deliverables Based Planning(r), Earned Value, ERP, Estimating, Governance, Government, IMP/IMS, Management, Model Based Design, NASA, Performance-Based Project Management®, Planning, PMI, Principles, Product Management, Project Management, Requirements, Research, Risk, Root Cause Analysis, Scheduling, Strategy, Systems Engineering, Systems Theory, Technical Performance Measures, Technology, Things I Know About, WBS |

Comments

Categories

Follow galleman on Twitter

 Subscribe in a reader

View Glen's profile on slideshare

Search

Recent Posts

Blog powered by Typepad
Member since 03/2005
© Herding Cats
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported

Recent Comments

Enter your email address:

Delivered by FeedBurner