Skip to main content

Top 5 Challenges in Requirement Management for Business Analysis & Project Management

Whether you are doing Project Management or Business Analysis, the foundation of Success or Failure of the exercise is REQUIREMENT.

Get it right, and you are on your way to achieving success in the Business Analysis or Project Management assignment. I sampled results of research studies conducted by several organizations and institutions between 2010 and 2016 on reasons for project failure, and one common factor reported by over 95% of these studies is inadequate/poor requirements definition and management. Also, after being involved in several projects and initiatives both in Project Management and Business Analysis capacities across many industries, I have realized the importance of Requirement Management.

I have outlined the top 5 challenges faced in Requirement Management. This list is as a result of personal experience, discussions with Business Analysis and Project Management practitioners and a mini-survey conducted across a community of practitioners.

Note: Requirement Management, in this context, covers the whole spectrum ranging from Elicitation, Analysis, Verification, Documentation, and Validation.

  1. Conflicting Requirements: No matter the scope and context of your project or business analysis exercise, you are certain to have more than 3 stakeholders or stakeholder groups whose requirements and needs must be managed (starting right from elicitation). And because these stakeholders or stakeholder groups have different needs and represent different interests within the business, there are always issues aligning their requirements. From my experience, this is the topmost challenge I have faced in managing requirements. I recall having this major challenge on one of the projects I managed for a top stockbroking firm in Africa. The project involved deploying a self-service, interactive and transactional trading portal for the firm’s clients where the clients can trade on stocks and shares directly from the portal without recourse to the company. One of the major requirements on the project was “User Idle Timeout (a maximum time for the user to stay logged in and not perform any activity on the portal). The business wanted to have the clients perpetually logged on (set at infinity), except if they decide to log out solely because the clients need to do some research before taking a position on a particular stock, while the IT Security Executive, another stakeholder on the project, recommended an idle timeout of 2 minutes. This conflicting requirement took us about 4 additional days of back and forth before agreeing to a 5-minute idle timeout. This happens on almost every project I have handled until I started using Facilitated Workshop technique for Requirement Elicitation. 
  2. Customers don’t know what they want: Let’s be factual, more often than not, customers don’t know exactly what they want. This is a huge challenge for the Business Analyst and Project Manager during Requirement Gathering. How do you elicit, analyse or document what is not knows? This challenge often leads to the technique called IKIWISI (I’ll know It When I See It). But a downside of IKIWISI is that it can easily lead to Scope Creep, which is an ingredient to Project Failure in itself.
  3. Unavailability of Stakeholders: Irrespective of the technique you have chosen to use in your requirement elicitation, be it interview, observation/shadowing, focus group, requirement workshop, prototyping, name it. You need to meet with Stakeholders. These are the guys with needs and expectations for the change or project you are working on, but scheduling a meeting or session with these stakeholders has always been a challenge. They are just not available, either due to their busy schedule or they are not interested in the CHANGE or project (hopefully, this is not the case). I had a key stakeholder, a representative from the user community on one project I worked on in the past who took over 2 weeks to track and get him to sit with me for 30 minutes to elicit their requirements. Unfortunately, no one could take his place. Imagine 2 weeks added to a 3 months change project.

  4. Advertisement

  5. Changing Priorities: For a lack of better word, I have used the word “Changing Priorities”, but more bluntly said, it would be “Customers keep changing their minds”. This is a VERY common, rampant, and tiring challenge I and couple of other practitioners have experienced on BA and PM engagements. I can authoritatively say I have experienced this challenge in 7 out of every 10 projects I worked on in the past. The customer comes with one set of requirements, the next hour, they are changing the requirements, irrespective of whether the Business Requirement Document has been signed-off. A typical example of this challenge was while working on an initiative for a stock broking firm to develop a self-service trading portal for their investors, same project I referenced above. During requirement elicitation, the business owner was very emphatic about online chat integration as a Must-Have requirement/feature. During implementation, the stakeholder called a meeting and decided to expunge that requirement, and replace with google map integration in the contact us page. The next review process, she was thinking and having another idea, hence a completely new requirement, different from what was elicited earlier. I find this challenge quite common when doing Requirement Management.
  6. Unsupportive Stakeholders: Well, maybe this is not as rampant on projects as the other four, but I have faced lots of challenges on requirement management when the stakeholders do not buy into the change. This could be as a result of a segregation between senior management and the user community or sheer lack of enthusiasm towards the change being implemented. A while ago, I was working on an automation initiative as part of a firm’s digital transformation program, and part of the process included understanding the current (manual) process (AS-IS), identifying bottlenecks and improvements, to be able to develop the future (TO BE) process. Unfortunately, the key stakeholders felt this automation would render them redundant and threaten their jobs. So, we faced a lot of restriction and challenges while meeting with them to elicit requirements of the current process or identify improvement opportunities.

Whilst I believe some of the highlighted challenges can be addressed by implementing the Agile method, there are still some residual challenges.

So, I would like to end by asking you to confirm if you have experienced any of those challenges identified above and provide comments on those other challenges you have encountered and possible solutions.