One Small Change One Big Deal

“How could changing a few words in one simple sentence lead to such an uproar?” June thought, incredulous at how upset some of her members were with her. All she had done was update a sentence or two in one of the high-level requirements. It had been a last-minute change that she included just before she sent the document off for approval. Her only purpose in making the change was to improve the document. As the project manager, she did not think that she needed to run every single word she wrote by her team.

June had sent the final version of the document out last evening just before she went home. It was now barely 10 am the next day, and she had received negative feedback from more than half of her team members. It was not until Peter, her project sponsor stopped by that June began to understand that perhaps her improvements were not such a great idea.

“June, part of me wants to sign this charter. “ Peter said. “But I cannot sign it with a clear conscience because you and the team cannot deliver what you promised.”

“What do you mean?” asked June.

Peter outlined the problem for June:

“The draft that we agreed upon made this statement: The project team will answer business unit questions related to product enhancements and investigate potential issues reported to them by the business unit during the product rollout.

You changed that to say: The project team will answer all product-related questions and provide full support to the business unit during the product rollout.   Do you understand the difference?”

June replied that she thought that the updated sentence was more concise and better-expressed support for the product and the business unit. Peter agreed that the updated sentence indicated better support for the business unit. In fact, it expressed support that June’s team would not customarily provide. The reason that June’s team was freaking out was that her updates placed them entirely into the product support role. The business unit owned support of the product; the team helped them with questions and issues as the business unit became comfortable with the enhancements.

It was then that June had an epiphany. In her attempt to put her stamp on the requirements, she had changed the meaning and the intention of those requirements. No wonder her team was so upset by her updates. If Peter had signed the document, her team would have been committed to providing services that they could not and should not provide.

June thanked Peter profusely and went off to call her team together to offer her apologies.

June was fortunate that she worked with an honest and insightful sponsor. And she knew that after her team learned that Peter had not signed the document, they would calm down. And while they would keep an eye on her for future written transgressions, they would forgive her. Perhaps, most importantly, this incident really taught Jane to think carefully before imposing her own perceived improvements on project documents. Her role as project manager was not to change requirements. Her role was to help the team define and agree to those requirements and then facilitate the work to fulfill the requirements.