PART III: Implementing Effective Analysis

In the previous two parts, we presented skills which we (effective analysts) must possess to drive the changes in the organizations, along with the principles and techniques which help us to do 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 the proven techniques cannot guarantee us to be the most effective analysts possible. The last missing piece to accelerate the effectivity is automatization.

A lot of teams store requirements in a spreadsheet, write requirements specification in a word processor, and supplement the requirements with manually inserted diagrams. It works, but such an approach is far from effective. The requirements names must be synchronized between the spreadsheet and the requirements specification, the diagrams must be updated manually every time any of them is changed, and versioning is usually done by word processor's revisions.
In fact, every documentation could be created using a word processor, spreadsheet, and a simple diagramming tool. Analogically, 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 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 the as-is documentation and to-be. We will evaluate their advantages and disadvantages, describe the reasons not to use any 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 the real tools. In the last part, we are elaborating on the third pillar of Effective Analysis, which is the strategy of how to deploy the whole Effective Analysis package in the organization.