In 1998, NASA launched the Mars Climate Orbiter, a $300 million-plus spacecraft that traveled more than 400 million miles to the red planet. Even with speeds exceeding 3 miles per second, the journey took almost 9.5 months. Upon reaching its destination, the spacecraft fired its rockets to ease into a Mars orbit. Radio transmission was disrupted as the craft spun behind the planet and was expected to only resume 21 minutes later as it reappeared on the other side. Only it didn’t. The spacecraft was never heard from again.
NASA investigators determined that a definitional problem doomed the craft. The engine burn was timed to slow the craft down and place it in a safe orbit 68 miles above the surface of the planet. However, the instructions for the burn were wrong, resulting in the craft attempting to orbit Mars at a disastrous altitude of only 35 miles. The problem: The NASA’s spacecraft was programmed to use the metric system while the commercial contractor sent burn information to NASA using the English system (pound-seconds instead of Newton-seconds). The burn lasted too long; the probe attempted too low an orbit, and burned up in the Mars atmosphere.
This is a pretty dramatic case of the definitional problem. The engineers’ thinking was sound, their math was accurate, their numbers were correct, just the definition of those numbers (English versus metric) was misunderstood.
A contentious area, fueled by definitional problems, is downtime. Imagine a situation where every Sunday at 2:00 a.m., IT takes email offline for preventive maintenance. At 2:10 a.m., the VP of marketing tries to send an email to the head of Europe only to get a message that email is not available. Later that month, the VP of marketing is surprised to see an IT report saying that there was no email downtime for that month. Result: The VP resolves never to trust IT reports again.
Who is right? Was email down that month? Depends on what you mean by down. IT believes that down means an unscheduled interruption in service, while the user believes that down means the service is unavailable, regardless of cause. Both groups have well-formulated, complete, and appropriate definitions, both definitions are adequate, accurate, and acceptable. They just don’t agree.
Of more consequence is user management being told by IT that the total cost of their new accounting system will be $1,000,000, only to find that IT did not include in its budget transition, end-user documentation, or training costs. Question: who is correct? Answer: both.
When multiple parties are right, or at least not wrong, then the basis of the disagreement is probably definitional. In the example above, IT believes that the development cost consists of the hardware, software, and staffing expenses to analyze, design, code, and test a system, but not implementation, user documentation, and user training charges, which are to be borne by the user organization. The user believes that the check he wrote for developing the system was the entire cost of getting his new application up and running, and is unaware of any additional “hidden” costs.
The problem
Arguably, half of all IT-user disputes are definitionally based or exacerbated.
The definitional problem appears in multiple forms.
Problem 1: Multiple conflicting well-defined definitions — One word or concept can have multiple legitimate and accepted but inconsistent definitions. Each party is using a formal definition that is well defined, correct, and broadly accepted by users in the field, just different.
The NASA case is a good example of this. Both the NASA team and the external contractor used complete, accurate, and accepted definitions of thrust. Each used its definition correctly and arrived at a situationally correct answer. Each team was aware that there were two distinct legitimate definitions. Unfortunately, each team assumed that the other team was using the same definition it was.
Problem 2: Multiple but not all well-defined definitions — One word or concept can have multiple definitions, with at least one a legitimate, detailed, and correct definition and at least one an inexact, although popular, definition.
This is a huge category that can be very frustrating for professionals. It usually involves a very technical and exact definition that is used by professionals in a field and the same word having a similar but much less exact definition used by non-professionals.
Take the word, theory. For a scientist a theory is a proposition that has been tested, probably multiple times, and has been proven to be sufficiently correct to predict future events. In empirical science, there is no higher state of truth. The popular definition of theory is quite different. Non-scientists use the word theory to mean unproven and, at best, a guess.
The ambiguous use of theory has led to some interesting if fruitless discussions. Anti-evolutionists point out that evolution is only a theory and therefore not proven science. Scientists say that the fact that it’s a scientific theory says that it is proven.
Problem 3: Non-specific, fuzzy, or incomplete definitions — While there are words that do not have a specific and well accepted definition, it is often the case that some people know, or think they know, what they mean.
Many projects define effort in person-hours, person-months, or person-years; where person-year is the work one person routinely completes in one calendar year. Person-months are everywhere in IT and throughout many non-IT project-focused organizations as well. It is not an overly technical term and probably 95 percent of the people you meet on the street will tell you they know what it means. It is undoubtedly one of the most ubiquitous project-related terms. But what does it mean? Exactly how much work gets done in a person-year? Experience shows that the IT year can vary from fewer than 1,500 work hours to more than 2,000 hours. Why the difference? Many organizations remove activities such as vacation, training, and administrative time from the person-year. Other organizations believe that these activities are the cost of doing business and should be included in the definition. Some take a stand in the middle counting certain activities in the person-year, such as administrative time, but precluding others, such as vacations. Yet, anecdotal evidence indicates that fewer than one IT organization in four has an exact definition of effort, formally publishes the definition, communicates it to relevant parties, and ensures that whenever it is used it is used correctly.
This problem can appear in IT where two project teams, or an IT organization and an external contractor, have different and poorly communicated definitions for common systems development words.
Problem 4: Obfuscation — Sometimes words are used to hide rather than elucidate meanings. Just bought a 2019 Ford Focus? That’s a used car, while the 2016 BMW across the street is a pre-owned vehicle.
Interested in decision support systems (DSS)? Well that’s old hat. Years ago the DSS gave way to executive information systems (EIS). The difference? Well, if there is any, then at least 90 percent of it is marketing hype. The EIS? Well it was replaced with online analytical processing (OLAP). The difference? You guessed it. OLAP? Well it was replaced by, er, was it business intelligence (BI) or predictive modeling (PM)? Whatever! Were all of these the same? No, there were differences and improvements. Did all deserve a different name? No. General Motors might change the design of the Corvette every year, but they still call it a Corvette.
What you can do
This is one of the few IT areas where the solution is relatively simple, easy to implement, and painless to use.
Solution 1: Define, define, define —It might take a little upfront effort, but all technical and even business terms should be formally defined and placed in a project glossary. Do it once and it can be used again and again. The project glossary should be part of the contract between the user and IT—even vendors and IT. It can also be an appendix to reports, a chapter in development documents, or referenced as a stand-alone text.
Definitionally challenged? Find a source (book, vendor documents, websites, etc.) that you can live with in toto or as input to your own project glossary.
Solution 2: Define first, then develop —The project glossary should exist before any development is started, planning completed, or costs discussed. This is important for two reasons.
First, it is easier to gain agreement on terms before anyone has a vested interest in the definition. Agreement on who will pay for end-user training before any contracts are signed is a lot easier than the argument that can occur after budget finalization. Down the road surprises are almost never good.
Second, a number of mid- or post-project disagreements can be settled easily by referring to published and agreed-upon definitions. The same is true within the project team. Defining documentation or testing can abrogate many potential project squabbles as team leaders maneuver to meet deadlines.
Solution 3: Agreement on operational definitions is required; agreement on conceptual definitions is not — A conceptual definition is an intangible, theoretical, and abstract concept that you hold to be true. You might believe that man never landed on the moon, that climate change is a hoax, or that existence is not a predicate. That is your right.
An operational definition, also called a working definition, is an agreement to use a precise definition in a specific context. The context for an operational definition can be temporary (before the year 2000 or starting next year, etc.) or limited to a specific project, department, location, company, or even country. Operational definitions make it easier for everyone on a team to work together. For example, you might strongly disagree with the team’s definition of temporary storage, but, for the purposes of communication and team harmony, you agree to use it during the project.
Solution 4: Keep the definitions updated—Technology changes rapidly and vendor marketing terms even more so. The project glossary should be revisited at the beginning of each project to see whether any definitions need to be modified, new terms introduced, or old terms removed.
Unless you are a lexicographer, you probably do not find the subject of terminology that interesting and certainly not as a part of project management. It does have a sort of bowtie image. However, a great many of the problems a project manager will encounter involve IT and sometimes even business terminology. It is important that developers and users understand what is being said, even if they do not necessarily agree with the definitions used.
George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com.
