It’s interesting but many of the problems we have working in and around project environments and PMOs come back to words and people’s interpretations of what they mean.
Just this month, in the organisation I am working with, we were trying to work out why we were getting so few project registrations yet we knew the projects were underway. The project methodology was fairly clear. Projects kicked off via the typical one page document capturing the basics of the project such as governance, scope, benefits and so on. These documents are known under a variety of names such as Project Charter, Project Brief, Project Initiation Form, Concept Statement but they all pretty much do the same thing. They are a record of common understanding of the proposed project. In this particular organisation, they also captured the sponsor’s signature and their billing code to enable the tracking, reporting and timesheeting systems to be set up.
It seemed getting a completed and signed off version of one of these documents was like getting blood out of a stone. Yes, it is sometimes hard to gain stakeholder agreement; yes, it is even harder to get the sponsor’s charge code; and yes, there are always unknowns. The business administration team were adamant that it took weeks to complete and they couldn’t get sign off.
After much scratching of the head and discussion we found that one field on the document was labelled ‘budget’. It was intended to be for an indicative cost to give the decision makers a basis on which to say go ahead or stop.
Unfortunately, it wasn’t labelled as such. These decision makers were senior managers, the very same ones that beat up on people when they blow their budgets. However, budgets don’t get set until the end of a feasibility stage containing requirements, high level solution design, estimate/business case and so on. People were reluctant to establish a budget until they were surer of the estimate, hence wouldn’t sign until the end of feasibility. The document should start the process, not be a deliverable of it—a classic catch-22 situation.
Our solution to this was frighteningly simple; we renamed the field ‘indicative cost’ on existing documents, even in biro, and voilà, a backlog of forms came through. This example shows how a minor mistake in wording can have quite significant consequences.
Reflect on a moment on your understanding of the difference between:
- Project sponsor vs Project owner
- Requirements vs Solutions
- Cost vs Price
- Budget vs Forecast
- Cost forecasts with or without contingency
- Deliverables vs Benefits
- Business case approval vs Funding approval
- Project vs Program vs Portfolio Management Offices
Aligning words with reporting, methodology, tools and guides is so important when considering consistent portfolio or program management. This is particularly important when considering global projects, with individuals speaking English as a second language.
It is obvious to us that despite a plethora of documents, guides, flow charts and intranet sites, people can still have fundamental misunderstandings, often attributable to the incorrect use of words.