PART III: Implementing Effective Analysis

In the previous two parts, we presented skills that we (effective analysts) must possess to drive change in organizations, along with the principles and techniques that help us practice our craft in a more organized and predictable way. Mastering all of these is necessary for us to be perceived as partners by both stakeholders and development teams, and to be successful in delivering solutions to business needs. Nevertheless, possessing the required skills, following the recommended principles, and applying proven techniques cannot guarantee that we will be the most effective analysts possible. The last missing piece to accelerate effectiveness is automation.

A lot of teams store requirements in a spreadsheet, write requirements specifications in a word processor, and supplement the requirements with manually inserted diagrams. It works, but such an approach is far from effective. The requirement names must be synchronized between the spreadsheet and the requirements specification, the diagrams must be updated manually every time one of them is changed, and versioning is usually done using a word processor's revisions.
In fact, any documentation could be created using a word processor, a spreadsheet, and a simple diagramming tool. Analogously, it is possible to go from London to New York on a paddleboard… You may see our point.

Analysts across the industry have been experimenting with various ways of documenting organizational components and specifying their changes. Some still use standard office tools. Some have decided to put documentation in the cloud, and others store all information in a CASE tool. For many companies, the choice of tools is not important at all, and they let analysts use tools according to their preferences. It is not an issue during analysis and development, as the primary goal is delivering the solution, but they forget the secondary goal—operating and extending the solution.

In this part, we are discussing the most common approaches for creating documentation, both as-is documentation and to-be. We will evaluate their advantages and disadvantages, describe the reasons not to use some of the existing approaches, and introduce our own instead.
The new approach is first described as a theoretical concept and later supplemented by a reference implementation, which shows how the theoretical concept can be implemented using real tools. In the last section, we elaborate on the third pillar of Effective Analysis, which is the strategy of how to deploy the entire Effective Analysis package within an organization.