RSMUS.com
If your client does not know what a ‘soffit’ is, that’s your problem, not theirs.
I arrived home the other day after a rather difficult day at a client site. I had just delivered a project that my team and I had really gone the extra mile to get right. In preparing for the presentation of the final product, I saw perfection in all we had accomplished.
Not more than ten minutes into my presentation, the client asks, ‘But where is this functionality?’ I replied, ‘What functionality? That functionality was never discussed.’
How did we miss that? We had done numerous meetings to complete the requirements; getting sign-offs on our notes from the client all along the way. We had several updated drafts of the statement of work based on feedback from the client before the final sign-off. We had even completed a proof of concept that they had agreed to as meeting their needs. So what did we do wrong?
When I got home that night, it all made sense to me. My client did not know the difference between siding and a soffit.
You may be asking yourself, ‘What is this guy talking about?’
Let me explain,
I returned home to see the progress my contractor was making on my new siding. I expected to see nice tan siding on the front of the house. To my surprise, the top eighteen inches was still white, while the rest of the house was the nice tan that my wife picked out. When I asked the foreman when that 18 inches would be tan he replied. ‘That is not siding, that is a soffit. If you wanted that tan, you should have asked for that before you signed the contract. To make it tan now, we would have to remove all the work we have completed so far. If you want, I can write up a change order for you to sign and we would be happy to do that work’.
What an eye opening experience! What I meant by the word siding was not my contractor’s understanding. Any siding contractor with years of experience would have known the top 18 inches of my house was not siding but a soffit. For me, having no experience with siding, siding was top to bottom.
At that point I understood the disconnect with my client. Requirements gathering for IT projects is much the same as getting a quote for siding for your house. Words have meaning to those of us who have done implementations for years, but many times, they are just meaningless words to our client. How many times have we fallen into this ditch?
How do we not fall victim to this? I have read many papers on getting requirements right, and they all seem to overlook one major concept. Is your client capable of correctly identifying their requirements using words that have a common meaning?
I, apparently, was not capable of communicating what I wanted done to my house. I wanted the house to be tan, but my contractor heard I wanted the siding tan and the soffit to remain white. I am not criticizing my contractor, he delivered exactly what I asked for. However, it would have been appropriate for him to have considered that I knew nothing about siding and asked me about the soffit?
The lesson learned here for me, and perhaps for the readers of this post, is to consider the experiences of your clients who are giving the requirements. Consider what concepts and terms are meaningful to you and how best to educate your client on those terms and concepts so that when the project is complete, their ‘siding’ and ‘soffits’ are the right color.
For more suggestions about how to get the most out of your Dynamics ERP when gathering requirements for projects, subscribe to our Microsoft Dynamics Community News publication.
Happy requirements gathering,
by Jonathan Struble for RSM
