When I was the IT Manager at my previous organization, we needed to prepare for the Cybersecurity Maturity Model Certification, or CMMC, to meet the compliance requirements for our government contracts. We hired an outside consulting team to help. It came at a very high price.
The consultants did a complete review of our architecture and documentation. Then they handed us a POA&M spreadsheet, a Plan of Action and Milestones, that said we were not compliant with CMMC.
We already knew that.
The contract was written around the delivery of a POA&M. But our understanding was that it would include specific, concrete guidance, not just on what needed to change, but on how to change it. There was a disconnect between the “what” and the “how.” What we received was little more than a copy and paste of our own documentation. They delivered what the contract said, and it was a complete waste of time and resources.
I don’t think that was a one-off. I’ve seen the same pattern more than once: a polished deliverable, a signed SOW, a paid invoice, and then a document that sits in a SharePoint folder gathering digital dust while the engineers work around it with manual overrides and “temporary” fixes. It’s a paper tiger. It looks fierce in the meeting, and it has no power over the tenant it’s supposed to govern.
The mission is still the mission
In the Army, it’s commonly said that no operations order survives first contact. There’s some truth to that. In IT, first contact is when the plan meets the real environment.
But the mission is still the mission, and it still has to be completed. A commander in the field doesn’t stop at first contact, and any contractor worth their salt won’t either. They complete the mission. In IT, the mission is the full implementation of the documentation.
That means you map out your intent, what you want to accomplish. Then you test and implement the plan. Then you constantly monitor and make adjustments. That’s change management, and I wrote about how I approach it in Behavioral Psychology in IT Change Management. A document is only the first step of that process. Our consultants stopped there.
A document can’t change a tenant
The failure point isn’t the logic in the document. It’s the assumption of stability. Microsoft’s release velocity renders a design document obsolete almost the moment it’s published. When we rely on a document to define our security and identity posture, we’re architecting for a version of the cloud that no longer exists.
The real technical debt isn’t in the code. It’s in the gap between the documented intent and the actual tenant configuration. Without clear implementation guidelines and a maintenance schedule that checks things like Entra ID Conditional Access or Intune compliance baselines against the documentation, your architecture is a collection of polite suggestions. Your engineers will ignore them in favor of whatever gets the ticket closed by Friday.
So the document becomes a ghost. It has the shape of what we intended, everyone agrees it’s the source of truth, and nothing in the tenant answers to it.
Why we keep buying it anyway
A POA&M is a deliverable. It can be reviewed, invoiced, and checked off. As a Director today, I’m still caught in the same structural trap: procurement loves deliverables. You can measure “POA&M Delivered” or “HLD Completion” with a checkbox. An HLD, or high-level design, is the document that lays out the overall architecture and how the pieces fit together. You can’t easily measure “Reduced Configuration Drift” in a quarterly budget review. That creates a perverse incentive to hire consultants who produce documents instead of people who implement the design and keep it aligned with the documentation. In our case, the “how” lived in our understanding, not in the contract.
We outsource the design and inherit 100% of the operational debt. We get the document. My team gets the headache of interpreting it, fighting it, and eventually rebuilding it from scratch when reality hits the fan.
How we finally got there
We did get to compliance. We hired a second contractor. We used our existing documentation and the first team’s POA&M as reference points, but we literally threw them out and started over. Then we worked together to map the network architecture and document the business processes. We developed a plan to make all of it compliant, and then we tested and implemented that plan together.
Starting over was the point. I’ve always said that business should shape IT, and that IT should not shape the business. Throwing out the old paperwork let us shape the architecture around the business processes, in a way that was compliant. The documentation that mattered was the documentation we built together, and then actually implemented.
That’s the same mission, finished. We mapped out our intent, then we tested and implemented the plan. The first contractor told us what we already knew. The second one helped us do something about it.
What I’d ask for instead
Stop buying diagrams. If your M365 consultant can’t tell you how the design will be implemented, and on what schedule someone will check that the tenant still matches the documentation, they aren’t an architect. They’re a graphic designer. Here is what I’d change in the next engagement:
- Write the “how” into the contract. Buy outcomes, not deliverables. Instead of “Deliver a POA&M” or “Produce an HLD,” ask for “Establish and maintain [specific service] configuration standards, with implementation guidelines and a maintenance schedule.”
- Start with the business. Make the contractor map your business processes before they design anything. The architecture should be shaped to fit how the business works, not the other way around.
- Plan for first contact. Every time a design is approved, ask: “What stops this from drifting in 90 days?” If the answer isn’t automation and monitoring based on a maintenance schedule, the design is incomplete.
- Hire for ownership, not knowledge. A senior architect shouldn’t just know every M365 feature. They should know how to make it work for your business, and they should still be there after first contact.
Looking back, the difference between those two engagements wasn’t the paperwork. It was whether anyone stayed to finish the mission.
So before you sign anything, ask one question: what will be different in our environment when you’re done? If the answer is a document, you already have plenty of those.
That’s the ghost in the machine. A design that exists only on paper has the shape of our intentions and no power to change anything. The mission was never the document. The mission is a tenant that does what we intended, and keeps doing it long after first contact.
Further reading: M365 Solution Architect: What the Role Does (sbd.org.uk), which argues the architect’s job should be an ongoing discipline, not a one-time document.
