On projects that replace existing systems, project sponsors have often insisted that we didn’t need any business analysis because the existing system was “fully documented” in the form of the old system. I wrote about one problem with that mindset, which is that the new system will have all the issues that the old system had.

Another problem is that it takes a lot of time to figure out how the existing system work. The development team will end up taking time to analyze the existing system regardless of whether analysis time is in the budget or not. Contrary to what project sponsors often believe, users of the system don’t know all the details of how a system works, and code is not “self-documenting”.

Multiple Users

Most complex systems have a variety of users. A relatively simple sales system has different users who place orders, manage orders, ship orders, manage the financials of the orders, report on orders, manage inventory, and handle returns. It’s time consuming for an analyst to research, understand, and record how all the parts of the system work from the users’ points of view.

User Knowledge is the Tip of the Iceberg

Even after talking to all the users, an analyst won’t know the full functionality of the system. In my experience, it’s rare to find users who know the details of every calculation, decision, workflow, and automated interface the system has behind the scenes. In the few cases where I’ve found that a system was well documented, I’ve been told that the documentation was outdated, so I couldn’t trust it.

Why not Just Look at the Code?

I’ve had project sponsors ask why the developers can’t just look at the code and rebuild the same system in a new technology. They assume that the rebuild is almost a copy and paste of the existing code. Although code examination is one of the techniques for understanding an existing system, developers are not able to quickly reverse engineer functionality from code in a complex system, even if the code is well organized. Any developer who’s made even a small change to a complex, unfamiliar codebase will tell you that understanding the code is time consuming.

Interviewing users, reviewing the exitisting user interface, and reviewing the existing code base are all important ways to understand the existing sytem. However, these actions clearly take time, and need to be budgeted for.

Feedback

What challenges have you had getting budget approved for business analysis? What have you done to address those challenges? I’d love to hear your tales from the trek.