99 Obstacles to Getting Good Requirements

problem solving (Demo)

By George Bridges

October 1, 2019

Current Challenge to Getting Good Requirements

Over the years in one of my courses on Writing and Managing Requirements, I have an exercise where the participants prepare a list of obstacles for getting good requirements.  Here are some of the obstacles that you may have seen or experienced, just to name a few:

1 Documentation (requirements) not maintained throughout the life cycle
2 The people that we talk to may not be the right people 
3 Aggressive project schedule limits time to get requirement
4 Anxiety on the part of management to get into coding
5 Assumptions in general

There have been recorded so many obstacles from these informal surveys that I wanted to publish this list for others to review, reflect, discuss and contemplate mitigation strategies to overcome these challenges.   We have not formally tried to rank or analyze these obstacles, but this list alone will shed some valuable insight on requirement generation obstacles.   After you recognize what obstacles you face, plan a course of action to deal with them.

Develop a mitigation strategy to avoid these obstacles

Having a list of the requirements is a good start in improving your ability to get good requirements.  However, we can make additional significant improvement by coming up with a mitigating strategy for each of 99 obstacles.

Here is the List of 99 Obstacles to Getting Good Requirements

1 Documentation (requirements) not maintained throughout the life cycle
2 The people that we talk to may not be the right people 
3 Aggressive project schedule limits time to get requirement
4 Anxiety on the part of management to get into coding
5 Assumptions in general
6 BA making sure that the right questions are being asked
7 BA’s are limited by time in doing the requirements research 
8 Business person has not researched the issues
9 Can’t get a vision from the users
10 Can’t get to the right users/people
11 12 13 Can’t get the right SME’s Can’t get management involved Changing requirements – more than one customer
14 Changing scope
15 Communication barriers  – English, technical and cultural 
16 Complex organization structure where you can’t get to someone at times 
17 Customer thinks we already know what’s going on
18 Customer won’t take the time
19 Developers don’t read requirements before they start developing
20 Differing skill sets and methods
21 Documentation is not up to date
22 Don’t know who the problem owner is
23 Don’t understand the problem first
24 External influences
25 Fire drills – limit time to develop good requirements 
26 Internal politics
          27 Incorrectly defining the problem, which limits getting the right solution 
28 Information can’t escape from information silos
29 Invalid assumptions
30 Lack of a defined policies and procedures
31 Lack of commitment from other divisions
32 Lack of domain expertise to understand what the business is looking for 
33 Lack of proper tools to build the requirements – framework 
34 lack of standard checklists
35 Lack of thorough analysis
36 Lack of training on the requirements to be built 
37 Lack of understanding of the client organization
38 Management doesn’t give buy-in
39 Management won’t give us a decision or answer the questions
40 Miscommunication
41 Poor communication
42 Lack of negotiation skills
          43 No date set for locking down requirements or not abiding to the set date
44 No idea of big picture
45 Not enough time
46 No standards
47 Not enough dedicated time to do requirements
48 Not finding the right people, like the SME’s
49 Not having complete functional knowledge of the system before we have to put the requirements together
50 Inability to communicate
51 Not knowing the areas involved
52 Not starting with the problem
53 Users communicate symptoms
54 Talking too much and failing to listen
          55 Not talking at a level the user community understands
56 Not the right users
57 Organization goals are not clear
58 Personnel on the business side change which, changes the requirements and priorities
59 Political intrigue
60 Pressure to produce something tangible
61 Pressure to start coding before requirements have been completed
62 Product managers don’t understand the current process
63 Requirements change after approval
64 Sales people promise what cannot deliver resulting in an inability to deliver requirements that were promised 
65 Scope creep
66 Style issues
67 Terms are not defined up front
68 The end users don’t always know what they want  
69 The people you need to talk to are never available
70 The project scope is so big that it is hard to come up with a full solution 
71 The right people aren’t available when you need them
72 The stakeholders who do the verifying don’t know what the user’s need
73 They bundle too many requirements into one requirement 
74 Those that define the requirements don’t always know what they want
75 Too big a hurry to code (get to the “how”)
76 Too focused on how and not enough on what
77 Too many changes in the environment
78 Too many interruptions 
79 Too many meetings  
80 Too much interference from business
81 Too much time in status and project management time related task  
82 Unrealistic expectations
83 User expects us to do it all
84 User lack of knowledge
85 Users are non-technical and don’t understand
86 Users disagree on requirements
87 Users don’t have all the information up front
88 Users don’t know how the system operates
89 Users don’t know what they are doing
90 Users don’t know what they want
91 Not defining terms upfront
92 Users keep changing their minds
93 Users tell you things that aren’t true
94 Users think requirements are a waste of time
          95 What was developed is inadequate to meet needs
96 Wrong people writing the business requirements 
97 Users want everything, just in case (and they can’t be convinced they don’t need it)
98 Users intimidated by technology
99 Users intimidated by lack of technology

Are we missing any obstacles?  If so, please post your comments?  If you can communicate some of these obstacles using pictures and not words, please send them for consideration for posting in a future blog.  I would like to get your comments.  You can also, email me at george@bridgesconsultinc.com

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: