Draft or Final

Strategy, Architecture & Problem-Solving

Draft or Final

Agreement

Some organisations have a different approach to how they handle the status of a document. The approach belies a more fundamental culture of how work is commissioned and reviewed and how staff are viewed.

Background

Report

Report

One of my clients exhibited odd behaviour regarding commissioning work and approving it.

Due to the nature of the engagement, decisions were made by me and then relayed to the client. That, almost unilateral, form of decision-making has not be the norm for my engagements. Instead, I’d have preferred to have reviewed the actions while I was working on those actions (rather than after the fact). It was all a bit backwards compared to any other client engagement, where we would address scope questions early on and progress from that more detailed, joint understanding.

Even though I was assessing business capability maturity, it felt contractual. I would have preferred a more collaborative approach, but the organisation’s approach to generating change was a contractual one. It’s an issue I’ve seen before but not as stark as with this client.

Status

Correcting

Correcting

What I’d noticed with this client, was that if a document were released (no matter what version or draft status), it would be treated as final and published. The review comments would imply that the author had made mistakes and that it should never have been released in that format. Fortunately that didn’t happen to me, but that’s probably more to do with how I released documents. My documents had the same version control I’m used to including with many clients and consultancies. Draft documents (assuming little or no sensitive content) are published early to the intended audience for review, in order to influence the outcome and content of the report. The more sensitive the content, the more restricted the initial distribution and the earlier that guidance is requested.

With this particular client in mind, that approach would raise conflicting issues. The reviewers wanted to be able to influence the outcome of the commissioned work, due to the political status within the organisation. But the reviewers wanted to meet as a group to review the version, not necessarily as a steering group, to guide the work to completion, but as a review panel.

Implication

Review Panel

Review Panel

I had to tread carefully as to what documents I would release to anyone, regardless of draft status. While I’m used to not initially sharing electronic versions of documents with some clients, it was more important with this client. It created an odd culture, where people would complete work before releasing it, which then created rework and longer delays due to having to fit in reviews and changes.

Perversely, it also created a set of behaviours where many documents never reached a true state of finalisation or approval. Instead, they continued in some draft existence until ignored or replaced. That was a common occurrence, where I’d be looking for a previous strategy document, to find that it never reached completion, but became generally accepted as defining a destination or discarded. However, there had been no formal acceptance or rejection of the content, just a tacit decision across many people.

Reverse-Engineering the Culture

Hierarchy of pieces

Hierarchy of pieces

I think that much of the commission and review behaviour occurred due to the hierarchical nature of the organisation. That culture enforced a situation where superiors reviewed the output of their underlings. Couple that with an admonishing culture, rather than a praising culture, and you end up with a situation in which documents have to be final, or the critique becomes more about the person than about the document itself.

This was more than just a client seeing a document and then acting on it, treating it as a final document, e.g. to assist with negotiation or alter their position within the organisation. This was a systematic approach to not adhering to how artefacts are created and developed through to release and acceptance.

There was a severe hierarchy in the organisation where one grade couldn’t comfortably jump a grade when communicating, instead everything had to be passed up or down the chain. While organisations can work like that, many adapt and maintain the lines of communication even with flexibility and the exigencies of operating in any modern market. This organisation did not flex and those that did flex were generally put them back into place.

All of this led to gross inefficiencies and confusion due to navigating the corporate hierarchy. I’ll reiterate, the concept isn’t rare, but the ultra-strict adherence to hierarchy is rare.

This particular client compounded the inefficiencies from the hierarchy with the inefficiencies of poor document version management (or rather the document acceptance process), resulting in intricate, exhausting dance of what to share and what not to share, who to share it with and who not to share it with. All of this encouraged and promoted a contractual culture rather than a collaborative culture.