The client stakeholder and I looked at each other, mouths open. We didn’t know if we should laugh or get angry. Did the IT provider’s team lead just throw his fellow lead under the bus?
And, at the same time, throw the ball into our court?
Our project was in the last few months of User Acceptance Testing (UAT). We were on schedule to complete UAT, the last major activity of our scope validation activities and to final system acceptance.
I was the business lead in the Project Management Office, advising the stakeholder and his UAT team daily on their UAT responsibilities. It had been a bumpy ride, but we could see the end.
And now this.
The IT team lead had rejected more than a few of our reported defects – defects that in our view would prevent us from implementing the system. The central financial subsystem for which he was responsible was calculating incorrect results. Puzzled, we met with him to help us understand why our defects were being rejected.
Were our test cases wrong? He said they were not (which we knew).
Were our expected results incorrect? He said they were not (which we also knew).
Then why was he rejecting our defects?
Are you sitting down for this?
He looked us directly in the eye and told us that there was nothing wrong with his calculation modules. He had tested them himself. If we were seeing incorrect results, it was because the data input modules were not storing the data correctly for his subsystem to use in its calculations. Therefore, these defects written against his subsystem were wrong and must be retracted.
My first thought was that the IT provider’s own quality control processes were woefully inadequate – certainly, their system integration testing was. My second thought was … (unprintable here).
I explained to the IT lead that from the end-user’s perspective, we didn’t care which subsystem originated the defects. We only cared that in testing the system end-to-end, the end-users had uncovered several high severity defects. We would be resubmitting the defects and were prepared to retest them when they were fixed.
He dug in and said that he would reject them again. His subsystem was performing the correct calculations.
Why is it that so many IT processes come with such rigidity? Why does process so often trump common sense? In this case, even the quality control had failed because of some internal IT process that was clearly broken.
We concluded the meeting, gathered up the rejected defects, and walked directly to the Project Manager’s office. He began to defend his lead, stating that our defects should have been directed more appropriately to the team responsible for data input, not to the financial team.
I reminded him that the end-users would not have known where the defect originated, only that it was a defect. It was his team’s responsibility to re-assign “incorrectly attributed” defects to the most appropriate team as warranted.
The client stakeholder also reminded him that there would be no acceptance signature unless these high severity defects were fixed. No acceptance, no payment.
Such are the people aspects of project delivery that trump unthinking process every time.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.