Declaration of Interdependence

The Declaration of Interdependence describes six behaviors of an agile project:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We expect Uncertainty and manage it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.

The problem I've always had with these types of manifestos is that they have very few, if any, actionable outcomes. They are lovely, even inspirational words, but how do I put them into practice—on the job?

In my efforts here in aerospace and at a bio-informatics client, I will act as an agile project manager, deploying Enterprise Services and agile product development. In that case, it's time to take action regarding the principles of the DoI.

Managing Chaos

The origins of chaotic systems come from a simple starting point of accumulated error. Managing Project Uncertainty , Meyer, Loch, and Pich, Sloan Management Review, Winter 2002, defines 4 types of uncertainty. These types are unrelated to traditional technical, market, people, cost, schedule, and quantity uncertainties. The question is how to manage these uncertainties, some of which come from the accumulating errors in any incremental development system. There are four categories of uncertainty for projects:

• Variation
• Foreseen Uncertainty
• Unforeseen Uncertainty
• Chaos

Variations can be modeled using a simple network chart (PERT or Critical Path), in which the sequence of activities in the project is arranged in a network. Planning for variation in the duration and path of each node and arch in the network results in a plan for the project.

ForesUncertaintyinty involves identifying project risks or chance nodes in the network where contingent actions can occur as the project proceeds depending on the actual outcomes from previous nodes in the network.

UnforesUncertaintyinty can be represented in the network with project risk and chance nodes, but only if the unforeseen chance node is recognized when it occurs and a contingency is developed due to the recognition.

When chaos occurs in the project, management must continually create a new network based on incremental learning. In this case, medium and long-term contingencies are impossible since foreseen and unforeseen uncertainty models cannot be developed.

Impact on Agile Project Management

For an agile project management approach, a process must be in place to deal with all four uncertainty sources.

• Variation - simulate the paths through the network with probabilistic models (Monte Carlo). Insert buffers to provide built-in management reserve in front of critical and near-critical paths in the network. These locations can be identified with the Monte Carlo tool. Set control limits for vital and near-critical path items at boundaries appropriate to the project team's experience, technical risk, and capabilities. Monitor deviation from these control limits on periodic boundaries.
• ForesUncertaintyinty - anticipate alternative paths, provide contingent funding for these alternatives, and manage risk through contingency planning and decision analysis.
• UnforesUncertaintyinty - provide the means to add or delete tasks to the network when unforesUncertaintyinty appears. Plan iteratively on acceptable-grained boundaries. Continuously scan for unanticipated influences on the plan.
• Chaos - continuous iteration of the plan and the deliverables. Repeatably verify requirements, deliverables quality, performance, and the go/no-go decisions. Managing Uncertainty

Let's start with We Expect Uncertainty and manage it through iterations, anticipation, and adaption.

I've encountered the four types of uncertainty on something other than technology, features, functions, people, or any other assumed risk source. For each of these uncertainty types, specific actions can take place.

• Variances come from minor (the definition of small needs to be developed) variances in task durations. This can be modeled using PERT or a probabilistic schedule risk tool like RISK+. The variance from the plan will cause a shift in the critical path, resulting in adjustments to the plan as part of the standard project management process. These changes to the plan can be managed through a schedule change request (SCR). The SCR defines what the change is requested, its impact on schedule, cost and risk, and the resulting new cost and schedule. When the planned delivery date for Test and Launch Operations is within ten days, and the test articles are not ready for shipment to the test lab, we'll add ten days to the downstream delivery of the integrated articles.
• ForeseeUncertaintyty is identifiable, and their outcomes are understood. These are side effects typesUncertaintyinty. Changes in the environment of the project. Things that have happened in the past on similar projects or from core knowledge about how the project works in the domain. Contingency plans are the way to address these types of uncertainties. If the local government cancels our access permit to the underground water source, we'll truck water in to make cement.
• Unforeseen Uncertainties cannot be identified during the planning phase of the project. There is no Plan B for these types of uncertainties. These are Unknown Unknowns. These uncertainties make Program Managers nervous because the problems appear without warning and have unanticipated consequences. Unforeseen uncertainties can be found in projects on the edge of technology. Digging into the basement of a nuclear processing building, I found two hidden floors from a long-ago fire that had been covered over. Now, we must excavate these floors, discover what buried wastes are there, and remediate them. Cost and schedule are out the window, so Plan B has become Plan C.
• Chaos in projects exists even when unforeseen uncertainties are not present. The structure, cost, technical scope, and underlying goals must be more structured. Research or exploration projects are like this. Let's fly to Mars with our little digging machine and turn over some rocks to see what's there. Planning this mission is possible for the technical side - getting there, landing, powering up the rover and establishing communications home. But when we start to drive a bit, we encounter a strange and hostile world (we planned for that) and a wholly unplanned and chaotic set of environmental, technical, and operational events. Continuous replanning, rethinking, reevaluating, budgeting, and re-everything is the ordinary course of this type of project.

What does all this mean for project managers and the DoI? The We Expect Uncertainty principle implies that planning uncertainty must occur, just like preparing for certainty. The plans come in a variety of forms, from submitting an SCR to turning to Plan B in the Mission Operations Guidebook, to convening a Change Control Board for a new baseline, to assembling a team of scientists and engineers to discover new ways to recover the spacecraft that drove into a ditch.

In all these cases, some form of actionable outcome is needed and planned in various degrees of resolution. Even for the upside-down rover, there is a plan. The plan is to get a plan to recover. Managing each type of uncertainty requires specific actions. They think through the actions before their need is part of Project Management, even in chaos-type projects.

• VariationVariation - starts with troubleshooting. Why does variation exist, and how can we put it back into the defined boundaries?
• Foresee Uncertainty: Identify the causal events, take specific actions—risk mitigation—to deal with the events' outcomes, or somehow prevent the event from having an impact. Disciplined risk management and mitigation are the starting points.
• UnforeseeaUncertaintyinty requires an evolving management plan. One approach is to make decisions "in the field" at the point of contact. This, of course, requires skilled and experienced staff as well as an integrated risk-sharing management style, which in turn requires trust and flexibility.
• Chaos - requires even more flexibility and trust. Fine-grained iterations are one way to avoid big surprises. Moving the spacecraft a few inches at a time rather than driving yards to a flat spot allows the team to evaluate every tiny detail of the machine's behavior. Continuous verification of project goals, technical and operational parameters, and feedback from old and new ideas is the raw material for managing chaotic projects. From top to bottom, EVERYONE's involvement is the engagement style for these projects.

So, for the agile PM to define the uncertainty type, the specific actions to be taken in the presenceUncertaintyinty, the management style, participants, and the expected outcomes must be made visible, actionable, and measurable for agility to be maintained.