Shafeen Charania, director of business value at Microsoft Corp. in Redmond, Wash., has pointed out that there are two sides to IT – the geeks and the wallets. The geeks speak geek and the wallets speak wallet, and the two sometimes have a hard time understanding each other, he said.
In order to make software development projects run smoothly, the two sides need a bridge, a language they both understand. And that bridge is often a business analyst.
Scott Meredith, a principal consultant and business analyst at Toronto-based Shore Consulting Group, defines his role as the liaison between the people who have a problem – the clients – and the people who can provide a solution to the problem – the developers.
Where clients see things in terms of objectives, constraints and budgets, developers see things in terms of technical details and programming code, he said. “They need someone in between who can go in and define the problem as well as possible…and reconcile the high level business goals with the lower level technical requirements.”
According to David Nicholson, president of Nicom Ltd. in Dartmouth, N.S., the biggest challenge for the business analyst is the process of compiling documentation.
“You have to provide documentation in a way that meets two needs: you have to portray to the stakeholder that you thoroughly understand the problem and develop documentation that the programmer can also understand. It’s a real problem and the whole industry is struggling with that,” he said.
Nicholson paraphrased a comment made by Microsoft’s chief software architect, Bill Gates, who said documentation proves to be difficult in software development because design documentation is declarative in nature, while programming is procedural.
“We see the business analyst as being key to a project,” Nicholson said, adding his company refuses to do business with a client that won’t allow an extensive analysis of a project.
“I’ve learned from experience not to do that, however I see companies do it all the time,” he said.
The problem with omitting the business analyst is that costs tend to rise because of miscommunication, Nicholson said.
Meredith admitted that the software development process could be completed without a business analyst, but he doesn’t recommend it.
“Without a developer there’s no code, and without a client there’s no project, but it’s the analyst who has the best picture of the business needs, the client’s desires and how the technical solution is coming together,” he said.
Nicholson related a story about a colleague who works for a large consulting firm that needed something small completed for a large client. Rather than involve a business analyst, the project was handed directly to the programmer, who misunderstood some of the wallet speak and ended up delivering an application that wasn’t in line with the client’s objectives.
“The client’s not happy because he’s not getting the product and costs keep escalating. The management in the consulting company’s not happy because the project keeps dragging on. The developer is frustrated. It turns into a vortex,” he said.
Christopher Osicki, a programmer and analyst for information resources at the Saskatchewan Institute of Science and Technology in Saskatoon, said it is always helpful to have a go-between.
“While, in my opinion, it’s good to have some involvement, it’s best to step in once [the business analyst] has an idea of what the project’s really about,” he said. “You don’t want to have all of the programmers always talking to [the stakeholders] because nothing would ever get done.”
Apart from serving as interpreters, the business analyst has to develop and maintain good relationships with everyone involved in the project, including the end users. This is particularly important when change is involved.
“If they don’t have confidence in you, when you have to facilitate change, you face a big risk. While the client might have objectives outlined, the users might not see things in the same way, so you have to pave the way for the changes that are going to come about with the new software,” Meredith said.
Using a business analyst to work closely with end users is also beneficial because the client sponsor doesn’t always have the opportunity to wade through minute details.
“First of all, the client doesn’t have time to talk about what different screens should look like, and secondly, he or she is often isolated from the day-to-day aspects of the work. The only way to document a process in enough detail to make a requirements specification is if you can sit down with somebody who can tell you what they do and why they do it,” Meredith said.
The one danger in this, he said, is to ensure that office politics or personal biases don’t get in the way of the process.
“You have to make sure that it’s the requirements and business processes that drive the project and not somebody’s preconceived notions or biases about what they like,” he said.
