Just the other day I was asked my opinion on RAID logs. I had to admit that “RAID” was a project management acronym I had not heard of. Checking the PMBOK Guide turned up nothing. I did find entries on some of the big PM sites via search. The thing is a Risk, Assumption, Issue, and Dependency log, for those of you hadn’t heard of a RAID log either. Apparently, some practitioners claim it is an indispensable tool while others question its utility as redundant. We’ll open that can of worms up in a future article.
What my research did reveal, and I had not really considered was: risks, issues, and dependencies are well understood in formal project management, however, there is little concerning project assumption management in the literature. Reviewing the body of knowledge for Agile project management yielded a similar dearth of discussion. What is more surprising is both appear to cover a similar minimal amount of recommended practice.
That Dog Is Going to Bite You
Every project manager I know has experienced that cold sweat moment when they discover that a key assumption, upon which much of project was based, isn’t true. The assumption they felt was as axiomatic as parallel lines, as certain as gravity, as immutable as the conservation of angular momentum, turns out to be neither immutable, certain, or axiomatic. Once bitten by a failing assumption, the best that can be hoped for is that the project has not been completely tanked. Sadly, most failing assumption stories usually include tales of late nights, death marches, and project cancellations.
Why are project assumption failures frequently so devastating?
Much of the problem is related to the nature of beginnings. Assumptions form much of the conceptual basis for the initial planning of a project. It is impossible to start to plan a project or develop a vision without accepting certain ideas as true for the future. We accept the risk that these assumptions may be invalid to identify opportunities that may drive a project. As we know, defects at the beginning of a project, and an invalid assumption is certainly a defect, get more dangerous the longer they go undiscovered. The initial insult is magnified by invalid work performed based on the invalid assumption and the eventual cost of repair. Failed assumptions become subject to the order of magnitude increase in cost of bad requirements in the worst way.
Fellow Agile practitioners maintain that failed assumptions cannot devastate a project in Scrum as requirements are only product backlog items (PBI) that get added to sprints according to their priority. The thinking is that the impact is largely limited the sprint they are assigned to. Assumptions may function like requirements, according to traditional PMI principles, and therefore be akin to a PBI. However, since assumptions have a longer time frame than most traditional work packages, they do not share the same correspondence to a standard PBIs. What’s more, invalid assumptions are more likely to hide in the product backlog until they blow up, like a forgotten land mine.
As was so eloquently remarked:
“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog” – Ken Schwaber – Agile Project Management With Scrum
The problem with assumptions on an Agile project is that they are frequently attributes of the vision of the project and not components that can be managed with the Product Backlog. As such, they have a longer time frame and impact on the overall effort than Product Backlog Items. Their risk cannot be reduced by limiting their impact to single sprint as they percolate throughout the entire length of the project.
Most of us have been surprised by failing assumptions, not only in project management but with simple everyday tasks. Although surprises are great for birthday parties, they are not much fun on complex expensive software development projects. Reviewing what has been written about assumption management for both traditional and agile projects: there is less than one would expect and nothing that is comprehensive for technical projects. I felt it necessary to revisit this problem to attempt to consolidate the literature into a more cohesive whole. This article will be the first of a number of articles on the subject.
Our initial foray into the subject will seek to establish a conceptual framework for discussion of project assumptions in technical project management. We hope to develop these ideas so that they are methodology agnostic. To truly understand the topic we will rely on the literature from traditional and agile project management bodies of knowledge and, perhaps more importantly, investigate key research concerning the subject from outside of technology and software development disciplines.
Assuming I Know What it Is!
Assumptions: I assume that I know their role in a software development project. It seems so tantalizingly self-evident. On further reflection, perhaps I spoke too soon. Getting into it, this is what I’ve found so far:
“Assumption – A factor in the planning process considered to be true, real, or certain without proof or demonstration.” – PMI – PMBOK® Guide, Fifth Edition
The problem is what it means to be “true, real, or certain”. How can we really be sure, how can we really know? These three terms are concepts that human beings have been chasing for as long as there have been human beings. To make things even more interesting:
“A planning assumption is a judgment or evaluation about some characteristic of the future that underlies the plans of an organization.” – James Dewar – Assumption-Based Planning
For Dewar, we are in the business of prognostication, trying to predict the future. Like truth, the future has been something that humanity has been trying to understand for millennia.
For our purposes, and the purposes of technical project management, we’ll combine these two views of assumptions into a single comprehensive definition appropriate for our exploration:
Assumptions are statements about the shape of the future at a specific point in time based on factors believed to be certain without proof or validation.
You Will Know Them by their Categories
To conceptually manage assumptions let’s identify categories and characterizations so we can begin to talk about them. There will be three characteristics that will be important:
- Timeframe – The future point in time that an assumption is valid for.
- Visibility – The ease by which an assumption can be ascertained or is discernable.
- Veracity – Assumptions are categorized by their type of truthfulness.
Timeframe Characteristics
A critical component of evaluating assumptions is the anticipated useful timeframe of the project. As an assumption is a statement about the shape of the future it is important to understand when that future is. An assumption driving an ERP implementation for a company may be valid for a year or two and be useful for a decade or so, but not so much for centuries. All assumptions are guaranteed invalid if the future is forever.
Visibility Spectrum
Assumptions have a level of visibility associated with them. Visibility is an attribute derived from the degree an assumption is based on inherent characteristics of the organization or project. If an assumption is based on something that is fundamental it is more likely to be missed when it comes to identifying the assumptions a plan is based upon. We’ll refer to such an assumption as “implicit”.
Opposite an implicit assumption, we recognize a concept of explicit assumptions. These are more visible as they are frequently derived from, and themselves not, inherent principles. They do not represent fundamental characteristic of the project’s performing organization or its stakeholders.
Note that the concepts of implicit and explicit represent the extreme ends of a spectrum. In practice, an assumption will find itself somewhere in between these two extremes.
Veracity Categories
At the early project planning stage, project assumptions are all considered to be valid and truthful for the target time frame. The veracity of the assumption can be broken into three primary categories based on the nature of the logic of the determination of truth:
- Axioms – concepts so obvious that they require no proof. Axioms are up there with Euclid’s axioms from Elements or Kant’s a priori judgment from the Critique of Pure Reason.
- Postulates – assumptions taken as true without proof for the purposes of the definition of project scope or vision planning.
- Heuristics – ideas generally accepted to be true through “common” knowledge, or as part the standards of a particular practice or organization. These are “rules of thumb”, truisms, culturally accepted norms or knowledge, and the like.
The veracity category can indicate something concerning the source of the assumption and its importance in the planning process.
Next Time
The above lays down an argument of why assumption management needs a more thorough analysis than currently exists in the software project management literature for traditional or agile practices.
For PMBOK practices, assumptions are mentioned in relation to project charter and scope statement documents. They play a role in estimation and scheduling, and can generate risks. While this is not insubstantial, there are gaps where failed assumptions can wreak havoc on a project.
On agile projects, assumptions sometimes may become a product backlog item. Otherwise, they are pretty much ignored in the literature. Some attempts were made to develop structure around assumptions, but with limited success. Project assumptions generally have a time frame for an entire project and can, therefore, disappear in a project framework that has a detailed view of the future typically limited to a few sprints.
The next chapter in this series will review project assumption management in the PMBOK practice. It will provide some of the missing detail in the literature. The goal will be to map out a process that you can use on traditionally managed projects to understand the roles of assumptions and control their impact.
References
- Ken Schwaber – Agile Project Management With Scrum
- James Dewar – Assumption-Based Planning: A Tool for Reducing Avoidable Surprises (RAND Studies in Policy Analysis)
- PMI – Guide to the Project Management Body of Knowledge (PMBOK® Guide) Sixth Edition
- PMI – Practice Standard for Project Risk Management
- PMI – Practice Standard for Project Estimating
- PMI – Requirements Management: A Practice Guide
Leave a Reply