One of the greatest issues project teams face today is the ossification of assumptions—the hardening of assumptions into facts without validation. This negatively impacts decision making and actions taken by the team, ultimately increasing the risk of failure. Yet, assumptions are something we use every day in our lives. So, how do we identify and mitigate those that could cause our project harm? This paper will provide, through case studies, an understanding of how this ossification of assumptions can happen; a proven technique to overcome it; and the role leadership has in developing a culture to prevent it. The intention is to help project managers reduce risk impact caused by the ossification of assumptions through:
- Learning new techniques to manage and validate assumptions.
- Improving decision-making time and quality through assumption approaches.
- Understanding, through case studies, how poor assumptions management can impact an organization's success.
Introduction
In 2004, Range Resources discovered they could employ hydraulic fracturing and horizontal drilling in the Marcellus shale area in Pennsylvania. The Marcellus was known to be rich in natural gas, but prior to this discovery, it was not economically feasible to access the natural gas in a sustainable way. After the 2008 spike in energy prices and the rapid adoption and application of these drilling techniques, oil and gas firms started expanding rapidly into the Marcellus. In the succeeding years, energy companies rushed into Pennsylvania to secure land and right of way (ROW) options for construction of pipelines, wells, and plants, in order to increase their potential market share. Most of these companies came from Texas and Oklahoma, where they had operated and maintained oil and natural gas wells and transmission systems (pipelines, compressor stations, etc.) for decades in the Southwest and Rocky Mountain areas of the United States. For many, this new Marcellus resource area (or “play”) was similar to a gold rush—virgin opportunities in close proximity to the population-rich cities of the Northeast, promising a steady supply of natural gas to support their winter heating needs. Like previous gold rushers, they hurried into an environment fairly unknown to them—in culture, geography, laws, and weather.
Within two years, many of those initial companies—especially the support services providers (engineering, construction, and site work) retreated to their home territories, having suffered financial and reputational losses. They had been pummelled with a host of issues ranging from:
- delays to construction schedules caused by the Indiana Brown Bat (protected under the Endangered Species Act),
- massive delays in environmental permitting due to only three Pennsylvania state approvers (one of whom would return any application due to grammatical or spelling mistakes, thus restarting “the clock”),
- local relations issues due to a lack of understanding how the various community governments work (townships, villages, cities, etc.), and
- cultural backlash, partly due to landowner's distrust left over from their relationship with the coal industry and lack of understanding of how royalties work.
A local project manager who had led engineering and construction projects for the chemical and utility industries summarized this phenomenon as “T.A.F.T—This Ain't Freakin’ Texas.” His meaning was clear: Everything those companies and their support firms assumed regarding engineering and construction projects based on their experience elsewhere was wrong in the Northeast.
Yet, did this have to happen? No. At least not all of it, nor to that degree of impact. The failure by these companies to manage assumptions at both the tactical (project) level and the strategic (company/market) level led to millions (possibly billions) in wasted capital and lost opportunity costs. This lack of assumptions identification and—more importantly—validation, was at various levels—from the tactical, project level to the strategic, business model level. It could have been greatly reduced, or even prevented, had teams captured and managed key assumptions during planning. It illustrates how launching into the execution phase of a project or program without proper planning can lead to great losses in time and capital. The techniques to prevent this ossification of assumptions are not time-intensive. They can be applied quickly and will improve the team's decision-making quality by providing clarity into three basic questions:
- What information is there that we know (validated)?
- What information is there that we can know, but have not validated?
- What information is there that we cannot know?
Assumptions Overview
An assumption, in its purest form, is some uncertainty that is held for the moment. It is something that could turn out many different ways or a status quo that may or may not be maintained. Assumptions are often present, and sometimes even necessary, when dealing with uncertainties in project conditions. We even make assumptions in our everyday lives—that traffic on the way to work will not be unusually heavy, that the sandwich shop down the street will get our order correct, that Dave in IT will forward us the instructions on how to log into the server, or that we all have the same understanding of the phrase, “completion of the deliverable.”
There are typically three ways we make assumptions: (1) intentionally, (2) complacently, and (3) inherently. Intentionally, because we know we have to make the assumption due to an absence of information or control. We cannot control the weather for a construction project, so we, therefore, have to assume a certain number of weather delay days in my schedule. Complacent assumptions are where we recognize there is an assumption being made, but accept it as a norm. The lead time for a certain piece of equipment was 12 months on the last project, so we, therefore, accept that it will be the same. Inherent assumptions are the most basic—language—where by employing certain words or phrases, one inherently assumes alignment in meaning and understanding. I ask, how long will this deliverable take to complete and you answer with, a week. What does that mean? Is that a week with everything on your plate? Or a week if you were 100% dedicated to my assignment?
Let's explore inherent assumptions a bit more for a moment, because how we manage them differs from the other two types of assumptions. Inherent assumptions can be the most dangerous type of assumptions, because it is embedded in us—our culture, our language, our experience. Often, when new team members join an organization, they bring their own set of semantics and may use the same terms as existing team members, but understand those terms differently. This requires clarifying phrases to become ingrained in the team. With the above example, the answer received should have been followed with, is that a week factoring in everything else you have going on? Or is that a week if you are only working on this? We, ideally, want our team communication to be where the initial response is a week, if you could help remove a couple of other items, which I think are lower priority, off my plate. That simple, yet more complete response just reduced the chance of making a poor assumption drastically, and provides more information to better manage the priorities. This approach seems simple (and it is), but we are victims of not using inherent assumptions every day.
Why we Make Assumptions
Through understanding the ways we make assumptions, we can better evaluate when and why we make them. Assumptions wreak havoc on a project, because they not only affect the schedule or cost performance, but they affect team morale, interpersonal relationships, and communication. They create unnecessary “noise.” To understand how to better prevent them, we must first understand why and when they happen.
Exhibit 1: Reasons why we make assumptions.
As Exhibit 1 illustrates, there are often four reasons why we make assumptions. Three of these are controllable through time and planning. But, it should also be recognized that there are situations where we don't have the luxury of time, and we have to accept assumptions are being made. For example, in a crisis situation, there may not be time to step back and resolve a plan to address the issue—we have to take action immediately, and we hope that the choices we make are right. The challenge is to recognize when we do have time—even a little time—to capture and then validate the assumptions.
The first reason why we make assumptions is because we fail to realize we are making them. This relates to the inherent assumptions referenced earlier and is not controllable through time or planning. Avoiding this type of assumption requires excellent communication and thoughtful questions, as well as the understanding that this type of assumption is happening potentially during every team interaction. The project manager's control mechanism is listening for potential gaps and coaching the team to attune for it.
The second reason is because it is faster and easier to make the assumption than deal with the facts. This is one of the most common reasons for the ossification of assumptions. Consider a team sitting in a decision meeting. The team realizes they are missing a key data point from another department. Instead of pausing to call the department or capturing the data point as an assumption that needs to be validated, they turn the assumption into a fact and make subsequent decisions or actions based on it. Within a couple of days, it comes to light that the assumed “fact” was wrong. Now, the team is back in the room in a reactive mode working to assess the information's impact. The project manager's control mechanism for this is both planning, time, and communication. Time, in that by establishing the intent and framework for discussions, the team may not feel pressured to make assumptions in their rush to a conclusion or action. Communication, because, like with inherently assuming, the team should start asking follow-up questions versus accepting the face value answer. When hearing the phrases, “I think,” “It should be,” “It could,” or “I understand it to be,” what usually follows is an assumption. The project manager should seek to instill within the team, the simple follow-up question of, “has that been validated?” and “who validated that?”
The third and fourth reasons both occur due to the desire or rush to get from planning (or “talking) to execution (or “doing”) and are controllable by time. The pressure to make these assumptions often comes from leadership, whether internal to the team or external. The project manager should recognize when this is occurring, and determine if it is necessary to slow the team down because the risk of making poor assumptions is high. Stakeholder management has to be balanced with establishing the desired culture to assess assumptions within the team.
While this seems a little bit daunting, here's the good news: as teams improve their assumptions identification and management capabilities, the speed in which they can manage them increases. Think of the Navy SEALs versus a conventional, less experienced infantry unit. The latter is new to the situation and new to their peers. It has a rigid command hierarchy for decision making because it recognizes that it lacks experience in assumptions assessment and management. The officer and senior non-commissioned officers are there to resolve them. In contrast, the Navy SEALs are flatter in their command, leveraging roles over rank, and are put into chaotic environments with great autonomy because their ability to identify and manage assumptions is mature and their experience is great. Project teams can achieve that level by employing a few techniques.
Case Study: Black Hawk Down
The intent of this case study is to provide a stark understanding of the impact assumptions management can have. This first case study in assumptions received a great amount of public attention. While this case exposed awareness of many command and planning gaps that the U.S. military failed to address coming out of the Vietnam War, it also led to the creation of techniques to combat them.
Operation Gothic Serpent was the military extension of Operation Restore Hope—an effort to combat famine in civil war-stricken Somalia. It evolved into an effort to combat chaos spawned by warring political factions and tribes by establishing a democratic government. While Operation Restore Hope had successfully negotiated with rival warlords and established the safe delivery of aid for a short period, the increased 1993 military intervention by the U.S. and the United Nations operated on multiple assumptions that eventually culminated in the infamous Black Hawk Down incident.
On October 3, 1993, an attempt to insert highly-trained Army Rangers and Special Forces into the city to capture two of warlord Mohamed Aidid's highest lieutenants was quickly jeopardized when two Black Hawk helicopters were shot down by an RPG. The Battle of Mogadishu turned into a rescue operation to retrieve the crews of the fallen helicopters that would ultimately impact American lives: 18 dead, 73 wounded, and an alarmed American public.
Crisis revealed the assumptions operating at both the on-the-ground tactical level and the overarching strategic level. For the Rangers and Special Forces, assumptions manifested in deadly miscommunications. First, soldiers and their squad leaders confessed confusion about protocol for fighting in a densely populated civilian environment and felt as if they could not protect themselves or civilians. At one point, two different groups of U.S. forces waited to hear from each other, each assuming that their counterpart would contact them first. In this period, the second Black Hawk helicopter was shot down. Second, several times during the mission, helicopters experienced landing delay or displacement because of clouds of dust stirred up by the rotors. Dust also inhibited squadron movement, leading to a large group of Rangers being immobilized in the city. The rescue mission was substantially more difficult because of assumptions in knowledge of protocol, communication, and conditions.
Moreover, political and social assumptions dictated the strategic position toward calamity. Defense Secretary Les Aspin stepped down following Mogadishu, admitting responsibility for the failure, as he denied requests for additional armored vehicles and tanks in the operation. This move was based on assumptions of Somali support for the American endeavor and of superior capability in communication through more advanced technology. However, as Matthew Bryden—a Canadian who was working with a relief organization in Somalia—describes, Somali animosity was cultivated in the three months leading up to Mogadishu through air strikes on the city. One such airstrike killed at least 60 people, including local leaders and elders, only some of whom supported extremist ideologies. Furthermore, Bryden credits the complicated inter-clan loyalty structures as fomenting resistance to Americans. Unfortunately, American strategy overlooked these realities, thus jeopardizing the operation.
The effects of these presumptions were exacerbated by a military dedication to hierarchical leadership structures. Orders from higher-ups were taken as absolute, which inhibited the ability of subordinates to point out assumptions. The Black Hawk Down case study showcases the danger of assumptions, and that even the most competent of teams can be hurt by them.
Case Study: Energy Company
This case study in assumptions was experienced first-hand by the author. The company's name has been removed for confidentiality and because its case examples are similar to other companies the author has encountered.
In 2010, a Fortune 100 energy company was in the midst of its expansion in the Marcellus Shale area. Its Pittsburgh office was abuzz with activity. Staff from other parts of the company's locations were on loan to get their presence established—contract admins from Houston, engineers and project managers from the Rocky Mountains, etc. Already, the customer demand for projects was well beyond what this team of more than 70 people could support. They were working very hard—long days and nights and weekends—but, were they working smart?
The company is a well-established operating company in the midstream natural gas industry. Its main purpose is to develop transmissions systems from the customer's (drilling) well site to the refinery and storage facilities. For more than 40 years, they had operated primarily in the Rocky Mountain and Gulf of Mexico regions, expanding or enhancing their assets to support their customer's needs. With the energy boom that started in earnest in 2011, the customer demand skyrocketed. Add to that, the new hydraulic fracturing and horizontal drilling techniques that enabled upstream (drilling) companies to access new areas with less cost. A “large” project for this company had been US$10 million prior to this boom, but now projects were in the US$25-50 million range. The company's capital expenditure (CAPEX) more than quadrupled within one year. By 2012, the Utica Shale became the next growth area, followed by the West Virginia and Ohio areas in 2013.
Exhibit 2: A map of the oil and gas areas in the northeast United States.
The situation this company found itself in was not unique. Hundreds of other oil and gas companies were now rushing into these new areas in the Northeast and the Dakotas (Bakken area). Most of these companies came from the Southwest area which had been a fairly static market for decades—demonstrated by the fact that very few Generation Xers were working in the oil and gas industry (a workforce issue from which it is still recovering).
Symptoms
There are two symptoms that illustrate how the ossification of assumptions existed in this company's Pittsburgh location. Both symptoms are understandable, based on the pressures that these project teams faced—in scale, speed to delivery, and change—yet, they did not have to occur. The resulting lack of assumptions management discipline led to millions in wasted dollars spent.
Symptom #1: Scheduling Assumptions
In 2010, there were more than 60 compressor station projects being planned. These projects often ranged from US$7 million to US$30 million in budget, and 12 to 18 months in duration (from start of engineering through completion). Prior to the Marcellus Shale expansion, most project managers used 10-20 lines in Microsoft Excel or Microsoft Project to manage their schedule. Some used only a whiteboard or notebook. These project managers were also used to only managing one or two US$1-5 million efforts simultaneously, with contractors who knew the region (e.g., Rocky Mountains), the equipment, and had direct contacts for environmental permits. In Pittsburgh, these project managers were now managing 5-7 projects at a time, in a whole new area, and with new players.
The company recognized it needed a more detailed, consistent schedule template—one that could also improve schedule predictability and high-level milestones to support the commercial group's needs in the business development process. In developing the schedule template, each functional area—engineering, permitting, procurement, land, construction, etc.—was interviewed to determine activities and establish those that had set lead times. For example, a certain compressor model would have a lead time of 18 months, and a certain air permit would have an assumed lead time of 12 months (as published by the responsible government agency).
As the schedule template developed, it became apparent that the overall project durations that the commercial team was using to secure customers (and commit to contractually) were woefully shorter than the project durations coming from the template. Despite this reality-based schedule, project managers would repeatedly reduce the durations to what they believed they needed in order to achieve a date or duration. For example, several projects required an environmental permit that had a 90-day application approval period. Yet, due to the massive number of application filings occurring, the permitting functional owner related that the current “real” duration was 120 days on average. The project managers would repeatedly reduce that duration in the template back to 90 days, because it had a critical path impact on the completion date. Subsequently, the projects for the first few years completed closer to the durations defined in the templates, but missed the customer-expected dates because the project teams had rejected the template's durations.
This was a failure to validate assumptions that could be validated. A phone call with a vendor to confirm the procurement lead time or listening to the functional owners who understood the reality of their area would have ensured more consistency in project delivery and would have reframed the risks and issues for the teams. The latter two reasons of why assumptions happen—the rush to planning and through execution—were on full display.
Symptom #2: Complacency
Another symptom of failed assumptions management was complacency—the acceptance that projects in this region would act and run the same way as other regions. The basic question of, “how is this different from where we have been?” was not asked.
One example of this was blue granite. Blue granite is a very hard rock. To get rid of it required blasting and removal. The Marcellus area was full of blue granite, and it affected the duration and effort required to level a site location prior to construction. This was not the case in the West, where site work (preparing the location) occurred. As contractors from the southwest moved into the northeast, they brought their assumptions of how things worked with them. On one project, the site work was estimated to last three months. After nine months of work, it was still incomplete. The contractor cited the amount of blue granite and the difficulty in removing it as being the cause. Yet, when the project team pointed the contractor to the original geotechnical survey (which was completed months before the project started), it noted every sample demonstrated blue granite, the contractor responded with, “we thought those were just a few pockets of granite and that the whole site wouldn't be [blue] granite.”
Again, this was a failure by both the contractor and the project manager to recognize: (1) this may be a different geology than previously worked; and (2) the assumption needed to be further validated earlier in the process to reduce risk. The ultimate result? For that specific project, the delay was more than 18 months. But this assumption further affected most of the other projects occurring simultaneously, and for months to come—because the project teams would not accept that the area was different.
The Technique
To better identify and manage assumptions, the following Knowns & Unknowns technique can be applied. It is used in military planning and missions, and is successful because it is simple and works at all layers of command. It quickly answers the three basic questions posed in the introduction to this topic and enables more thorough planning and/or discussion:
- What assumptions are there that we know (validated)?
- What assumptions are there that we can know, but have not validated?
- What assumptions are there that we cannot know?
Although the enumeration of Known Unknowns, Known Knowns, etc. is often accredited to Donald Rumsfeld, he writes in his memoir that he first heard the phrase when working with NASA administrator, William R. Graham. Graham explained the Known Knowns technique as a way of reigning in assumptions while serving on the Ballistic Missile Threat Commission in the late 1990s. Prior to the formation of this theory, it was common for assessors to assume that because something could not be proven true, it was likely false, leading to a misjudgement of a country's missile capacity. The Known & Unknowns technique avoids the assumption(s) by offering other classifications.
Knowns & Unknowns
As Exhibit 3 illustrates, there are four categories of information. Each category consists of two words, with those words being either: “Known” or “Unknown.” The word in the first position of each category states whether or not we have identified the data point—a “Known” (in that position) means we have identified the item—usually during planning (proactive); while an “Unknown” means we did not identify it—this is an issue now that we have to respond to (reactive). The word in the second position of each category states whether or not we can control the data point—a “Known” in that position means we can control it by validating the item—whether now or in the future (fact), while an “Unknown” means we cannot control it (risk).
Exhibit 3: Categories of knowns and unknowns.
Known Knowns are assumptions that have become facts. When placed in the context of assumptions management, these facts often represent constraints or former assumptions that have been validated. They often become embedded in the scope definition through requirements and in the schedule through activities. If a Known Known later changes, then it may (based on impact) cause a change order to be initiated, because a “fact” that the team based its scope, cost, or schedule upon, is no longer valid. Known knowns that could conceivably change over the lifetime are especially important to identify so they can be monitored for potential risk.
Known Unknowns are assumptions surrounded by uncertainty—we have not or cannot validate those assumptions. Most assumptions identified during project planning start in this category and these are most commonly captured in the “Assumptions” section of project charters and plans. The items in this category fall into three types: (1) those that can become “facts” now if they are validated (require additional actions); (2) those that can become “facts” at some point in the future, but not now; and (3) those that cannot become “facts” because we cannot control them. This last type should become risks in project planning, such as an estimated weather delay for a construction project, because the team cannot know what the weather will be—they cannot only know it until after it has passed. It should be captured as an “Assumption” and as a “Risk.” The first type are candidates to be validated and then moved into the Known Known category as quickly as possible. This type is something we can control today and reduces our overall risk of failure. It should be part of the “Scope Statement” and could have a severe impact on the project if changed. This type should also be noted as either an “Assumption” or a “Constraint.” The second type are candidates that need to be scheduled or managed through date trigger points in an assumptions or decisions log so that they are not lost during project delivery. When the trigger point occurs (event-driven) or comes due (expected date), then it should be moved to the Known Known category. These should be noted as “Assumptions” and “Risks” and, for those that could severely affect the project, they should be added as “Validation-” or “Decision-Milestones” in the project schedule.
Unknown Knowns are issues to which the project must respond. But really, they are an assumption that could/should have been identified prior to occurring, but was not and became an issue that affected the project. They are generally avoidable with proper communication and/or interaction. An Unknown Known often happens when different functional areas know certain rules or requirements and fail to be asked or to raise them. They can also be an effect of organizational siloes or poor engagement. An example of this is when one project manager works with a township and realizes that their permit application will be reviewed for approval only monthly at a council meeting (most municipalities review and approve on an ongoing basis). If they are missing certain pieces of information, the review will be delayed by at least a month. After experiencing this (usually through a schedule delay), the project manager doesn't relate this to his/her peers. The next project manager goes through the same pain and impacts. This is a data point that could have been an assumption used by the second project team, however, they lacked awareness (and they failed to ask their peers for insights as well). This lack of knowledge sharing led to an issue that the second project manager experienced. The goal of an Unknown Known is that it should be shared through lessons learned and become a Known Known for future projects.
Unknown Unknowns are also issues to which the project manager must respond. They are issues that were not identified as risks and could not be controlled—true surprises. An example of this would be when a project has a major delay due to a political coup in the country where the equipment is being manufactured. This causes a substantial impact to the schedule and there is nothing the project manager can to do to control it. The goal of an Unknown Unknown is that it should be shared through lessons learned for future risk consideration for projects as a Known Unknown.
Applying the Technique
So, how does this work in action? The following technique can be applied to various needs—from planning meetings to decision-making sessions to crisis planning. It can be managed in a quick burst or over a few days, depending on your time sensitivity and complexity to risk tolerance level.
Supplies:
- Flip charts or whiteboards
- Sticky Notes
Steps:
- Take four flip charts, and write the following titles, one per chart: KK, KU, UK, and UU. If this is a whiteboard, then create four quadrants (mirroring Exhibit 3), and write the same title in each quadrant.
- Give each person a stack of sticky notes. Have them write one information item or assumption per sticky note.
- Ask them to place the sticky notes in the quadrant(s) to which they believe are applicable.
- Evaluate the sticky notes first for, “are they valid assumptions? Are they written correctly and completely?” Beware of vague statements, i.e., “Weather” or “Approvals.”
- Then, evaluate the sticky notes to determine if they are in the correct location. If you are in the planning phase of the project, there should not be any sticky notes in the UK or UU quadrants because, if you are discussing the item and it has already happened as an issue, then you are identifying it (which makes it a KK or KU). The most difficult items to assess are assumptions that have not yet been validated, which should be KUs until they are validated.
- For those items in the KU quadrant, review them to determine which ones can be validated either now or in the future, so that they can be controlled. Capture trigger dates for when they can be validated.
- For those in the KK quadrant, capture them in the relevant logs or documents in Scope, Assumptions, or Constraints.
- For those in the KU quadrant, capture those with trigger dates in the schedule and/or assumptions log. For those that cannot be controlled, capture them in the risk log.
- For those items that are captured as Assumptions, the next step is to quantify them. There can be a number of approaches to measure and prioritize assumptions, but the one in Exhibit 4 is simple and enables a rapid rating. Based on the score generated by multiplying the Confidence by the Severity (Score = Confidence x Severity), and then considering the trigger date, a list of prioritized assumptions is created.
Exhibit 4: Assumptions quantification criteria.
Conclusion
Black Hawk Down Aftermath
Following the public and political backlash in the United States, the U.S. military sought to simultaneously attempt to sweep the battle from its mind, while also withdrawing its presence in Somalia. The U.S. Army did not pursue an investigation or complete lessons learned of the event—it wanted to forget it as quickly as possible. It wasn't until Mark Bowden researched and later published his book, Black Hawk Down, that an account of what happened become public knowledge. It was also the first documented lessons learned report, later used by the military for improvement opportunities.
Quietly, though, rising leaders such as David Petraeus, Ray Odierno, Stanley McChrystal, and Harold McMaster, took lessons from the event that they would later apply (and sometimes relearn) in Iraq and Afghanistan. One key lesson was how technology should be used in battle. The new technologies that enabled the Battle of Mogadishu's U.S. Army general and his command to see the battlefield and communicate with their platoon leaders in real-time, led to micro-management of the situation. Despite this fact, they did not have a complete view and their communications led to more confusion of the troops engaged in combat. The backseat driving of the convoy from the planes above would be humorous if it wasn't so sad. Brave American soldiers lost their lives. Their leaders had good intentions, but their failure to manage assumptions—strategic and tactical—contributed to this loss.
Energy Company Aftermath
For a few years, the Marcellus region saw companies continue to flail and flee. Many left the region completely, seeking safety in other areas. Some went bankrupt, having overspent and over-leveraged their capabilities. But for some, they learned and adapted. They started sharing information and recognizing that assumptions could be managed. In 2011, a seasoned project manager selected a location for a site based on a Google map. The land was purchased without an onsite visit. The schedule and cost estimate and customer contract were created without an onsite visit. The key issue was that this site sat atop of an abandoned mine. Instead of knowing this ahead of time (and they easily could have), or moving the location prior to construction, the project manager elected to stay because the customer was told, “that would be the location.” After a US$9 million cost overrun from filling the mine with concrete to meet code, and a 12-month delay in schedule, the site was completed. While this is slightly comical, it is also unfortunate that this site became another victim to a lack of assumptions management.
Flash forward to today—the same company in the same area—and you see young, less experienced project managers and teams leading four times more projects than they were in 2011. They ask a lot of questions because they are new in their role, and they share information across teams and functions. They take lessons from issues and apply them immediately. Not every project is a success, but there has been a substantial reduction in cost and schedule overruns. Google maps are still used, but they are now in a consolidated database that enables updates from other teams to share their data across the region. The likelihood of that Google/mine location failure happening today is negligible. Assumptions identification and management has become embedded in the culture of this organization.
Final Thoughts
Assumptions are elemental to project management—in our language, our planning. They are often referred to as the “silent assassins” because we don't recognize them until it's too late. The above technique provides a quick and simple approach to identifying them and determines which assumptions we need focus on first. Sometimes, all it takes is a phone call or an email to get an answer. Yet, so many teams fail to take that step. Don't become a victim of assumptions—coach your team to see them, rate them, and resolve the assumptions they can, while managing the rest as risks. It will shift team members out of daily fire-fighting into a more proactive, disciplined team as ossifications of assumptions dwindle in their frequency.
