Do We Need A Common Project Management Language?

Several weeks ago, there was a comment on one of my blog posts about the need for project managers with personality. I agree!! And, as I said, if we can find people who communicate well and are good with people, we can teach them a project management process that works. One challenge is the increasing amount of project management lingo. For all of its value, the Project Management Institute keeps revising the PMBOK guide. And it hasn’t gotten any shorter. That means, more and more vocabulary and concepts to learn.

Is all this lingo actually improving project management though? I understand the need to include more agile concepts, but is fragmenting the overall project management approach in the organization improving project management? I’m inclined to believe that simplifying things and using the same words throughout your organization so EVERYONE understands what you’re saying would be a step in the right direction.

I believe we would benefit from adopting a common project management language that would allow us to compare projects across the spectrum — from construction to IT to change management, research and development, and financial services. In this blog, I’ll talk about some particular words that we could standardize and the benefits that we could realize by doing so.

Projects

Forget the official definition for now. That’s not the problem. The question is really about what kinds of projects the PMO(s) and/or business executives are interested in. That is going to vary from organization to organization.

I recently talked with a mid-level business executive in a Fortune 500 company who is convinced the C Suite is pretty happy ignoring individual project performance. They simply trust the people under them to ensure all trains are running on the track. I’m still pondering how I feel about that statement. I’d love to know what others think.

What kinds of projects do you need or want to monitor in your organization? Are executives trying to monitor ALL of the project investments, just the IT projects, or a group of the larger, more challenged projects?

Are client engagements being monitored in the same way that in-house projects are being overseen? I frequently see people in HR, marketing, compliance departments, or the office of general counsel working on projects that no one else knows a thing about. No tracking of labor costs is being done because salaried employees are doing the work. So, how can we compare those projects in a meaningful way?

First, you need to know what your long-term oversight goal is.

Work packages, activities, or tasks

There are many words that can be used to describe something that needs to get done on a project. User stories, activities, tasks, work packages, deliverables, tickets, action items, requirements, backlog, cards, and sheets. I’m sure I’ve missed some. Definitions can vary.

I recommend distinguishing between the larger work packages (I call them activities) and the smaller tasks that need to be done. You may also need a name for the major groups of activities for which you want to track summary budget data.

The point is to come up with a name for the level(s) of deliverables that you want to track across the organization. It doesn’t matter whether we’re talking about a building construction project where the activity might be to prepare the site for construction, an IT project where the activity might be to build a particular feature, or an HR project where the activity is to create an executive summary of a new compensation plan.

The challenge is to determine at which level(s) you want to monitor your project portfolio. In my experience, there are probably two levels where it pays to focus — at the activity level, or what PMBOK would call, the work packages level. And from the summary level — so those work packages that are at the top of the WBS hierarchy.

I’ve written before about how to break the project down. If it’s done well, the rest is much smoother. What matters is the size of the activities. If the size of the activities gets too large, the teams can never declare victory on anything. If they are too small, there are simply too many to track. The sweet spot seems to me to be in the range of activities that can be accomplished by one person, working full-time, in a two — four-week period — maximum. Some will more likely be in the 3–10 day range but they will vary. The goal is to set your team up for frequent small wins.

It’s also essential that we think of them as deliverables. I see some business, scientific, and legal projects where the activities involve a fair amount of time researching some issue. That’s appropriate — but where is the deliverable? We need to always be thinking about delivering incremental value to the client, or to the management team. The deliverable may be as simple as a short presentation with executives to outline the research findings and determine next steps. OR, it may be the final published training manual for a new piece of equipment that has been developed. You just need to align what your client is expecting with what you are planning to deliver.

People

Can we find a way to standardize what we call the various people on projects, regardless of whether we are using Waterfall or an Agile approach? I often think a Waterfall project is better managed by someone who coaches teams effectively and clears impediments, rather than assigning responsibilities. Perhaps there is a way to develop a core set of roles that will work across the board, with customization where appropriate.

In another comment to one of my blogs, someone noted that no one in HR knows anything about project management other than certifications. I’m sure that’s not true everywhere. And HR professionals cannot be expected to know everything. If we developed a common project management language and wrote strong descriptions about the positions that are available in our companies, that would help.

Maybe we really do need project managers, project leads, project sponsors, scrum masters, product owners, project champions, portfolio managers and directors, and program managers and directors, in the same organization. I’m not convinced that we couldn’t simply the conversation some.

Time

We need a way to monitor how long activities are going to take in a world where we really don’t know. I’ve proposed thinking about complexity rather than durations. In this context, complexity is a basic concept that allows us to compare the sizes of activities, and thus, projects, within an entire diversified portfolio of projects. It’s not the same as durations and is a much simpler concept. I outlined my thoughts on how to move from estimating durations to estimating complexity in a blog here.

When estimating costs, it’s essential to understand the activity requirements and the quality needed. For example, if the activity is to create a PowerPoint, Keynote, or Prezi presentation for the CEO to give at the annual stockholders meeting, it’s helpful to understand the medium, and whether the slides are going to present six key words, raw numerical data, or bar graphs. Or, should a graphic designer create slide pictures that tell a human-interest story? The more you really understand an activity, the closer you can reliably estimate complexity. Does that mean that you have to list every step? No, it’s more important to understand what done looks like, what kind of quality is expected, and who is going to do the work.

I recommend we keep complexity simpler, and allow only about 6 choices: 1, 3, 5, 10, 30, and 100. As project activities get more complex, our ability to estimate them drops. This is particularly true in the earlier days, which is typically when you are doing the estimating.

Agile

Talk about a confusing word. Does it mean nimble, or does it refer to the outcome of using a particular project management approach — such as Scrum, Kanban or Lean? Or does it mean people over processes, working in sprints, cross-functional and self-managing teams, or rapid delivery of value to the customer? What part of all of that? Organizations simply have to know what they want to achieve if they want to become Agile. Define the end game. Understand what ‘done’ means.

If we move towards developing a common project management language, what will the benefits be? How about less time in confusing conversations and more comparability in our project portfolios.

Join the conversation and share your thoughts. And sign up for my newsletter where I offer a book review every week..