Business analysis in software projects
So why does software industry still have a high rate of failed software projects? In this post I want to focus on one of the major reasons for project failure that is often overlooked. Yes, you guessed it… it's lack of quality business analysis. Most of the software development horror stories that we hear about can be traced on some level to the software development team’s inability to listen. Sounds simple? Because it is very simple, yet there are many project managers and business analyst that do not listen closely enough to their customers.
In gathering requirements, ability to listen and to ask questions that allow you to transfer the domain and operational knowledge between business worlds and technology is a foundation of a quality software project. If business analysis does not yield a proper model then software development really has only two options: one is a project failure and a second one is to shift the business analysis to developers. Senior and experienced developers can rescue the project, but the costs of the project usually go significantly up.
So how does one conduct a proper business analysis? The first step is to resist the temptation to jump into implementation level detail during the requirements gathering phase. Many issues that clients are trying to resolve are actually not necessarily technology problems. They often can be resolved by proper business analysis and modeling. Technology is a tool that allows you to automate or streamline the proper business process. If your process is flawed, the software development project may suffer too.
The second step is to find a communication platform that works for transferring knowledge. Clearly, meeting with customers in person yields many benefits, but what is next? How do you document and communicate back to your customers? The answer is dependent on the client’s ability and commitment to requirements. For some generating User Interface designs, and complementing them with user stories will work, while for others UML and use cases are the answer.
The third and main step is simple. Just listen to your customer…
