The Impacts of Lack of Business Requirements Process
No matter how well something is planned, there will always be something that comes up that was not planned for.
It is just as critical that processes are in place for a project, as it is for those processes to be flexible enough to allow for things to happen and adjust in a way that is productive to the project.
In this series I highlight impact areas when a lack of process is present. The first post in this series, Lack of Project Management Process, offers a list of areas where lack of process can really turn a project into a nightmare. Don’t find yourself spinning, find yourself following the process while knowing that a process can change before the end of the project.
In this, the second post in the ‘Lack of Processes’ series I look at the Business Requirements process. The Business Requirements process defines what the project is and feeds all other processes after it. The requirements are the foundation of the project. If the foundation is not strong, than anything built on top of it is likely to crack and crumble.
The better the Business Requirements process, the better all the other processes will be before the test phase, and the better the test phase will be – hence improving the outcome of the project as a whole.
The list below highlights some of the impacts to a project if there is no Business Requirements process or the process is not being followed:
- Harder to determine if there are business process defects
- Open interpretation on what a defect is
- Ever-changing scope
- Incomplete Requirements Traceability Matrix
- Increases cost to the project
- Increases resource effort for the project
- Reduces overall quality of the project
- Business Requirements Documentation
- No approved documentation on how the business needs the system to function
- Not enough detail
- Over analysis/under analysis
- Missed functionality
- Business Needs
- Code not written to business needs
- Design not based off of business needs
- Training is based off of the system as coded
- Test scripts/test cases written against the system as coded
- Test Execution is against the system as coded and not on the system as needed
Business Requirements and how the process is followed throughout the project is critical to a successful project. When processes are not followed you can almost guarantee project failure. At some point in the project the need for the Business Requirements will become critical and at that point, a lot of rework will have to be done to ensure that all the requirements are documented, approved and included in all processes in the project.
This list was collected by consultants based on real experiences from projects they have been on. If you want to avoid these types of issues on your next project, then put together a business requirements process and follow it throughout the project. Stay tuned to the Olenick blog for more from Ken Stawarz on Processes.