In yesterday’s blog post, “Don’t Sweat the Small Stuff,” I laid much of the responsibility for misunderstandings of system requirements directly on the development team analysts. Typically these misunderstandings appear during the user acceptance testing phase of the project. As I noted yesterday, when it comes to a disagreement over whether or not a user-reported defect is actually a defect, I’ll side with the users the majority of the time.
I said the majority of the time – but not all of the time. I have witnessed on numerous occasions, during discussions of whether the result of a test was a defect, the users say something like this, “I mentioned that during the requirements sessions, and you forgot to document it.” Or this: “That may be what I said, but that’s not what I meant.”
I can understand the users’ frustration, and often they are relating what they remember to be true. From the developers’ point of view, however, if the requirement is not as stated in the signed-off requirements deliverable, how can they be held responsible for not including it in the system? As much as the development team analysts may have incompletely documented the requirements, the user review team equally incompletely reviewed the document and signed it off.
I am carefully avoiding contradicting what I wrote in yesterday’s blog post, which dealt primarily with differing interpretations of the requirements as written. For that I hold the development teams analysts responsible. However, when requirements are missed or incompletely documented, and the user review team fails to note that in their review, then the users bear equal responsibility for the incomplete definition of requirements. Given that, a reported defect that is not supported in the requirements document will not be repaired except through a Change Order.
This is where a communication skill called “using common sense” comes in handy. For example, in one system on which I worked a series of reports was defined with several levels of organizational rollup. During the review of the requirements document, the users had noted that on several reports the analyst had misinterpreted the organizational rollups. The report specifications were corrected, signed-off, and the development team programmed the reports. However, during user acceptance testing the end-users noticed that not all of the reports in the series had been corrected for the proper rollups and submitted defects. Apparently in updating the reports specifications, some of the reports in the series had been overlooked, and the development team coded exactly as specified. The development team rejected the reported defects and requested Change Orders to correct the reports that had been overlooked.
Common sense requires that the development team admit that these reports had been overlooked during requirements definition, and fix them as legitimate defects. In my mind (and common sense approach), the developers were negligent in both the documentation of the report specification and the development of the reports, particularly given that they did not even ask to whether these reports should behave like the others in the same series. I would argue differently had the users missed the incorrect organizational rollups for all of the reports in the series, and had signed off the requirements document with that error.
Using common sense is truly a valued communication skill – perhaps because it’s so uncommon.
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