Organizational Factors to Consider in Project Requirements

Business needs aren’t the only things you need to look at when developing project requirements. Organizational customs and characteristics as well as the regulatory environment within an industry also come into play. Here are other elements to analyze as you work on project requirements. 

• Language and process variation across the organization. To create requirements that benefit everyone, you need to look at and address variations in processes and terminology. Smaller organizations often don’t document processes. As a result, different people may perform the same job in different ways. They also might not use the same terms for describing events and process steps. To overcome these issues, plan to interview multiple people. You also need to do this in large organizations, but for different reasons. Large organizations might have process variations based on local laws and local habits. 
• The regulatory environment. Many industries, such as banking and healthcare, have regulatory obligations, which will affect project requirements. However, there is a key point to identify with regulatory requirements: Do the regulations dictate processes that must be used to generate an outcome, or is it just the outcome that’s regulated? This distinction has a significant effect on project requirements. For example, investment bankers might need to produce a report on the changes they make to their client’s investments. How that report is produced might not be regulated, as long as the outcome is accurate and meets regulatory requirements. 
• Decision-making customs. How requirements are developed will differ within organizations that use consensus-based decision-making versus hierarchical decision-making. (For a funny example of dysfunctional hierarchical decision-making, check out this Mr. Show sketch video.) The difference is sometimes referred to as “power distance.” In other words, the organizational distance between decision makers and non-management stakeholders. Let’s say a second-level manager in a hierarchical organization approves any requirements. However, the requirements should be more reviewed by others before that approval. For example, first-level managers and the “worker-bees” (non-management personnel) that report to them need to examine and provide feedback on the requirements.

Things are different with consensus-based decision making. You need to consult more people to ensure requirements are accepted. In most cases, you need to involve teams that feed into or receive information from a process. With consensus decision-making, that audiences that review requirements are more horizontal than vertical, such as across departments or business units.

• add this link behind the text “sketch video” https://www.youtube.com/watch?v=KyocQT4Vn2g
• Degree of individual empowerment. Some organizations are very rigid about their processes. Employees must follow process to the letter, regardless of the circumstances. Other companies empower their employees to be more agile. Companies with empowered employees focus on outcomes over compliance. So, in the occasional case when a business process won’t produce the intended outcome, employees can vary standard processes. When writing requirements, understand the degree of empowerment employees have. If rigid compliance to process is in place, requirements should have restrictions around what people can execute. When embracing more agility, the ability to diverge from process standards should be part of the requirements.
• The risk tolerance of the organization. When organizations are risk-averse, people might be uncomfortable with change, so they avoid proposing big changes that could be needed to meet business objectives. In this environment, persistence is helpful. To expand possibilities, ask stakeholders for options beyond conservative requirements that they request. The project team can then figure out if those requirements can be delivered within an acceptable level of risk. The benefit of doing this is to increase the value the project can deliver to stakeholders.

Do you have tips or questions about developing better requirements? Add them to the comments section.

For more about requirements, check out Angela Wick’s Requirements Elicitation and Analysis course.

Coming Up

Watch for more Office Hours broadcasts in July!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 38,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________