Skip to content

How far does a tool go?

September 25, 2010

Years ago I was invited to speak at the Hasso Plattner-Institut fuer Softwaresystemtechnik in Potsdam, Germany. After the presentation during the Q&A session I was asked what my favourite collaboration tool was. My response was: whiteboards (with post-it notes as a good second).
Forward to a year ago when I joined a SI project at a local bank. This was a largish project with 70+ project members. My job was to head up a small team to determine the requirements for the interfaces between the new core system and the various systems: product systems, external parties, call center system etc.
The business processes were fairly well documented but voluminous. Hence the interfaces on a business/logical level were many (over 70). We started using Enterprise Architect by Sparx Systems to not only document the interfaces but also to link them to the business processes, the systems they connected to and the information conveyed. It was hugely useful for us, ensuring that we had a consistent and complete set of requirements.

Enterprise Architect has a useful feature where it can publish your model to a web site.  We decided to make use of this and went about making all the technical parties involved aware of the site. Yet that turned out to be limited  for two reasons:

  1. There were a number of external parties that would not have direct access to the model’s web page
  2. Many of our users were not the technical type who’d be willing to read UML diagrams
  3. The project methodology called for documents that had to be signed off and users expected to get documents, not a web site with many interlinking pointers.

We also published the word documents, one per interface. This ultimately turned out to be very useful, as it gave us a nice granularity where users could sign off individual interfaces as they became completed and we could pass them on to the vendors and internal IT for implementation on an interface by interface basis.

We had:

  • a model, used internally by my team, to ensure consistency and correctness
  • a set of small documents that was accessible and understandable to a wide audience (see my earlier blog post on the issue of readability of requirements).

I was quite happy with this setup and expected to continue this through the life-cycle of the project. But then something strange happened:

As part of the requirements we had published a spreadsheet that listed the interfaces and some metadata (version number, status). Once the interface documents stabilised and entered the stream of design & decision-making by the various parties involved (vendors, it, scope management) this spreadsheet started acquiring additional columns of information. As various constraints (time, technology) became apparent, these would be captured and comments and commitments by various parties would be documented in the spreadsheet.

The spreadsheet ultimately became the equivalent of a treaty document between all the parties involved. Each party ended up with a column where they could enter what they would commit to for each of the interfaces.  For a period of several months this was a central document for managing scope and contractual commitments.

By being involved in maintaining this spreadsheet I started to neglect the model. Mostly it was one of convenience, as the key technical information captured in the word documents was relatively static and the information that was dynamic appeared in the spreadsheet. (Interestingly the spreadsheet never grew over a certain size. Usually when certain information was settled it would migrate to other documents, the requirements, design documents or change control documents etc.)

I started several attempts at re-invigorating the model but it turned out it had entirely outlived its usefulness. The model in Enterprise Architect had been useful during the early period of discovery and creation. But once that had matured, the tools strengths became less relevant, where as the humble spreadsheet gained in importance.

There is a lesson for tools. And it’s not a simple: ‘use what is appropriate’ kind of message. It is a recognition that specialised tools such as design tools are for specialists. They help discover and design. But once that phase comes to a conclusion another phase sets in where the design is being negotiated. This is no longer the domain of specialists in the project but the generalists – project managers, the steering committee, the vendors and other suppliers of services. For these people you need a tool for generalists and that are word documents and spreadsheets.

The next time I join such a project I will plan for this. The specialist tool has its place but it must give way for the tool that provides the best collaboration.

As a corollary I think that many requirements web sites that spring up and promise collaboration still have a long way to go because they do not make this distinction of the different nature of collaboration required during different phases of the project. For them it’s still a one size fits all.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: