Words matter.  Even in project management.

Words can carry meaning far beyond their formal definitions.  Connotation and perception can have unintended consequences. 

Even basic project management terms can create misunderstandings that can disrupt or derail a project.  In this article, I expose some linguistic pitfalls impacting the profession.

Project

The Project Management Institute’s formal definition of a project is “a temporary endeavor undertaken to create a unique product, service, or result.” It has a secondary definition of “creating value through unique products, services, and processes”—a subtle but significant difference.   

Projects are temporary.  They must have a beginning and an end.  Many don’t.

Projects are unique.  Many things we call projects fail this requirement. 

Creating value is a great aspirational goal.  Defining it is hard.  Achieving it is even harder.

Products are easily understood.  They are tangible. 

Services are harder to define because the outcome is not physical. 

Results are outcomes—better, faster, and cheaper are common ones.  We want to be more efficient.  Reduce costs.  Increase revenue.  Be more Agile. 

To be honest, I am baffled by the second definition.  Why were “results” dropped and “processes” added?

So, does everything we call “projects” meet the definition?  Probably not. 

Hybrid Project Management

I admit that I am biased.  I do not like the word “hybrid.” 

Years ago, I wanted to purchase a second bike to pull my (then) toddler son in a trailer.  I asked a friend for advice.  He said, “You have your triathlon bike for racing.  If you buy a mountain bike, it’s like owning a jeep—rough and rugged.  If you get a hybrid, it’s like owning a Chevy.  There is nothing cool about that.”  I bought a mountain bike. 

Waterfall, Agile, and Hybrid labels imply three clear, discrete options.  But they are not.  They are ranges on a longer continuum.  We can describe the attributes of Waterfall and Agile.  But Hybrid defies a clear definition. 

A PMI Journal article described Hybrid as an “approach, which combines traditional and agile… At its most general level, a hybrid project management approach combines methodologies and practices from more than one project management approach.”   Sounds great, but not very useful. 

Disciplined Agile describes itself as a “hybrid toolkit that harnesses hundreds of agile practices.”  The DA toolkit provides a wonderful, curated list of best practices.

A PM Network article was titled, “Hybrid Approaches Can Sow Confusion; But If Thoughtfully Developed, They Will Deliver Value.”  I agree with the title.  Unfortunately, the guidance was not actionable.     

I like the concept of Hybrid project management.  I believe great project managers have a comprehensive grasp of principles, processes, and practices.  However, I would like a label that is not Rorschach Test.

Project Manager

According to PMI, the project manager “leads the team that is responsible for achieving the project objectives.” 

This definition is generally understood to mean that the project manager is accountable for the project’s success.  Some say the PM is “large and in charge” and see this as a badge of honor.  To others, it carries the pejorative connotation of being domineering or overbearing.    

Rarely does the accountability standard apply.   As Bob Dylan sang, “You’ve got to serve somebody.”  At best, most project managers are the proxy for the responsible person(s).

In earlier versions of the PMBOK® Guide, PMI differentiated project management roles and levels of responsibility—project manager, coordinator, and expeditor.  Those distinctions disappeared a decade ago.  So, we no longer have formal industry guidance.    

Job titles versus project roles also create confusion.  Titles are static and define stature in the organizational hierarchy.  Roles are dynamic and describe responsibilities on a specific project. 

It is easy to understand why there is so much confusion.  Generically, it is easy to label someone a project manager, but defining expectations in the constellation of the project stakeholders defines them. 

Scrum Master

The Scrum Master title also deserves scrutiny. 

Jeff Sutherland and Ken Schwaber called the leader of the Scrum Team the Scrum Master.  The word “master” has multiple definitions.  As an adjective, it includes someone skilled or proficient.  As a noun, it can be an artisan qualified to teach apprentices.  Both of those definitions fit. 

The first version of the Scrum Guide described the Scrum Master leading and coaching the team, and “[being] responsible for ensuring that Scrum values, practices and rules are enacted and enforced.”  While the definition has morphed over the years, it is still consistent with the original intent. 

In my opinion, becoming a Scrum Master has become too easy.  Most frameworks only require a 2-day class and a relatively easy exam to become “certified.” These classes are often very good introductions to Agile, Scrum, and often practices.  However, they are not adequate preparation to be a master. 

As the Scrum Guide states, Scrum is easy to understand but hard to master.  Exceptional Scrum Masters earn the distinction the hard way—through trial and error.  They recognize that each team and project is unique and make context-sensitive decisions when selecting frameworks and practices.

Scrum Master has become a branded name for a generic role, like Kleenex, which is synonymous with facial tissue.  Recently, some frameworks have started using different titles to describe the role.  SAFe adopted the hybrid label “Scrum Master/Team Coach.”  Disciplined Agile calls them “Team Leads.”   Not to be excluded, people can also be Kanban Flow Masters.

Regardless of the project approach—Agile, Hybrid, or Waterfall.  Regardless of the framework or methodology—Scrum, Kanban, Lean, Waterfall.  I like calling the person leading the project the “project lead” or “team lead.”  At this point in time, the word “leader” has fewer pejorative connotations than other titles, and it generally describes what needs to be done.

Project Success

When we finish a project, we often invoke the word “success.”

Project success is typically measured against the “triple constraint.”  Did the project deliver the expected scope within the planned budget and timeline?  On the face of it, that sounds like the perfect metric.  However, historical performance against these targets is disappointing in 2021:

• 73% of projects met the original business intent, and 12% were deemed a failure;
• 62% were delivered on budget, and
• 55% were delivered on time.

There have not been significant changes in these and similar measures over the past 30 years.  If this is the historical state of the industry, are we measuring the right things?  Or are we just destined to be mediocre at our performance?  Maybe we should come up with a different label to describe finishing a project.  Maybe survival?

© 2023, Alan Zucker; Project Management Essentials, LLC

See related articles:

• Making Sense of Agile and DevOps
• Project Frameworks: Understand the Choices
• Project Management: Principles, Practices & Context
• The Project Manager and the Scrum Master Should be Friends

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/.

Image courtesy of:  National Geographic