The three most misused terms in project management

From the Easy in theory, difficult in practice Blog
by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

How hidden are your hurdles?

Negativity is the Dark Side of the Project Management “Force”

Are you being (responsibly) transparent?

Don’t get blindsided by stakeholder influence

What if the PMBOK Guide was a Choose Your Own Adventure® book?


Categories: Project Management


Although PMI has provided a glossary of terms in the back of the PMBOK Guide for many years, too many people continue to confuse others (and themselves) through the use of some common terms.

Sure, a rose by any other name would smell as sweet, but in our profession we have a hard enough time bridging expectation gaps to make things worse by calling a spade something other than a spade.

In no particular order, here they are:

Project charter: The document that PMI defines as “a document issued by senior management that formally authorizes the work of the project to begin (or continue) and gives the project manager authority to do his job” has been confused with everything from a project plan to a vendor contract to a Statement of Work.  As the name itself implies, a charter is needed for “chartering” – it is not the plan.  The plan should follow the charter and not the other way around.

Project plan: As per PMI, the project plan is “a formal, approved document that defines how the project is executed, monitored and controlled. It may be summary or detailed and may be composed of one or more subsidiary management plans and other planning documents”.  However, if you were to ask most people what a project plan is and they will very likely say “that’s what you create in MS Project”.  Not only does this create confusion, but it also reduces the perception of the planning phase of a project to “creating the schedule”.  Forget about risks, budgeting, quality, scope, communications, procurement, human resource planning and so on.

Risks vs Issues: This has become a standard part of every risk management presentation or consulting engagement that I do.  I’ll never assume that the audience understands that a risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives”.  Although PMI does provide a definition for an Issue, I prefer to define an Issue as an event that has occurred that, if left unresolved, will impact one of the objectives or success criteria for a project.  Many times when I ask a client to describe their project risk management methodology what I will get is a review of their project issue practices.

You may wonder why I wrote an article on this – this lack of consistency and precision is a contributing factor to why project management has struggled to be recognized as a profession.  The work of associations like PMI, IPMA and others is helping, but we (as the practitioners of the profession) need to incorporate this consistency into our daily interactions.

(Note: this article was originally published on kbondale.wordpress.org in September 2009)

Posted on: January 02, 2019 08:58 AM | Permalink

Comments (14)

Please login or join to subscribe to this item
Well said, Kiron!
I would like to add one more thing. Lack of training in Project management is a relevent factor of misusing technical terms. Most of project managers didn't get a college degree in project management but in some other technical specialty and had to learn the profession on the job.
I believe that formal training in project management is mandatory at some point of a project manager's career in order to structure the knowledge acquired through experience.

Thanks Yassine! I agree that a basic grounding in project management through a course is a good idea.

Kiron

Nice post, Kiron. And wow, ten years ago :)

'Project Plan' is the one I see as the most misused term.

Thank you for posting here Kiron.
I agree - one of the challenges is the level of understanding of "Project Management" by Project Sponsors. How many PMs end up writing their own charters? or being told to forget all about the charter and get into the plan (referring to the schedule)?
Once a sponsor understands Project Management, a project charter, a plan (including a schedule) and a risk/issues terminology and management would be much easier for any PM.
I usually also add that an issue is a risk that has either eventuated or its likelihood of eventuating is 100% (given that nothing has been done to mitigate it).

Goodness ! such fundamental mistakes are prevalent even today?

Very True. Quite Interesting Points. Bang On , Thanks for sharing it.
Well Point added By Yassine.

Good article Kiron!

Thanks all and thanks Andrew for recognizing the "vintage" of the article - I wrote my very first article on my personal blog in late June of 2009 so I'll be celebrating a decade of writing later on this year!

The article is still very relevant and up to date. Will share it with the team.
Agree with Yassine and Amany points regarding training and the fact that many PMs still end writing their own charters.

Thanks for sharing your "vintage" post :)

Very interesting insights Kiron!!
Thanks for sharing.

Good topic Kiron!!

Kiron, in order of people haiving doubts are 1. No clarity on Issue and Risk in fact this is an interview question. 2.Project Plan: you have rightly said in fact many project managers believe project plan is ONLY about project schedule 3. Last is Project Charter: let me share an incident when one of my colleauge said it Work Statement ...

That's a good definition for "issues" Kiron. As for project plans, in an Agile environment they sometimes don't exist, although the planning elements (knowledge areas as per PMBOK) do in various formats.

What I found to create confusion is the inaccurate use of terms, that are clearly defined in PMBoK.
One example is that there is no such thing as a 'project plan', it is called 'project management plan', also to distinguish it from artifacts that might be called 'project plan'.
Another example is the confusion that the PMBoK process groups are project phases. They are not. The process groups describe the work of the project manager and are in themselves iterative and incremental. The phases are defined by the project lifecycle which is the sequence of work that creates the project output, it is therefor specific to the type of output in contrast to the process groups.

We must continue to consistently describe project management, respecting the standard, as the profession grows and gets approx. 1.5 million new members each year and hopefully more young people are attracted. They should not be confused.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"If we knew what it was we were doing, it would not be called research, would it?"

- Albert Einstein

ADVERTISEMENT

Sponsors