The Day We Sent Letters to Dead People

Missed Requirement Sent Letters to Dead People“We just sent letters to dead people!!!” The CIO panicked, as he anticipated the inevitable PR nightmare.

The client organization had just rolled out its new system, and this was its first major issue. As project oversight for the client organization, I immediately grabbed the client’s and IT provider’s Project Managers to prepare for an emergency code fix.

I looked at the IT provider’s PM, “How could we have missed this? How could we possibly have sent letters to dead people?”

“Don’t look at me,” he responded. “You didn’t tell us not to.”

While his response was factually correct, his attitude created immediate resentment. True, the client had not identified a specific system requirement to not send letters to dead people. But, neither had the IT provider’s analyst explored this during requirements elicitation. It was one of those situations that while specifying what the system must do, it never occurred to anyone to specify what it must not do.

The functional requirements gathering process is ultimately a people process; that is, while attention to process is necessary, focusing on the people aspects of the process is paramount. As I recommended in my previous blog post, 16 People-Focused Techniques for Better Requirements Definition,” it is incumbent on the IT analysts facilitating the requirements gathering workshops to employ people-oriented techniques in soliciting the functional requirements. In doing so, the end-user participants have the freedom to explore their requirements in-depth and will often uncover requirements such as the one in the scenario above.

Too often the IT team’s facilitator is primarily interested in documenting the requirements he/she feels are necessary to include in the system, while looking to the end-user participants primarily for validation. Too often the IT facilitator is marching to a schedule which, while important, is not more important than eliciting a complete set of well-defined functional requirements.

I have witnessed this on many occasions. One that comes to mind involved a young IT analyst who was facilitating her first requirements workshop, and a seasoned end-user who clearly knew how her business area operated. The young analyst was very bright and very personable, and was intent on making a great impression on her boss.

She had studied the client’s business area in great detail, mostly by reading policies and procedures manuals and studying desk aids. During the requirements workshop she explained her newfound information in great detail. Notice my phrasing: she explained her new information to the end-user; she did not elicit the requirements from the end-user. She could have easily leveraged her newfound knowledge to develop some well-thought out questions, and then let the end-user help define the functional requirements for the new system.

As the analyst explained the requirements that she thought were necessary, the knowledgeable end-user was not understanding. She began to ask questions. This set up an uncomfortable discussion – the analyst not wanting to give ground as she felt that she had described the requirements correctly, and the end-user not understanding but not willing to challenge either.

Fortunately, my IT experience and domain knowledge allowed me to step into the discussion. I reframed the analyst’s description of what she felt the requirements were such that the end-user immediately understood. I then worked with the end-user to correct the analyst’s misunderstanding of several of the requirements. Problem solved.

But what if I, or someone with my experience, had not been there to intercept this impasse? The end-user told me later that she was ready to give up. She was intimidated by the analyst; she thought she wasn’t able to get it; she felt inadequate.

IT staff need to hone the people aspects of their project delivery. They are so reliant on process and schedule to execute their tasks that they don’t take time to focus on the required people skills or to genuinely involve their end-user counterparts in the requirements definition process.

And so we send letters to dead people.

Merv Jersak
If you want your IT projects to come in on time and within budget; if you want your clients to be your best ambassadors and your project teams to be committed to your success; if you want to stop leaving money on the table – then Merv Jersak is the mentor and coach who will work with you to help attain the results to which you aspire. With more than 40 years’ experience as an IT Project Management and systems consultant, Merv works with IT solution providers and end-user organizations, focusing on the people aspects of project delivery to drive more profit to the bottom line and to have fewer budget overruns.

To learn more about Merv’s service offerings, or to hire him to speak to your organization, visit


52 Project Management Success Tips from Merv Jersak  •  Copyright ©2020. All rights reserved.