It seemed like a simple question
“Could you just approve the wording?”
Of course you could. You knew the terminology, understood how the Business operated and could spot the difference between something that sounded sensible and something that would leave customers wondering whether they had accidentally applied for a mortgage.
So you read the proposed wording carefully, corrected a couple of sentences, suggested a clearer heading and pointed out that one of the terms hadn't been used since approximately 2007. The Project team thanked you, and you confirmed that the wording was fine.
A useful contribution, a small job completed and everybody happy. Or so you thought.
Apparently, you approved rather more
A couple of weeks later, someone mentioned that the Business had approved the new process. You were pleased to hear it, until they mentioned that you had approved it. This was slightly less pleasing.
You remembered approving the wording on a screen. You did not remember approving the process behind it, the changes to how colleagues would work or the arrangements for handling the exceptions nobody had yet discussed. But there it was, recorded against your name: Business approval received.
You had gone into the meeting to check some words and had apparently emerged with responsibility for an entire operating model. An impressive promotion, considering nobody had mentioned it.
The problem with a small yes
Most people are reasonably cautious when they recognise that a decision is beyond their knowledge or authority. Ask someone to approve a major financial commitment, an unfamiliar technical design or a change affecting several departments, and they may quite sensibly say that they need more information.
The difficulty is that not every significant decision looks significant when it arrives. Sometimes it looks like a request to confirm a sentence, choose between two options or check that a diagram reflects how the Business currently works. These can be perfectly reasonable things to ask a Business participant to do, and Projects need that knowledge.
The problem begins when a limited confirmation is interpreted as approval of something much wider. The person giving the approval may not realise what the Project intends to do with it. Equally, the Project team may not realise that the person has understood the request more narrowly.
Both sides can leave the conversation believing everything is clear, which is a remarkably efficient way of creating a misunderstanding.
Not every misunderstanding needs a villain
It is tempting, when these situations come to light, to assume that someone has been careless. Sometimes the Project hasn't explained the scope of the approval clearly enough. Sometimes the Business participant hasn't asked what their confirmation will be used for. And sometimes neither side has fully recognised the consequences of the decision.
There are also occasions when complexity is deliberately understated to keep work moving. That can happen, but it would be unfair to treat it as the normal explanation. Often, the people involved are simply working with different assumptions.
The Project believes it has secured approval to proceed, while the Business participant believes they have confirmed that one particular detail is correct. Neither realises that the other has understood the conversation differently until something happens that makes the distinction rather important.
What exactly are you approving?
There is a useful distinction between confirming that something is correct and authorising what happens next. You might be entirely qualified to confirm that the wording on a screen is accurate. That does not necessarily mean you have assessed the complete process, considered its operational consequences or been authorised to approve it on behalf of everyone affected.
Equally, a Project may legitimately need several different approvals at different stages. The answer is not to turn every request into a formal investigation, but simply to make the boundary visible.
A few questions can help:
A useful sentence to keep handy
There is nothing wrong with being helpful. In fact, Projects depend on people who are willing to share their knowledge, review proposals and make decisions within their responsibilities. The trick is to be precise about the help you're giving.
Something as simple as “I’m happy to approve the wording. Just to be clear, I’m not approving the whole process.” may be all that’s needed.
If the Project requires wider approval, everyone now knows that another conversation is necessary. If it only needed confirmation of the wording, nothing has been delayed. Either way, the Project has gained something valuable: a clearer understanding of what it can rely on.
The Project Survivors observation
A significant approval doesn't always arrive looking like a significant decision. Sometimes the risk isn't that people knowingly approve things they don't understand, but that they don't recognise the full significance of what they're being asked to approve.
So before you say yes, make sure you understand not just the thing in front of you, but what your yes will be taken to mean. You don't have to become a Project Manager; you just need to know what you've approved.
Preferably before somebody congratulates you.
Explore further
Understand: The Dangerous Little Word “Agreed” — why an apparently straightforward agreement can become a commitment nobody intended.
Act: Ten Questions Worth Asking Before You Say Yes — clarify your responsibilities, authority and commitments in Project life.