Chapter 21
Ten Sets of AKAs
In This Chapter
About naming conventions in project management
AKA – ‘also known as’
Ten lots of synonyms
Standards in projects can be a bit of a problem. If you’ve learned one, you’re reading a book based on another but your new company uses a third one, then don’t be too surprised if your head starts to spin.
This Part of Tens chapter is to help you pin down what’s what and to find a way through the maze of terminology. In each section the term used in this book is listed first and after it the AKAs – ‘also known as’.
What’s in a name? That which we call a rose
By any other name would smell as sweet.
Juliet, in Romeo and Juliet by William Shakespeare
Generally speaking the underlying concepts for parts of the project and for documents are the same, and it’s just the names that you find are different. One or two exceptions do occur though, where you need to be more careful. You’ll find a comment or two in this chapter where that is the case.
Kick Off
Kick Off: Project Start Up.
Outline Charter: Project Brief.
Planning Stage
Planning Stage: Initiation Stage.
Project Charter and Project Management Plan (PMP): Project Definition Document (PDD), Project Definition Report (PDR), Project Initiation Document, Project Initiation Documentation (PID).
The International Standard ISO 12500:2012 and approaches that are aligned with it, such as the Project Management Institute (PMI) and the PRIME project method, separate out the strategic view of the project which is set down in the Project Charter from the tactical view which is in the PMP. Others combine them into a single document such as a Project Initiation Document (PID). In one sense it doesn’t make any difference because the overall content is pretty much the same. However, it’s arguably much neater to have the strategic separated from the tactical. I’m biased, but I think that the international standard has it right here. The two elements are used in different ways, and I think that the approaches that combine them are not as effective.
Plans
Activity Network: Precedence Network, PERT Chart.
Float: Slack, safety.
Product Definition: Product Description, WBS Dictionary (see the note below for more on the WBS (Work Breakdown Structure) Dictionary.
Resource levelling: Resource smoothing.
Work Breakdown Structure (WBS): Product Breakdown Structure.
Work Flow Diagram: Assembly Diagram, Product Flow Diagram, Milestone Diagram.
At the start of the chapter I noted that some of the AKAs are not exact equivalents, and that is particularly true of some of the terms in this section.
The term ‘activity network’ is a generic one. The two AKAs are actually different types of network. One has the activities ‘on the node’. The activities are drawn as rectangles with arrows between them showing the order in which those activities will be done. That’s the Precedence Network. An older approach is the PERT Chart (Project Evaluation Review Technique) which has the activities on the line and the nodes as marker points between them. The nodes are drawn as circles with figures inside showing the timings. Modern approaches use the Precedence Network because it avoids diagramming problems with the PERT. However the terms are included in this chapter because you may hear the activity network referred to as a PERT Chart, even when actually it’s a Precedence Network.
The next confusion is with the WBS itself. Some, including some project planning software, use a WBS as a hierarchical decomposition of activities. So you take the whole project as one giant activity, break it down to sub-activities, then sub-sub-activities and so on. When you have reached a reasonable level of detail, you transfer those activities or tasks onto your Gantt.
Other forms of Work Breakdown Structure are a decomposition of products, not activities. It’s not a country-by-country divide either. In the USA where many use an activity decomposition, the space agency NASA uses a product decomposition with activities only at the lowest level. Still confused? Try reading the UK edition of Project Management for Dummies for an explanation of product planning and the use of the WBS.
The WBS Dictionary is a commentary on elements in the Work Breakdown Structure (WBS). Although the equivalent is Product Definitions, Product Definitions are generally more thorough and useful, especially where they form a part of the overall product based planning approach.
Organisation
Project Steering Group: Project Steering Committee, Project Committee, Project Board.
A lot of organisations use the term ‘Project Board’ for the group of senior managers charged with oversight of the project. Often the organisation has picked up the term because it is the one used by one of the leading project methods. However, watch out for problems if your organisation uses the term ‘Project Board’. The problem lies with the word ‘board’ because it brings with it the idea of a management board. Unsuitable people (whose careers, let’s face it, will never reach the heady heights of the management board) may want to be a board member because it sounds prestigious. That leads to Project Boards filling up with unnecessary people who want, or ‘need’, to be there.
It’s important to keep Steering Groups ‘lean and mean’ and big ones are trouble. Most big Steering Groups never actually meet because if you have 10 or 15 people involved there are bound to be one or two missing at any one meeting, and often more than that.
Another problem with the prestige view is that if ‘important’ people think that they must be on the Steering Group because of their grade in the organisation, they expect that to be their only input. In turn that means that these group members start to ‘do’ the project in the group meetings, taking it completely off track and making for very long meetings. The function of the Steering Group or Project Board revolves around the management of the project, not in doing it. The doing part is in the teamwork. You can have very senior and important people on teams and that’s where they should be, getting on with their ‘doing’ there, not cluttering up the PSG and diverting it from its true purpose.
To help you keep the PSG ‘lean and mean’, here are three things to help. First, keep the membership focused on roles. If someone says ‘Oh I don’t want to be one of the roles but I should be on the PSG.’ then they don’t belong there – keep them out. The PSG is a working group, not some theatre with an audience. Second, listen out for managers saying ‘I need to be on the PSG because I must have an input to the project.’ No, that’s an argument for being on a team, as noted in the previous paragraph. People can have an input by being involved or by being consulted without them being on the PSG. Third, ‘I must be on the PSG because I need to know what’s going on.’ Knowing what’s going on may be an entirely valid need, but it’s a communications need, not part of the management of the project. Use the Communications Plan to think through and then decide on suitable communication products such as news sheets and briefings.
Project Roles
Project Sponsor: Project Director, Project Executive, Executive, Senior Responsible Owner (SRO).
Project User: Senior User.
Project Supplier: Senior Supplier, Project Provider.
Team Leader: Team Manager.
The chairperson of the Project Steering Group should always be the Sponsor – or the equivalent title. Most organisations use the term Sponsor, but be careful not to confuse this with the user interest, covered by the Project User.
Of the three views referred to in the ISO standards, amongst others, are the business view, the user view and the supplier view. The Sponsor has the business view and must ensure that the project is worthwhile from a business perspective. A user may want something, but it may not be justified in terms of benefits. If the Sponsor is covering the user viewpoint as well, he may get diverted onto the ‘nice to have’ rather than what is justified.
To help the people involved in the project understand their roles and responsibilities, you can find checklists in Chapter 6.
Support services
Project Audit: Project Assurance.
Project Office: Project Management Office (PMO), Project Support Office (PSO).
‘Project Assurance’ is a poor term because although it is accurate in one sense, few people can readily understand what it means. Because just about everyone is familiar with the idea of a financial audit, the term ‘Project Audit’ immediately gives a clear picture of the service involved.
Communication breakdown is a common cause of project failure. It therefore makes sense to use terms that people can readily and accurately interpret. To help avoid comms problems, think critically about naming conventions in the context of your organisation’s projects, and especially your current project. Is any term potentially misleading or confusing? If so, you might want to change it.
Even the leading UK project method which promotes the term ‘Project Assurance’ confuses the work of the role by involving the auditors in project decision-making, as pointed out in Chapter 19 which is written primarily for Project Auditors.
To really hammer this point home, financial auditors don’t help write the accounts and then audit those same accounts; that would be pointless, since their independence would be totally compromised. If your organisation uses the term ‘Project Assurance’ make sure that those involved are crystal clear on their true role and maintain an independent view; and that’s no matter what your chosen project method tells you.
Stages
Stages: Phases
Stage Completion Report: Stage Report, End Stage Report.
Stage Gate: End Stage Assessment (ESA).
Control
Logs: Registers.
Project Memo: Project Issue, Issue.
Quality Control: QA (Quality Assurance, but see the warning below).
Version control: Versioning, Configuration Management.
Quality control is testing. Watch out for some environments, notably IT, where people refer to something being ‘in QA’ (quality assurance) when it is being tested. Although this term is included here as an AKA, it is nevertheless a wrong use of the words. Assurance in the context of a project effectively means ‘audit’ – checking that the tests and quality procedures have been done, not actually carrying them out.
Some approaches use the term ‘Register’ instead of ‘Log’ and refer, for example, to the Risk Register. The content and use of the log is the same though. One approach in particular uses the term ‘Log’ for informal documents that are for the Project Manager’s use only, and ‘Register’ for the more formal ones that are checked by others. However, using both terms introduces, in my view, unnecessary complexity because everyone involved in the management of the project knows full well what the documents are and how they are used.
The term ‘Configuration Management’ makes more sense in engineering and IT circles where the ‘configuration’ of equipment is important. However, the use of the term in the context of project management is a source of much confusion to people who are not engineers or IT specialists. If you ask business managers what Configuration Management is, most will be unable to give a meaningful reply. Ask them what version control is and they won’t have a problem.
Configuration Management is more sophisticated than mere version control, but for many projects the difference is not significant. If you’re in an environment that needs the greater degree of sophistication, then you’re probably already well aware of that because of your knowledge of the project, organisational standards and procedures.
Closure
Project Closure Report: End Project Report.
Evaluation
Evaluation: Post Project Review (PPR), Post Mortem.
The term post-mortem (autopsy if you’re American) is here for completeness, but if your organisation uses the term in this project context then try to get it changed. It is entirely negative, whereas an evaluation should look at the positive as well as the negative.