When it comes to a project, regardless of framework, often the key is not just understanding what the customer wants but understanding what they really need. This comes down to either gathering requirements in a traditional framework or filling the backlog in agile. Regardless, a clear understanding is needed to ensure that what is delivered, is not just what they wanted, but also filled the need. Often the debate starts as to who is the best person to gather the requirements. Is the person who is the subject matter expert? Well, I would challenge you to consider the possibilities (yeah, I say that a lot).
Over the years I have had the pleasure of working with some amazing business analysts, developers, engineers, and infrastructure folks. As with every project there are successes and failures. Below are two examples of what these looked like, and after the analysis is the cause of the success or failure.
Story 1: Implementation of a new software as a replacement for an existing system.
In this case, I picked up the project when it was already underway. The project was running in iterations and the person responsible for gathering the requirements was a business analyst who was the subject matter expert. When I started digging into the project and reviewing the requirements, I saw a lot of gaps and assumptions being made by the business analyst. In talking with this person she explained that “well she just knew”…really? This project had been having issues with what it was delivering so at that time I asked for a business analyst that was not familiar with the product. Guess what? This business analyst started asking all the questions and was not making assumptions because she honestly did not know the answer. With a new set of requirements, and a new business analyst in place, all future releases were successful in delivering not only what they wanted, but what they needed.
Story 2: Upgrade of system already in production.
In this case, again I picked up the project when it was already underway. There were several enhancements that were being requested and the development team was working directly with the business. Luckily, one of the developers was new to this product so he was asking all the appropriate questions and every enhancement implementation met the wants and needs of the customer.
One of the biggest challenges I continually see with subject matter experts, is that they make assumptions that others know what they are talking about; they forget to add in requirements because it is simply second nature to them. They also often do not ask all the questions that someone without that expertise would ask. If you are a subject matter expert, go back to the root of what a requirement is. A requirement is not an assumption; a requirement is not just ‘known’ by others. There are also many types of requirements that to this day I continue to see left out.
The types of requirements that everyone should consider include functional and non-functional requirements. Sometimes the business analyst is not the best person to gather the non-functional and system requirements but should have someone with them such as an engineer or architect. There are also specific questions that go along with these types of requirements when you begin to think about business continuity, backup and restore needs, service level agreements, response times, allowable outage periods, and other areas that a business analyst who is used to the functional or end-user requirements may not even consider.
A lot of people may see other areas of the project, regardless of framework, as the most important. In my mind, none of that can be successful without a true understanding of requirements. In today’s agile world, often the requirements that I see skipped over are the non-functional and system requirements. No thought seems to be given as to asking the questions to understanding storage needed or response times. If an issue comes up they throw it into the backlog and ‘fix it later’. This may only be the few organizations that I have worked with in the past, but I also hear the same story from peers working in other organizations.
So how do you fix this large gap? I would strongly suggest having someone who is not a subject matter expert involved if that is possible. If that is not possible, make sure whoever is gathering this information, that they do not make assumptions about anything. In the past the requirement for years may have been that it allowed for an outage of 4 hours, but what if that changes and that question is not asked? An organization can quickly find themselves with an outage that is now greatly impacting their business, or their clients’ business. Also, do not assume the want is the same as the need. I may ‘want’ a mansion, but my need is to just have a roof over my head. Be careful on inserting what you believe are the requirements of the customer. If you build me that mansion I am going to laugh, give it back and say I can’t afford to support that mansion.
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
Alyce Reopelle, the author of this article, encourages conversation; agree with her or disagree with her, it’s all still knowledge, and she is here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what she are doing, take a minute to share her articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
All articles on this site, this article is protected by copyright.
Author, Speaker, Project / Program / PMO Thought Leader
Over 20 years project management experience with a passion for helping organizations grow their PMO, their project managers, and their teams. My passion has taken me to the pursuit of a Doctor of Education, as I enjoy seeing the proverbial light bulb come on. I am a believer in continuous growth and improvement, and believe that an organizations culture and environment is what drives the growth of PMOs and all areas, and not the other way around.