Create a common language to define what you will deliver

This is rule four in my *Code of the Project Manager* series. And just five minutes to read. Enjoy!

If I were forced to rank these rules, then this rule would be top or thereabouts.  Using a common language to define your products and services, the documentation and tools that enable your delivery and your project roles and responsibilities, is key to successful project management. To do this, however, you first need to create the common language. How, you ask?

Allow me to explain…

The Glossary

The first step is the construction of the glossary, an all-powerful document rather like the bible – but with fewer pages and slightly more serious in tone.

The first section should cover products and services. This should include the labels, terms, summaries and descriptions you use to describe your products, and the constituent components that make up your service(s). I’d suggest adding the version number, the estimated time to build and links to other products, too. Finally, list the product champion/owner and subject experts for each component, product and service, along with any training materials.

Section two covers project management terms such as benefits, business need, risk, issues, assumptions, decisions, lessons, success criteria, UAT, change and so on. This should be complemented with descriptions of each project document, template and tool you use – such as what we mean by a business case, project brief, project plan, team plans, the various project logs and project reports.

Section three covers roles and responsibilities. What we mean, for example, by the project board, project sponsor, account manager, project manager, team manager, team member, lead developer, lead designer, product owner and so on. And their responsibilities so there is no unintended crossing of boundaries or inadvertent land grabbing. If you’re feeling on a roll, or just plain crazy, you could knock up an RACI document for use across the company.

NB: If you really want to supercharge your project management, you could record lessons learned, issues and risks against each product, template and role. Now that’s powerful stuff right there.

The Documentation

Step two is the construction of a library of project documentation. Master templates should be created for all standard documents, along with an explanation about its proper use and an example of what is required for each section.  Again, I’d recommend you list subject/domain experts for all templates.

The benefits

This is not an insignificant piece of work, and it will require the cooperation and involvement of pretty much every team in the company, BUT the benefits are HUGE!

• Everyone using the same labels and terms to describe a product, or its constituent components when creating plans, writing documents/logs or managing delivery. Means you are always taking about the same thing, even account managers, sales people, biz dev folk…
• Project management is at once demystified – no excuses now…
• Clear roles and responsibilities mean processes, activities, people, and so on mesh seamlessly, with no overlaps
• Consistency of approach and timings for what you build
• Pulling together proposals is far easier with pretty much everything you need predefined/documented
• A learning resource that can be used by everyone in the company – from new starters to people switching teams
• Easier to share knowledge – with named experts who can deliver training, answer questions and share wisdom

There are a few short cuts you can take. Lift existing definitions for project terms, roles and responsibilities off the web and adapt these to fit your company. Start the glossary off as a wiki and build from there.  Appoint Admins/SMEs to oversee its development – if it’s not up to date, it won’t be used. These duties could be linked to specific roles, be part of ongoing staff development, the recognition of skills and/or knowledge. Consider Gamification if that suits your company culture. Just do something.

In the end, having a consensus will make the real difference, with everyone speaking the same language. Imagine that.