That’s a Great Idea! Let Me Get Back to You…
We ask team members to build relationships with clients. We tell them the customer is always right. We tell them we want to deliver value to the customer. Then, when presented with information that a solution we are working on could be improved, senior management gets grumpy if troops integrate the suggestion without seeking approval from above. Why give team members grief for being responsive to customer needs?
I coached a project manager recently who is getting a clue. Good and smart person, but the project manager role is new to her. My protégé is starting to see the challenges of project management from both sides.
A client had cornered one of her developers and asked to change a previously agreed upon interface specification. The developer promised to make the change, then informed the project manager, who was NOT happy. A vendor had already developed and delivered their side of the interface, and this change was going to take time and cost money that wasn’t in her budget. Her choices now were to undermine her developer by overturning his promise or overrun her schedule and budget.
The developer was surprised. “Aren’t we trying to serve the client? If they need this, don’t we have to do it?” he asked earnestly.
We discussed how she might frame this for the client and the developer. It isn’t that we are rigidly bound to the protocols of the change management gods, it’s that change should always be a conscious decision. The element that the client had requested be added to the interface would have been a convenience, but by agreeing without discussion there was no chance to determine whether it was worth the cost and delay. There was also no opportunity to discuss when the change might be made (now or as part of some future update).
Imagine that the new data element was part of a transaction that occurred 10 times each day. Let’s assume the convenience of having that element available saved 1 minute of staff time each time the transaction occurred. Let’s further assume that your people cost you $1 per minute. Adding this element was going to save roughly $10 per day. Now let’s assume that the vendor’s charge for adding the element was $10,000 and it will delay the project 2 weeks. Let’s further assume that the 2-week delay means that go-live now conflicts with the vacation plans of the database administrator who was scheduled to support go live. The two-week delay now becomes a four-week delay. The four-week delay now conflicts with another system that was scheduled to go live…
It’s not that being responsive to customer needs and desires is a bad thing, it’s just that the decision to accept, reject, or defer a change is something that should be considered in light of the consequences of the delay.
“How should I suggest my team respond when the customer asks for a change?” the project manager asked.
I encouraged her to suggest the following response, “That seems like a good idea, let me check with the project manager to see what the cost and schedule implications are and get back to you.”
Change management is our only tool to fight scope creep. Every team member needs to understand why we want to assure that changes are cost effective. When a project is delivered late and over-budget, customers often forget (or were never aware) that it is due in part to “little” changes they requested that had a more significant impact than anyone imagined.
