{"id":3287,"date":"2013-08-16T08:33:21","date_gmt":"2013-08-16T15:33:21","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=3287"},"modified":"2023-01-12T16:56:44","modified_gmt":"2023-01-13T00:56:44","slug":"requirements-and-various-stakeholder-groups","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2013\/08\/16\/requirements-and-various-stakeholder-groups\/","title":{"rendered":"Requirements and Various Stakeholder Groups"},"content":{"rendered":"
You might have noticed that requirements activities on projects sometimes lead to adversarial relationships. Customers don’t always feel that business analysts have their best interests at heart. Product managers get frustrated when customers demand never-ending changes in requirements but don’t want the delivery date to slip. Testers don’t appreciate having to redo their work because no one told them about updates to the requirements. Developers bristle when the project manager holds their feet to the fire to meet schedule despite piling on new features through scope creep. It’s a wonder anyone still speaks to their colleagues at the end of the project.<\/p>\n
If you’re interested in pursuing better requirements processes, you have to respect the many cross-connections between the software development group and numerous external stakeholders. This article identifies some of those important interfaces and suggests ways to engage such stakeholders in a collaborative approach toward more successful projects in the future.<\/p>\n
Figure 1. Requirements-related interfaces between software development and other stakeholders.<\/p><\/div>\n
Figure 1 shows some of the project stakeholders that can interface with a software development group and some of the contributions they make to a project\u2019s requirements engineering activities. Explain to your contact people in each functional area the information and contributions you need from them if the product development effort is to succeed. Agree on the form and content of key communication interfaces between development and other functional areas, such as a system requirements specification or a marketing requirements document. Too often, important project documents are written from the author\u2019s point of view without full consideration of the information that the readers of those documents need.<\/p>\n
On the flip side, ask the other organizations what they need from the development group to make their jobs easier. What input about technical feasibility will help marketing plan their product concepts better? What requirements status reports will give management adequate visibility into project progress? What collaboration with system engineering will ensure that system requirements are properly partitioned among software and hardware subsystems? Strive to build collaborative relationships between development and the other stakeholders of the requirements process.<\/span><\/p>\n
When the software development group changes its requirements processes, the interfaces it presents to other project stakeholder communities also change. People don\u2019t like to be forced out of their comfort zone, so expect some resistance to your proposed requirements process changes. Understand the origin of the resistance so that you can both respect it and defuse it.<\/p>\n
Much resistance comes from fear of the unknown. To reduce the fear, communicate your process improvement rationale and intentions to your counterparts in other areas. Explain the benefits that these other groups will realize from the new process. Make sure they understand the pain that projects have experienced in the past because of shortcomings in your current processes. The prospect of eliminating pain is a great motivator for change. When seeking collaboration on process improvement, begin from this viewpoint: \u201cHere are the problems we\u2019ve all experienced. We think that these process changes will help solve those problems. Here\u2019s what we plan to do, this is the help we\u2019ll need from you, and this is how our work will help us both.\u201d<\/p>\n
Here are some forms of resistance\u2013both active and passive\u2014that you might encounter:<\/p>\n
\u2022 A change control process might be viewed as a barrier thrown up by development to make it harder to get changes made. In reality, a change control process is a structure, not a barrier. It permits well-informed people to make good business decisions. The software team is responsible for ensuring that the change process really does work. If new processes don\u2019t yield better results, people will find ways to work around them\u2014and they probably should.<\/p>\n
\u2022 Some developers view writing and reviewing requirements documents as bureaucratic time-wasters that prevent them from doing their \u201creal\u201d work of writing code. If you can explain the high cost of continually rewriting the code while the team tries to figure out what the system should do, developers and managers will better appreciate the need for good requirements.<\/p>\n
\u2022 If customer-support costs aren\u2019t linked to the development process, the development team might not be motivated to change how they work because they don\u2019t suffer the consequences of poor product quality.<\/p>\n
\u2022 If one objective of improved requirements processes is to reduce support costs by creating higher-quality products, the support manager might feel threatened. Who wants to see his empire shrink?<\/p>\n
\u2022 Busy customers sometimes claim that they don\u2019t have time to spend working on the requirements. Remind them of earlier projects that delivered unsatisfactory systems and the high cost of responding to customer input after delivery. You\u2019re going to get the customer input eventually. It\u2019s a lot cheaper and less painful (and people are in a better mood) to get it earlier rather than later.<\/p>\n
Anytime people are asked to change the way they work, the natural reaction is to ask, \u201cWhat\u2019s in it for me?\u201d However, process changes don\u2019t always result in fabulous and immediate benefits for every individual involved. A better question\u2014and one that any process improvement leader must be able to answer convincingly\u2014is, \u201cWhat\u2019s in it for\u00a0us<\/em>?\u201d Every process change should offer the prospect of clear benefits to the project team, the development organization, the company, the customer, or the universe. You can often sell these benefits in terms of correcting the known shortcomings of the current ways of working that lead to less than desirable business outcomes.<\/p>\n
![\"\"](\"https:\/\/static.jamasoftware.com\/www\/imports\/2013\/08\/a4f1.jpg\")