We started a writing project with a project plan and a requirements document that was referred to as a blueprint for the project. Then we allowed the project goals to change and morph as more was learned about stakeholder needs and production realities. The plan was updated including budgets and schedules and all that as we went along, but not the blueprint. That was left in the dust of history.
So now, six months and 2000 meetings later, the team is going over some final details. The text is being reviewed on a projector screen. A manager confers with notes on his laptop and then points at a heading on the screen from one of the textbook chapters. He asks, “How does this map to the blueprint?”
He isn’t joking.
“Document C12-34-09A. I have it right here.” He flashes an extremely complicated excel file onto the projector screen.
“That thing is months old,” I reply.
“So? Everything has to be mapped to the blueprint.”
“That blueprint is out of date. It no longer reflects the project’s goals.”
“So update it,” says my manager.
It’s my turn to pause. He’s serious. “You want me to update a document so that you can then verify that I have complied with it?”
How does that make any sense?
It makes sense because many companies rely on the requirements document to explain the project’s goals and how you met them, what resources were used, the budget, and deadlines. This document keeps your project on track and justifies your work. Even if you finished the project without updating the requirements document, your manager probably wants to see the blueprint so that he has an understanding of exactly what went on behind the scenes.
Moral of the story: Beware requirements documents that are not kept current. Once a document such as a blueprint has been created, accept that it is there to stay and must be managed along with everything else.