The problem with analysis

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?

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.

Business SMEs masquerading as analysts
This is a particular bugbear. Too many businesses are unaware of the variety of techniques involved in formal business analysis. As a result, they often put their staff into analysis roles without giving them the requisite tools. Too many times I have come across SMEs with the title “Lead BA” or “Senior BA” who do not have even the fundamental skills. In other words, they are trainee BAs. The result is very poor business analysis output. While it is an excellent idea to put a SME into a BA role, their experience as a SME should not entitle them to a senior BA title. Only their skill and experience in the techniques of business analysis can do that.

The myth of the analyst-programmer
Software development companies often assign programmers to analysis roles. Indeed, most job adverts for analysis positions are really adverts for programmers who also know how to use MS Word. 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 itself (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 be involved in the former. However, programmers can and should be taught to do the latter correctly.

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 several specialists (each representing a each discipline of the lifecycle) and not just a design lead. Each specialist would take on the responsibility of leadership a certain phases of the project (even standing in for the project manager if needed) and then merge back into the team.