Declan Chellar

Analysis is an undervalued skill in the world of software development, largely because there seems to be a lack of capable, senior analysts in the industry, which often leads to poor analysis and thus the skill’s being undervalued. Here Declan Chellar examines some of the problems in the field of business analysis.

Consultants in swaddling clothes
How often has your company awarded a contract to a consultancy only to find it then assigns recent graduates as business analysis “consultants”? IT consultancies often do this because they do not appreciate the skill and experience required to produce good business analysis models and they use their more experienced staff to produce the software itself. After all, anybody can do analysis, right?

Inappropriate methods
Experience is important, but if the analysts only have experience in older methods, they can hinder the project rather than help. If your workflows are going to be implemented using Pegasystem’s PRPC, for example, assigning analysts who are highly experienced only in SSADM techniques is not going to help. Your analysts need to be broad-based and up-to-date and be flexible enough to adapt their methodology to the needs of the project.

Analysts who only know analysis
You might have an experienced and capable team of analysts but if they have no experience or understanding of the rest of the software development life cycle, then their tool kit has some empty space. An analyst with development and testing experience understands the later pitfalls and can look at the analysis models through more than one pair of eyes.

The myth of the analyst-programmer
Software development companies often assign programmers to analysis roles. However, many companies perpetuate the myth that programmers are analysts by default. The myth of the analyst programmer stems from earlier days when there were no analysts, so programmers drove the customer workshops. However, out of roughly sixty programmers interviewed by Declan over several years (all of whom listed “analysis” as one of their skills) only two were able to answer the question “What is the difference between analysis and design?”

When it comes to analysis, the weakness of such programmers is that they approach analysis workshops with a design mentality and thus fail to understand the customer’s real needs.

At this point I should distinguish between analysis of the business model (which produces the business architecture) and analysis of the system requirements (see the What is business analysis? page on this blog). I do not believe that programmers should execute the former, but I do believe programmers can be taught to do the latter.

One Solution
Perhaps the (requirements) analyst-programmer should be dragged out of the realms of mythology and into the real world. What is more, the label “tester” could be added. Yes, “analyst-programmer-tester” is a bit of a mouthful. In the world of BPM, such a person should be called a “BPM consultant”. Each such consultant should understand and be able to perform tasks from analysis through to testing and deployment, but be specialised in one particular area.

This is not unlike a military squad, where everyone can operate the radio, even though there is a specialised radio operator.

One of the key aspects of BPM is flexibility. That flexibility should also apply to the team providing the solutions. What happens if the team’s only deployment specialist goes down with the flu?

An analysis specialist who can write specifications that a developer and tester can read, who can pitch in with the development effort when needed, who can advise testers on writing test scenarios that fit the requirements and even help out with testing as needed and who can lead and mentor his colleagues, becomes a better analyst with each journey through the development life cycle and is a much more valuable asset to the team.

The same is true for development specialists and testing specialists who can help out at other stages of the life cycle.

So your project team should consist of a specialist in each discipline, not just a design lead – a specialist who takes on the responsibility of leadership at certain phases of the project (even standing in for the project manager if needed) and then merges back into the team.