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
