What is a frog?

Right now you are probably thinking of a small amphibian with long legs that some like to eat. But, the word frog has many meanings:

• A decorative clasp joining the collar of a cape.
• A metal plate used in railroad switches and crossings to guide the wheels across gaps.
• A device used for arranging flowers.

Actually, there are more than twenty different meanings for the word frog. The one that correctly conveys the user's meaning depends on the context within which it is used.

The traditional professions, law and medicine promote clarity in communication by using Latin. They chose Latin because it is a dead language; that is, it is no longer spoken by a living population and, thus, the meanings of words will not alter through popular usage. Unless the human body mutates radically, an ulna will be an ulna forever and legal scholars who depend on the stability of precedent will interpret a mensa et thoro with unwavering regularity.

The Language of Project Management

Since the founding of scientific management during the Industrial Revolution and during its metamorphosis into the modern practice of project management, different words have been used to convey the same meanings. For example, tasks in Microsoft Project (arguably one of the most popularly used computer applications to plan and monitor projects) are referred to as scheduled activities in more traditional applications. Apparently fearing that the lack of a professional etymology for all terms used in project management might be at the root of failures and cost overruns, the Project Management Institute (PMI) has set itself a goal:

“The PMBOK® Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. Such a standard vocabulary is an essential element of a professional discipline.”

Inasmuch as PMI has not shown any inclination to adopt a dead language for their professional vocabulary they must devise and implement it using the popular vernacular of each country in which they operate. I do not know how much success they are having in other countries but in America their success thus far has been somewhat spotty. Consider the following example:

PMBOK® Version 3 defines task as “A term for work whose meaning and placement within a structured plan for project work varies by the application area, industry, and brand of project management software.” Ignoring for a moment that they aver that task is synonymous with work, they are correct in their assertion that the usage of task varies. However, it is difficult to find any application area, industry or brand of project management software that uses task synonymously with work as PMI defines work; “Sustained physical or mental effort, exertion, or exercise of skill to overcome obstacles and achieve an objective.” Sorry, that is not how others use task. In popular usage, you may assign a task or work to someone and mean approximately the same thing. But, using them as verbs, “tasking a person” and “working a person” have completely different meanings. Generally, in project management task refers to a scheduled activity and work refers to the effort required to complete a task.

Fortunately for students of PMBOK® there are only two occurrences of task within the entire text and both may be interpreted accurately relying only on popular usage. They will be led astray only if they attempt to interpret if they have been using Microsoft Project and attempt to interpret it as a scheduled activity when they read the following from the 3rd Edition:

“For example, late recognition that the legal department was a significant stakeholder in a year 2000 rollover (Y2K) software upgrade project caused many additional documentation tasks to be added to the project's requirements.”

“Additional documentation tasks” is easily interpreted so long as the reader does not apply the definition of task as provided in the Glossary of the 3rd Edition of PMBOK® in which this quote appears. Tasks interpreted as scheduled activities are incremental steps in the logical network of a project plan. Again relying on the Glossary, tasks are not a part of a project's requirements.

Jumping to the defense of PMI, we must observe that PMBOK® Version 3 has been replaced. Let's see how PMI handles the issue in the recently published 4th Edition of PMBOK®. Looking to its glossary we find that both task and work are now omitted! Surely then one might think that they must have removed all references to task from this new edition. However, we find there are twelve references to it in Version 4 whereas there were only two in Version 3! How then are project managers to define its usage in each case as they read and study PMBOK®?

Ambiguity Has No Place in a Professional Vocabulary

“Do as I say, not as I do” does not work for leading or inspiring others to adopt a professional vocabulary any better than it works for parents attempting to civilize their children. For PMI to effectively promote adoption of its professional vocabulary it must use it themselves and use it consistently; especially in PMBOK®.

A lack of consistency in both PMBOK® Version 3 and Version 4 is clearly evident using just one example; the usage of stakeholder.

Stakeholder has long been used popularly to identify those with the greatest interest in the outcome of a project; those who pay for or approve its deliverables. PMI attempted to clarify this by including the following definition in the Glossary of their 3rd Edition of PMBOK®:

“Stakeholder. Person or organization (e.g., customer, sponsor, performing organization, or the public) that is actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.”

This definition was greatly expanded and expounded upon in section .2 of Chapter 2 of the 3rd Edition of PMBOK®. It averred that key stakeholders include the project manager, customers/users, the performing organization, project team members, the project management team, the sponsor, influencers, and the project management office (PMO). In other words, any one or any group that has an interest in or influence over the outcome of a project.

Curiously, stakeholder was omitted from the Glossary of the new 4th Edition, however, Chapter 2 provides the same definition as found in the Glossary of the 3rd Edition and reaffirms the above list of stakeholders then adds a few more.

Generally, however, most references to stakeholder throughout both editions of PMBOK® are ambiguous. They do not differentiate which key stakeholder is implied. While some references are easily interpreted, many are not. For example:

“When dealing with any stakeholder, practitioners should be committed to honest and fair practices and respectful dealings.”

“Enterprise environmental factors include, but are not limited to... Stakeholder risk tolerances.”

“The generic life cycle structure generally displays the following characteristics... Stakeholder influences, risk, and uncertainty, (as illustrated in Figure 2-2) are greatest at the start of the project.”

“Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project life cycle. Their responsibility and authority may range from occasional contributions in surveys and focus groups to full project support, which includes providing financial and political support.”

“The PMO can provide... Centralized communication among project managers, project sponsors, managers, and other stakeholders.”

The connotations to be applied to the use of stakeholder are easily interpreted in the first and last above cited examples. In all others, there is ambiguity. Such examples abound in both editions of PMBOK®.

Last Word

Some may argue that all of the above examples of the usage of stakeholder can be interpreted with a little common sense. However, common sense is an uncommon commodity. That is why we are admonished to “Say what you mean and mean what you say” in contracts, raising children, and building relationships as well as in setting standards for professional practices.

Generally, the 4th Edition of PMBOK® vastly improves on the 3rd. PMI has repaired some portions and yet others remain in need of attention.

Throughout this paper it has not been my intent to be critical of PMI and its publication but rather to provide constructive criticism. As a student of Law holding a Juris Doctor as well as having more than 30 years experience managing and often rescuing projects I believe that PMI is on the right track but have not yet arrived at their journey's end.

About the Author

Jack Durish is the Interim IT Executive. He has helped organizations of all sizes including global ones discover and adopt creative technological solutions to real business problems. He has participated in every aspect of exploring emerging technologies, evaluating them, and deploying them. He has also aided in their adoption, training and motivating users to maximize the return on technological investments.

Jack has more than 30 years experience planning projects, scheduling tasks, and managing teams in government and military operations as well as private industry. He is a creative problem solver with a proven track record of surmounting risks to complete projects on time and on budget.

Jack is a skilled communicator. He is a published author of books both fiction and nonfiction as well as IT courseware and articles. He is an experienced lecturer in the boardroom as well as the classroom having mastered the ability to both instruct and persuade audiences of all sizes and types.

Visit his website at http://www.ironlantern.com/