The Business Analyst (BA) adds clarity necessary for projects to pass smoothly from one approval gate to the next. Without this clarity in the form of proper goals, scoping, and ROI the project can get hung up along the way — and possibly sit on the shelf for years. I was added to a project recently that was “in the making” for over six years. There was plenty of “how” material gathered but not much on “why.” The project was missing a business case in general and the ROI (or Cost Benefit Analysis as they called) in particular.
But how do you throw a trained BA into the mix without telling everyone else [overtly] that they were not able to succeed? When a BA is introduced late in the game, the customer may be reluctant or even angry about working with him/her. The customer may feel that they are wasting time going over things that others have covered.
A construction analogy can help here, as with other stages of software development.
When a home or building is put up, the architect, buyer, and builder all work together to bring the dream to reality. It is the Building Inspector, however, who issues the Certificate of Occupancy. He/She is the person who says “people can live/work here.”
A BA coming into a project late can be introduced along similar lines. They are being asked to certify that the project will meet the goals of all parties — customer and developer. When positioned in this way — as success insurance or a quality value-add — the project can pick up speed without offending other team members or the customer.
