Creating Common Sense, Communicating Assumptions and Risks

Product Image

Type: Article, Report or Whitepaper

Topics: Project Management

Date: April 2012

By Bradley A. Malone, PMP

This is the seventh in an ongoing series of organizational project management articles by InfoComm University™ senior instructor Brad Malone.

Working on hundreds of projects and training thousands of project managers, I’ve often wondered why so few people around me have common sense. Many times I’ve discovered their lack of common sense three-quarters of the way through a project, which is a little late. I mean, they’re intelligent, hard-working, and committed to delivering a quality product and/or service, but sometimes they just don’t seem to think correctly.

First, let’s define common sense in a way that comes off as self-centered but actually holds true. Common sense is when everybody around me agrees with my perception of reality, without my having to tell them. In other words, they have common sense based upon my sense of what should be common. In my younger days, I thought everyone shared this definition — or at least should. What I’ve found as I’ve gained more experience is that I have to create common sense (everyone understanding common terms, procedures, definitions of quality, etc.) instead of just hoping for it and be disappointed when it doesn’t manifest.

There are four things that help define common sense as it pertains to an AV project and its key stakeholders (clients and their representatives, sales, project managers, implementation techs, service, etc.): assumptions, risks, constraints and issues. Many organizations collapse or confuse the four terms, and thus have a difficult time effectively managing required responses. Other organizations continue to expend little effort in their projects’ initiation and planning phases identifying and communicating all of the above, leaving their project teams in a reactive, fire-fighting mode when issues arise in the execution phase. These organizations often have to accept deliverables that don’t meet performance objectives in a project that’s already late and over budget.

Still other organizations, however, are beginning to see the value of managing assumptions, risks, constraints and issues across similar projects. They’re making efforts to invest time and personnel to identify them and proactively respond. In order to succeed, you should be one of those organizations. Here’s how.

To make it through each and every day, we routinely make assumptions in order to plan our activities, such as figuring the amount of time needed to go somewhere (grocery shopping, work, etc.), determining how long it will take to complete a weekend “to-do” list, or estimating out how much a vacation may cost. These assumptions are often based on our belief that past experiences will somehow shape future ones, especially if the future contains similarities to the past (such as our commute to work, which may have been the same for years). Although we might not think we’re making assumptions (some would say we’re “using common sense”), we definitely are.

An assumption is a condition that a person believes is true now or will be true at some future point in time. It’s often based on that person’s experience and creates the context in which the person makes decisions.

Now let’s put that person in the context of a project at work. Remember, a project is a temporary endeavor, undertaken to create a unique product, service or result. In order to plan the project, each person must make assumptions, whether visible or hidden.

You’ve probably heard the saying, “When you assume, you make an a** out of u and me.” But that saying and its interpretation are among the major causes of poorly initiated and subsequently failed projects. A more powerful and proactive saying would be, “Undocumented and uncommunicated assumptions make an a** out of u and me.”

Assumptions form the basis of the plan — a project can’t start without them. They’re so essential to projects that I often say, “Assumptions are the paper the plan will be written on.” This is because projects are, by nature, forward-looking events that blend similarity with uniqueness. The more similarity, the more we can use our past experiences to plan for the future in a predictable fashion. The more uniqueness, the more we have to make qualified guesses about what may occur.

Assumptions should be written down in a bulleted list somewhere prominent in the project’s Scope of Work. They shouldn’t be hidden in the terms and conditions or written into legalistic sounding paragraphs. Examples:

•  Room will be ready for installation (all construction and finishing complete) by April 30, 2012
•  All owner-furnished equipment (OFE) will have been tested and certified
•  Site will have a secure storage room

These assumptions are written as statements of fact, not hope. The client, sales rep and project manager must read and agree on the assumptions. If they are not true, or if they become false in the future, then a change order is necessary.


Risks are specific events (that occur in a time and place) that can impact a project negatively (risk) or positively (opportunity). They live in the realm of project information between total uncertainty and total certainty. A total uncertainty — or unknown unknown — is a surprise event that exists in the realm of ignorance, and is something for which you cannot plan (see Issues). A total certainty — or known known — is not a risk, but is something for which you must plan.

Projects always move forward with partial information, or information that sits somewhere between general and specific uncertainty. Specific uncertainties are often referred to as known unknowns — that is, you know what you don’t know. They provide you with powerful information that you must communicate to the project team and stakeholders. Many project managers think they must remember every problem they’ve solved in the past, but it’s more important to share with others a project’s known unknowns (risk events).

Risks can be identified from past projects by a range of stakeholders. They can be analyzed for timing, probability and impact (to scope, quality, schedule, cost or customer satisfaction). Once identified, they can then be avoided, mitigated, transferred, or accepted via a contingency or fallback plan. The management of risks often occurs within risk mitigation activities and the project’s contingency and management reserves.


Constraints are conditions placed on the project by internal or external parties, and they limit the project team’s options and flexibility. They can be viewed as a sub-category of assumptions and often impact the project in a negative fashion. Examples:

•  Room availability from 5:00 p.m. – 8:00 a.m. only
•  Loading dock and freight elevator must be used to move equipment
•  Contractors must receive new security pass weekly

All of these conditions expand the project scope, often making the project more difficult. Sales should ask the client if there are any project-specific or site-specific constraints before the project is estimated. The project manager should verify these constraints during the field verification audit and/or project kick-off meeting.


Project issues are incidents that definitely cause the project to become out of alignment. The occurrence of a risk event does not necessarily make it an issue. Issues happen via surprise, mistake, or a change in assumptions or constraints. The realization of a risk event may cause the project to be revised through a contingency or fallback plan —  the project manager shouldn’t need permission to exercise such plans, but does need to communicate their implementation.

Issues are bigger than the project manager’s authority to manage and usually require that a change request be initiated and moved through the documented project-change control process. Many project managers view project issues as fires they must try and put out. This normally exacerbates and prolongs the impending crisis, ultimately leading to a loss of credibility and professionalism in the eyes of the client.

Ideally, the employees of a mature AV integration company share with each other — and learn from — their project’s assumptions, risks, constraints, issues, mistakes and surprises. When a company starts to create a common understanding among its key project participants (owner, sales, estimators, project managers, implementation techs, purchasing, warehousing and service), common sense begins to prevail. With this common sense, each new project team learns from the past and avoids repeating the errors and omissions of old projects — often at an incredible cost.

Common sense is best created early, during project initiation, when the project’s strategy and direction are determined. But it must be cultivated — not just hoped for or relied upon.

Bradley A. Malone, PMP, is an InfoComm University™ senior instructor and president of Twin Star Consulting, an organizational excellence and program management consulting company serving multiple industries. He holds the Project Management Professional (PMP®) designation from the Project Management Institute (PMI) and is one of PMI’s highest-rated instructors. Please share your thoughts with him at