It was a challenging project. We were closing in on an on-time, under budget implementation. The client was extremely pleased with our progress. The funding agency couldn’t believe that we had not requested a single increase to our contract price. My own management was delighted.
Late in the project lifecycle, however, a representative of the client’s own IT department raised a large Change Request. He claimed that he had raised the issue during requirements definition, but had not seen it anywhere in the design, or the documentation, or the preliminary testing results. In his mind our team had deliberately excluded it because of its complexity. He felt that it must be included before the system was implemented. He also insisted that because we had deliberately excluded it, we must now implement it out of our fixed-price contract.
He was right about two things. Yes, he had raised the issue during requirements gathering. Yes, it was a complex requirement. But he was wrong about everything else. Our team had not excluded it; the client subject matter experts had. If he had attended the requirements sessions or participated in the deliverable review, he would have known this.
In an attempt to mollify him, my team pulled together a high-level analysis of the impact of the requested change. It was easy to show that the system implementation would be significantly delayed. We also included a hefty price tag, not agreeing that the CR should be implemented at our expense.
I presented our estimates to the client executive (we did not have a formal Change Control Board). The requestor was invited to the meeting to answer any questions the executive might have for him. It was soon obvious that the executive did not want to include this CR, and certainly not for the cost nor the delay in implementation.
But the requestor would not let it go
To this day I don’t understand why he dug in. The change did not in any way affect his area of responsibility. The client, for whom the CR was supposedly raised, did not need nor want it prior to implementation. If his end-users deemed it was necessary in the future, it could be included as a post-implementation work order.
A lengthy discussion ensued, the requestor still not wanting to let it go. Finally, I confronted him directly, “It ain’t in the book, and the book is closed!” With that I ended the meeting.
Not my proudest moment. Not my preferred way of handling the people aspects of project management. In this case, however, I was assured of support from the client executive (who was also the primary stakeholder).
Word got back to my management and I received a phone call from my VP. Fearing a reprimand, I was instead surprised by his hearty congratulations. He was going to adopt my words – “It ain’t in the book, and the book is closed!” – and distribute them to all his Project Managers.
Sometimes we just have to learn to say “no” in more creative ways.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.