Yesterday’s blog post, “Lessons from a Service Writer,” started me thinking more about the communication skills that project delivery staff need to develop when interacting with their client counterparts. It seems that nothing emphasizes this more than during the user acceptance testing of a new system.
Over the course of my career, I’ve worked on several long-term, fixed price projects. It’s always during the user acceptance testing phase when “the rubber meets the road”. As the users test the system they report defects. As the development teams review the defects, they turn many of them back as non-defects, stating that they are functioning as designed. Nothing infuriates the end-user more than having a developer tell them that an obvious defect is functioning as designed.
How do we get to this place? After all, if anyone knows their business, it’s the end-user. If the end-user reports that some functionality is not working correctly, then my bet is that the user is right. How then does the development team have the audacity to reject the defect and declare it functioning as designed? It’s easy, they go back to the requirements specifications.
You know the drill. During requirements gathering the users define their requirements, and the development team analysts document those requirements – in their words and with their understanding. When the users review the written requirements, they review them based on their own understanding. They sign off on the requirements, and all looks good on paper – that is, until user acceptance testing. I cannot tell you how many times I have witnessed the user team and the development team read the same words, and derive different understandings of the same requirements.
But here’s the frustrating part. The development team is required to be expert in requirements definition. That is why they were hired. Development team analysts are required to understand the functional requirements almost to the extent that the end-users do. So, in my mind, any misunderstanding of how those requirements are programmed into the system rests with the analysts and the developers. Yet legitimate defects are rejected because they are “functioning as designed” based on a document that the users signed off in good faith, believing that it accurately captured their stated requirements. And the animosity between the two organizations builds.
Here’s how I handled the situation when I managed projects. I instructed my development teams not to argue scope with the end-users, but rather try to understand the reported defect from the perspective of the end-user. I also reminded them that even though we had signed-off requirements, it simply was not possible that we were 100% correct, and the end-user (whose business it was that we were automating) was 100% wrong. When my teams looked at the situation this way, and understood that they themselves may have misstated the requirement, it was much easier to accept the defect as our responsibility.
An interesting phenomenon would occur. When the end-user noted that we accepted responsibility for system defects that we legitimately could have turned back, they would equally admit responsibility for situations where they may have been unclear in defining the requirements. The teams would work more cooperatively, and the end product was often delivered in a more timely and collaborative fashion.
And here’s a dirty little secret – and a little extra benefit. Often I would instruct my teams to give in on the small defects, and fix them without Change Orders, even though we legitimately could have held the client organization responsible. Then when a defect was reported that would result in significant system change, the client seldom balked when we presented a Change Order. They understood that we had given in on many disputable reported defects, and that there were times that they must do the same.
Communicate constantly. Accept responsibility. But don’t sweat the small stuff, because it’s NOT always small stuff.
www.ElitePMStrategies.com • The Human Aspects of Project Management • Copyright ©2013-2014. All rights reserved.
Permission to reprint all or part of this article in your magazine, e-zine, website, blog, or organization newsletter is hereby GRANTED, provided: 1. You give full attribution to the author; 2. The website link to www.ElitePMStrategies.com is clickable (LIVE), and 3. You leave all details intact (i.e. links, author's names etc.).
Latest posts by Merv Jersak (see all)
- The Olympics of Project Management – Control and Balance - February 12, 2014
- The Olympics of Project Management – Unstoppable Performance - February 11, 2014
- The Olympics of Project Management – Competing with the “Big Guys” - February 10, 2014