Don't make an ass out of you and me--using assumptions effectively

Abstract

At one time or another, every project manager has experienced the sinking feeling that occurs when a conviction he or she thought was held in common with others is proved untrue. Often the effect on the project is far out of proportion to the apparent size of the unstated belief. Despite the old saying, “When you assume something, you make an ass out of you and me,” assumptions are manifold in every project and are parts of all project management deliverables. The proper use of assumptions is an essential skill for improving planning and communications in projects.

Introduction

Due to their temporary and unique nature, all projects float on a sea of uncertainty. The risk management process provides the project manager with the tools and techniques to help control the unknowns, but certain items must be treated as absolutes so that planning can proceed. This is where we must make the effective use of assumptions, or, “factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration,” (PMI, 2008, p148). Because A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) makes only passing mention of this vital topic, this paper will examine the various models of finding and analyzing assumptions and propose the use of more formal tools and techniques.

The Nature of Assumptions

The Foundation of Communications

It is sometimes said that the three most important things in project management rhyme with the old saying about real estate and location (i.e, “location, location, location”), but in our case they are “documentation, documentation, documentation.” In 2002, when I shared this with my colleague, Merleen Hilley, PMP, she asserted that a certain kind of documentation was far more critical than any other. “The most important thing in project management is getting the project manager to write down their unvoiced thoughts and assumptions.”

Assumptions are at the foundation of all communications, no matter the media, formality, or participants. Any two people entering into a conversation will hold certain beliefs to be true (e.g., you can hear me, we speak the same language, and you are willing to talk). Likewise, any written communication will harbor similar assumptions in addition to others (e.g., my writing is coherent, the vocabulary is shared, and my message is worth your time). In many instances, a problem in the personal use of assumptions has trivial and even humorous results, but a failure in their use can have a devastating effect on objectives and success in projects.

Assumptions Models

A variety of assumptions models exist, with potential applications to project work. We will examine in detail two of the most complete—one drawn from the world of literature and the other from the domain of strategic planning. We will also review some less developed approaches to using assumptions in projects.

A Literary Model

Although oriented toward the discovery and impact of assumptions in and on writing, Daniel Kies, an English professor at the College of DuPage in Illinois, presents a model that has application to projects as well. If a writer is trying to persuade or convince us of something, then we must try to uncover the assumptions he or she may be making in his or her work. Like the assumptions based planning (ABP) model discussed later, it is primarily based on the examination of existing documents.

Origins of Assumptions

Kies posits that assumptions tend to arise from four origins: cultural, biological, intellectual, and idiosyncratic.

Project managers simultaneously belong to several cultures, including at a minimum: humankind, country, ethnicity, and organization. In particular, assumptions attributed to the organization can play a large role in projects. Staying under budget is more important than making the deadline, I could be laid off if the customer is not fully satisfied, and all the user interface requirements must be met in this release of the project; these are examples of organizational assumptions that might be held by a project manager.

Assumptions with biological origins predispose us toward action over inaction and favoring things that are tangible to our senses. This can be useful when testing and evaluating assumptions if the project manager can leverage our “hard-wired” tendency to prefer a show, tell, and do approach in receiving and believing information. Intellectual assumptions presuppose that “we prefer fact over opinion, certainty over uncertainty, truth over lies” (Kies, 1995). Aristotle talked about the three appeals: rational, emotional, and ethical to describe how we can be persuaded. This intersects with the cultural and idiosyncratic (personal history) origins in interesting ways in modern projects. Because most organizations exist as a way to achieve tangible goals, and most project managers consider themselves quite rational, it follows that all decisions made in and about projects are based purely on logic and dispassionate reasoning. Obviously, this assumption ignores the influence that emotional and ethical appeals can have on our planning and decision making.

Categories of Assumptions

Kies divides assumptions as shown in Exhibit 1.

Exhibit 1 – Categories of Assumptions

This yields four possible categories, as described below.

• Unwarranted, implicit assumptions are undocumented and taken on faith with no supporting evidence at all. This type of assumption presents the most potential for harm to the project.
• Unwarranted, explicit assumptions have no evidence, but have been documented. These assumptions are potentially less risky because their written status offers a greater opportunity for examination and validation.
• Warranted, implicit assumptions have support, but their undocumented nature still presents challenges to the project manager, depending on who holds them and those individuals’ potential to impact the project.
• Warranted, explicit assumptions pose the least threat to projects. The project manager should attempt, as much as possible, to move all assumptions into this category. Bear in mind that evidence supporting an assumption is still not the same as absolute proof.

Testing and Evaluating Assumptions

Testing assumptions for relevancy and validity is the way that Kies believes we can determine their true worth.

In a project environment, relevancy may be less of an issue than in writing, in which irrelevant assumptions can be used to mask a logical argument or a jump to conclusions. Assumptions should still, however, be examined for relevance to the plan components in which they are documented.

To support the validity of any conclusion, rhetoric (the art of using language to persuade effectively) uses four tests: type of evidence, quality of evidence, quantity of evidence, and opposition's position (Kies, 1995). For an assumption made by an expert we would test the type and quality by judging his or her experience, objectivity, consistency, and access to information. To test quantity, we would look at the volume and variety of evidence. The opposition's position can be tested by assessing if other experts disagreed and evaluating their arguments.

Recognizing Limiting Assumptions

An important concept is that of a limiting assumption, one that “blocks or interferes with our ability to think clearly about any particular issue” (Kies, 1995). We sometimes give ourselves messages (often unwarranted and implicit) that function as limits on our abilities or efforts. “I am no good at spreadsheets so I can't analyze the performance data,” and “There is no use in explaining why we need more money since the budget is fixed,” are examples of how limiting assumptions can constrain our actions. “Assumptions are the operating principle behind self-fulfilling prophecies. If we believe something to be true even though it is not tested or not even true, we often act as if it were true” (Ibid).

Assumptions Based Planning (ABP)

Developed by the RAND Corporation in conjunction with the U.S. Military, ABP has been used by both government and private organizations, primarily in high-level strategic planning. “ABP is a tool for identifying as many of the assumptions underlying the plans of an organization as possible and bringing those assumptions explicitly into the planning process…It is primarily a ‘post-planning’ tool (recognizing that planning is an iterative process) that concentrates on the assumptions in an already-developed plan that are most important to a plan's success and that are most uncertain” (Dewar, 2002, p 1). ABP has many concepts in common with project risk management, but as we will see, the terminology differs.

The overarching process is shown in Exhibit 2.

Exhibit 2 – ABP Process

Taxonomy of Assumptions

ABP divides assumptions into the taxonomy shown in Exhibit 3. Not all branches of the tree are shown for the sake of clarity.

Exhibit 3 – Taxonomy of Assumptions

ABP concentrates on the bolded leg of the tree. It focuses on explicit assumptions made about the problems the plan is designed to address rather than those made about the solutions the plan proposes. Projects would need to deal with both types of assumptions in order to be effective.

A load-bearing assumption is one whose failure would necessitate significant changes to the plan. Vulnerable assumptions are those that could fail or be proven invalid during the project. From a project management perspective, an invulnerable assumption would be considered a constraint or “restrictions or limitations, either internally or externally, to the project which will affect the performance of the project or a process” (PMI, 2008, p 148). All assumptions in projects are therefore vulnerable to some degree.

Two-sided assumptions tie into the concept of opportunity and/or threat risks in the PMBOK^® Guide. A one-sided assumption is a worst-case statement that, if it fails, can only impact the project positively. (e.g., “We assume our primary contractor will go out of business while performing this project.”) Dewar sees little benefit in dealing with this type of item. Most assumptions made in projects would slant toward being one-sided in the other direction since their failure would generally impact the project negatively.

Identifying Assumptions

Dewar describes nine techniques to assist in identifying assumptions, four of which have particular applications to project management; paraphrased, they are storytelling, looking for “wills and musts,” rationalizing the plan, and asking the journalist's questions.

Storytelling—“telling planning actions the long way” as Dewar calls it—involves elaborating or adding details to statements made by stakeholders or in a plan. The objective statement in a project charter might read: “This project is initiated to create and adopt a unified Asset Tracking and Protection System (ATAPS) for all company-issued portable information devices.” Encouraging the storytelling approach could yield: “Our organization has come to depend on employees working from remote locations and using portable information devices. Recently, there have been several serious secure data breaches involving portable devices. As a result, our senior management team has decided we must initiate a project that will correct existing security deficiencies and establish consistent standards for the future.” This longer version of the “story” reveals several assumptions, among them that the organization is (and will remain) dependent on portable devices and that standards for these will help with the problem.

Looking for “wills and musts” is a simple technique that involves searching electronic versions of documents for key words. These words appear with amazing frequency in many plans and tend to highlight assumptions that are being made. Just as doing a search for the word “shall” can pinpoint requirements in a request for proposal, finding the wills and musts can identify the planners’ assumptions about the future and actions that the organization intends to take to solve problems or achieve an outcome. Applying this technique to the text above helps confirm previously identified assumptions and adds one implying that the ATAPS project will solve the entire problem.

Rationalizing the plan is based on finding the connection between assumptions made and actions planned or so called “addressed assumptions.” If planned actions are found that do not connect to assumptions about the future, we may have uncovered an unstated assumption. “Planners do not usually plan useless actions. Figuring out why an unconnected action is being planned usually reveals an assumption about the future that has yet to be explicitly stated.” (Dewar, 2002, p 45) This technique only works with rigorously written and analyzed plans, but can have applications in some projects.

Asking the journalist's questions is applying the rule for the six questions any written article should answer: What, When, Where, How, Who, and Why? Dewar asks the first five and adds “why” to each, e.g., “What are we going to do and why?” This is a basic technique commonly used when interviewing stakeholders to collect requirements, develop objective statements, or analyze possible solutions. It can also encourage critical thinking for the project manager to ask him or herself the questions when planning or making decisions.

Developing, Shaping, and Hedging Actions

Shaping actions are those taken before the fact to help insure that the assumption remains true or valid. These relate most directly to avoid, transfer, or mitigate for threat risks and exploit, share, or enhance strategies for opportunity risks. Hedging actions are planned responses to use in case assumptions prove invalid or fail. They map most closely to the contingency strategies used in risk management. Both types of actions depend on developing what Dewar calls “signposts” or warning signs about possible problems with an assumption. This is closely aligned with developing clear cause and effect statements and related “triggers” in project risk management.

Project Management Models

The PMBOK^® Guide defines assumptions, mentions their presence in a few documents, and uses them in one technique; no coherent approach or model for their use appears, and very little else is written about them in the project management literature. Examining PMI's definitions of risks and assumptions in detail helps to reveal the similarities and differences between the two.

Relationship between Assumptions and Risks

A project risk is “an uncertain event or condition that, if it occurs, has an effect on at least one project objective” (PMI, 2008, p 438). The two primary attributes of a risk are the probability of it happening and the impact (negative or positive) that it might have on a project.

Assumptions are “factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration” (PMI, 2008, p 148). Since an assumption is treated as an absolute, this could mean that the only characteristic to consider is its potential impact. However the “absence of demonstration or proof” means that validity rests on many factors, including the certainty of the statement. The initial defining element is “for planning purposes,” which implies that if assumptions are not made, planning cannot proceed and that invalid assumptions lead to invalid plans.

PMI recognizes the relationship between risks and assumptions with the technique “Assumptions Analysis in the Identify Risks” process, which is said to “explore the validity of assumptions based on inaccuracy, instability, inconsistency, and incompleteness” (PMI, 2008, p 287), No further explanation of these terms or elaboration of the technique is given.

Shortcomings in Practice

When mentioned at all in the domain's literature, it is usually recommended that the project manager make a list of assumptions at the beginning of the project, often treating them as some form of risk and attempting to use the same tools and techniques. Some authors will then say that they should be reviewed periodically during the project, but rarely offer any more guidance. The importance of documenting assumptions during every aspect of planning and continuing their formal use throughout the project has, until now, not been addressed in detail.

Formalizing Assumptions in Projects

Implementing an AMP (Assumptions Management Process)

To improve their use in projects, a more formal and standardized AMP is necessary. The following are the steps used in this process.

• Identifying assumptions
• Analyzing assumptions
• Assignment and iteration of assumptions

Identifying Assumptions

I hold a belief in my mind; you hold a belief in yours. We both proceed with a communication, decision, or course of action with the thought that this belief is shared. This is how to assume something “makes an ass of you (‘u) and me”. We must get these beliefs aired and shared before we can reduce the danger. Clearly, the first and most important step in using assumptions effectively is their identification and documentation. Assumptions not identified cannot be addressed further in any form or fashion.

Categories

The risk categories used for a risk breakdown structure example in the PMBOK^® Guide (technical, external, organizational, and project management) can be a useful starting point (PMI, 2008, p 280). Other categories might also be relevant such as cultural, regulatory, environmental, and funding. The point of using categories is not to worry so much about labeling each assumption, but to help promote a broad view of identification. Just as we often tend to focus on identifying technical risks, we might most easily find organizational or regulatory assumptions. Generating as complete a list as possible is our main goal in this step.

Techniques

In addition to those used in ABP, some of the techniques used in risk identification, particularly documentation reviews and information gathering, can be valuable for identifying assumptions. The application of the “lasso technique” can help to focus attention on individual words or phrases in a document. Analyzing a simple statement like, “management sees the success of this project as essential to our future efforts,” can reveal a host of assumptions that might need to be clarified. Management: what level of management, immediate or all the way to the top? Success: what does each of the management levels or stakeholders consider success and who is the ultimate judge of success? And, so on for “essential,” “future,” and “efforts.” By isolating the components of a statement we can discover many implicit assumptions.

Examining risks can often spotlight items that are better treated as assumptions. If the probability of a risk is extremely low, the event or condition might be better treated as an assumption statement made in the appropriate documents.

No single identification technique can compete with documenting assumptions made at each step of the planning process. Many project charters have an assumptions list, but virtually every project management document is built on unstated assumptions. Whether creating a WBS (work breakdown structure), schedule, cost estimate, or human resource plan, the team should always document the relevant assumptions. Making assumptions identification a standard, expected part of project management will yield more benefit than any other possible change an organization can implement.

Analyzing Assumptions

Since effective assumptions identification can result in an unwieldy list, some form of analysis or ranking must be done in order to prioritize our attention and efforts.

If/Then Analyses

David Hillson recommends a simple qualitative technique drawn from the conditional phrasing used in risk statements. “IF this assumption is proved to be false, THEN the effect on the project would be…” (Hillson, 2004). Assessing the IF aspect allows us to consider the probability that the assumption is valid. Creating the THEN phrase lets us analyze the outcome or impact, which can be useful in getting a broad understanding of the priority of the assumption. Even more interesting is his observation that most assumptions are optimistic, that is, that their failure will result in only negative impacts on the project. To address this he suggests examining constraints by saying “IF this constraint could be relaxed or removed, THEN the effect on the project would be…” (Ibid). This might result in a valuable assumption that can then be tested. For example, the constraint “The project budget is $500,000” might yield the assumption “We assume that in addition to the published $500,000 budget, management has set aside a reserve of $50,000 given what we have seen on past projects of similar strategic value.” This is a very interesting technique that can be applied to every constraint in every project.

Ranking Models

The most detailed model for rating assumptions comes from Neville Turbit and uses three key parameters for assumptions:

• Confidence: How sure are we that the assumption is true? 1 (almost certain) to 4 (low confidence)
• Lead time: Time before proven true or false. 1 (first half of remaining time in project) or 2 (second half)
• Impact: Rework/additional work needed if proven false. 1 (minimal < 3%) to 4 (significant > 30%)

Adding these numbers rates the priority from 3 to 4 being low to 9 to 10 being critical (Turbit, 2005). This model mostly looks at assumptions as being paired with related risks and advocates having risk responses identified for each pair. This could have the undesired effect of inflating the risk register unnecessarily, since an assumption that remains valid is not a risk.

A modified form of this system is more appropriate for the AMP:

• Validity

  – Scale for likelihood the assumption will remain valid for duration of the project

  – Example: 1 (almost certain) to 5 (very unlikely)

  – Consider moving the assumption to the risk register if rated over 3

• Impact

  – Scale of impact to project if assumption fails

  – Example: 1 (minimal) to 5 (project failure)

• Urgency

  – Scale for probable time the impact might occur

  – Example: 1 (failure in first half of the time remaining in project) to 2 (failure in last half of remaining time)

This system also yields rankings from 3 to 10 (assuming any with a validity of 4 to 5 are treated as risks) and can guide actions the team might take.

3 to 4    Record, monitor, and perform repeat testing if conditions warrant

5 to 7    Record, perform repeat testing, and consider enhancing actions

8 to 10    Record, perform repeat testing with more frequency, and take enhancing actions

The urgency scale recognizes that the later an impact occurs the more is at stake in terms of investment, commitment, and reputation. “Sunk cost is just that. It can never be recovered, but can always be increased” (Kinser, 2008). Actions that can be taken to enhance the likelihood that the assumption will remain valid can be an important strategy for highly ranked items.

Assignment and Iteration of Assumptions

Assumptions “typically are documented at the start of a project and filed in a safe place. Aside from helping pad out the project charter, they are usually ignored” (Turbit, 2005). Only by assigning ownership and revisiting them during the life of the project can they add value to the project management processes.

Traceability and Repeat Testing

Associating each assumption with other project documents allows for more thorough monitoring and review. Tracing the origin and variety of links that exist promotes a better understanding and rating of an assumption. Performing scheduled reviews and repeat testing maintains the correct status given the inevitability of shifting conditions in a project.

Using an Assumption Register

Utilizing a centralized repository and following a consistent process for the management of assumptions is the core component of improving their value in projects.

The Risk Register and the RTM

Most practitioners are familiar with the risk register, which records each risk, probability and impact, priority, response, owner, and status. The requirements traceability matrix tracks each requirement, its origin, links, reviews, status, and so forth. Combining some of the features of both tools allows for optimum documentation and tracking of assumptions.

A Hybrid Model for Assumptions

Exhibit 4 illustrates what should be documented in an Assumption Register.

Exhibit 4 – Assumption Register

The register records not only the assumption's potential impact if it fails and its ratings, but also shows the origin and links to other documents and projects. In the case of problems with the assumption, these other elements can then be addressed and modified as needed. Perhaps most importantly, the owner, review dates, and frequency insure that the assumption is periodically revisited so that it is not treated as an absolute truth, nor does it deteriorate into an unaddressed risk.

Changing Behaviors in Practice

Effecting any significant change in an organization can seem daunting at best, but following what I call “The Six Ps of Change” can provide some direction.

• Policy clearly stated at the appropriate level
• Processes and documents developed
• Providing a standardized vocabulary
• Performance recorded and assessed
• Prioritizing improving expertise
• Periodic review of the change

For the Assumption Management Process to add value to projects it must be applied consistently in every project, every time. “Project management is about applying common sense with uncommon discipline.” (O'Brochta, 2008, ¶23)

Conclusion

Since childhood, we have been warned of the dangers of assuming anything; yet, assumptions are an integral part of our daily lives and all projects. By increasing the visibility, formality, and reliability of their use, project managers can harness a powerful tool to improve communications and plan their endeavors.