Common sense is when everybody around me agrees with my perception of reality, without my having to tell them.
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 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 life experience is that I have to let go of my ego and create common sense (everyone understanding common terms, procedures, definitions of quality, etc.) instead of just hoping for it and being disappointed when it doesn’t manifest.
There are four terms that help define common sense as it pertains to a systems integration project and its key stakeholders: assumptions, risks, constraints, and issues.
Many integrators collapse or confuse the four terms, and thus have a difficult time effectively managing required responses. Other integrators 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.
Other integrators, however, are beginning to see the value of managing assumptions, risks, constraints, and issues across similar projects. They are 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 is how.
Assumptions
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 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 are making assumptions (some would say we are “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 is 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, with the likelihood that changes will occur during the endeavor. To plan the project, each person must make assumptions, whether they’re communicated or not.
You have 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 cannot start without them. They are 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 endeavors 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 should not 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
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 (we know a piece of equipment will fail, but we do not know which on or when). These known unknowns 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 have solved in the past, but it is 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 client 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
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. Constraints placed on a project by the client should be listed in the scope of work because they will often increase the amount of risk to the AV company and should therefore increase the client’s price. 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 client project kick-off meeting.
Issues
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, the expenditure of contingency funds, and duration.
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 savings in cost and frustration.
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.
This article comes from our partners at Navigate Management Consulting, and has been published with their express permission.
Would you like to learn more?
Join Navigate Academy!
Solutions360 is a proud sponsor of Navigate Academy, the new online learning platform designed specifically for systems integraots.
Don’t miss the next live webinar
Friday, Sept 11 @ 11:00 am CDT
Title: Scope of Work
Handpicked Related Content:
