Skip to main content

Agility, Uncertainty, and Expectations

There are few things we can be certain of, for example, change and impermanence. When it comes to plans, there is no certainty that the plan will reflect the actual outcome.

Plans Do Not Determine Outcomes, They Predict Them

Managing and performing under uncertain conditions is a challenge. In Agile and more traditional projects alike, some people act as if they think that there is 100% assurance that the planned end date will be met within budget while producing a quality outcome. Others are “variance averse” – they deny the implications of current conditions and stick to the plan, no matter what.

Acknowledge that even with a well-defined backlog of sprints, nicely estimated user stories, stable technical requirements, assigned resources all backed up by forceful direction and support of sponsors and clients, you cannot guarantee an outcome with 100% accuracy. Also acknowledge that while the plan does not determine the outcome, it and the constraints it sets do influence performance.

Uncertainty Is a Fact of Life

As I point out in my book, Managing Expectations: A Mindful Approach to Achieving Success, it is irrational to think that a plan will truly reflect the outcome with 100% accuracy. This is particularly true for complex projects and for plans that are made well in advance of the actual performance.

Plans are predictions. Given the number of performance factors, no-one can predict the outcome with 100% accuracy. Uncertainty is certain. The performance factors or variables in play are:

  • the availability of required resources
  • clarity and accuracy of requirements
  • changes in requirements
  • priorities
  • design quality
  • errors and responses
  • reliance on external performance
  • getting approval
  • and more.

The more time between plan and performance, the more opportunity for events that make the plan a fiction. The more individuals and organizations involved, the more complex and volatile the environment, the more uncertainty.

Recognition, Acceptance, and Action

Both Agile and traditional waterfall project management approaches when managed well, recognize and accept uncertainty and act by analyzing risk, identifying areas of uncertainty, qualifying estimates to manage expectations and continuously managing the plan.

The Agile approach brings the issue of uncertainty to the surface. Founded on the idea that Agile is cross-functional and interdisciplinary teams that evolve a product through exploration of requirements and their implementation in an iterative process of small concrete deliverables, review, refinement, acceptance and integration.

The process itself makes behaving as if plans were deterministic less likely. Who knows how long refinement will take? How many errors? How many discoveries of new requirements and improvements? How many disagreements and how much time to resolve them?

The acceptance of refinement – controlled change throughout the process – as normal and beneficial, is a major difference between Agile and the more traditional waterfall approach, Waterfall tends to see change as a negative and tries to inhibit it and postpone it until after the product is delivered. Agile views change as beneficial and enables it.

Levels of Detail: Step Back to See the Full Process

To help face the challenge of managing and performing in uncertainty, we conceive of the project in levels of detail, a hierarchy as in a work breakdown structure, identifying phases, major functions and interim and final deliverables and the tasks and sub-tasks that must be performed to deliver them.

Each level is a point of reference for an estimate and a view of the project. The higher levels represent the roll up of the detailed estimates at lower levels or are estimated in a top-down approach.

By breaking the project into small manageable and meaningful deliverables, performed in sprints, it is possible to tightly estimate the effort and duration of the work required in each sprint to deliver a technical result – code to satisfy a defined requirement.

When we step back from the coding and look at the rest of the development process – requirements, design, review, refinement, acceptance, and integration – we recognize uncertainty and the need for continuous plan refinement.

Stepping back further, we can see the product in the context of the overall program that it is part of – integration, process management, training, organizational change, deployment, user acceptance testing, hyper-care, infrastructure, support, etc.

At this level, fulfilling business objectives is the focus, as are the product and its surrounding processes making a valuable contribution to the organization.

Greater Uncertainty

These aspects of the project are difficult to estimate with the same degree of precision as the typical software sprint. For example, in software projects, it is common to identify changes to the product directly after the product is released. There is a need for hyper-care to carry users through their change process and address issues. This part of the process is complex, and therefore there is uncertainty, though we can have a good sense of a range of possible outcomes based on several factors such as:

  • past experience
  • knowledge of the players and how they relate to one another
  • confidence in the quality of the product and how well engineered it is, as measured by its performance the frequency and impact of changes

How to Manage Uncertainty

The bottom line is that uncertainty is a fact of life and must be considered in every project. To manage it:

  1. Make sure that everyone understands the nature of planning and the need for continuous refinement – the actual outcome will be known when the project is completed, though, as the project progresses the estimates should be increasingly accurate
  2. Define business objectives, program and subproject objectives clearly and make sure everyone agrees
  3. Assess the degree of VUCA – the volatility, uncertainty, complexity, and ambiguity – of your project, sprints, tasks, etc.
    Volatility is measured by the frequency of change and variance from your baseline assumptions.
    Uncertainty is unpredictability, the probability of surprise and the degree to which issues, objectives, principles and events are understood.
    Complexity is a function of the number of interacting factors in a process and the degree to which outcomes are predictable.
    Ambiguity is the fuzziness of understandings such as objectives, constraints, roles and responsibilities, requirements, values, and principles.
  4. Bring risk and uncertainty into each estimate – how certain are you; what can cause variance; what impact can it have; what can you do about it?
  5. Break your project or program into clearly defined chunks – phases, activities, sprints, etc. in levels of detail
  6. Remember that product development (e.g., coding) is always embedded in a business project or program and that the development is the easiest and most certain part
  7. Estimate top down at the high level when you are far from performance – include buffers and ranges of estimates along with assumptions.
  8. Iteratively estimate bottom up as you progress through the project and have more specific knowledge.
  9. efine the plan as you identify variance.
  10. Communicate to manage expectations.

George Pitagorsky

George Pitagorsky, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. He is a coach, teacher and consultant. George authored The Zen Approach to Project Management, Managing Conflict and Managing Expectations and IIL’s PM Fundamentals™. He taught meditation at NY Insight Meditation Center for twenty-plus years and created the Conscious Living/Conscious Working and Wisdom in Relationships courses. Until recently, he worked as a CIO at the NYC Department of Education.

Comments (4)