DOORS Information Architecture Workshop. Part 2 of 4

In the previous article I looked at what information needs to be collected in the as-is phase of a DOORS Information Architecture Workshop.  In this article, I will focus on how that information is collected.


As a reminder, this series consists of :

1. What information needs to be collected for the as-is
2. How to collect the information for the as-is
3. Identifying the to-be solution
4. The plan to move from as-is to to-be

Obtaining all the information described in the previous article is not a simple task. A workshop is the best method, and ideally with two facilitators – one on ‘crowd control’ and one on documenting the conversation. Crowd control consists of asking the right questions and allowing the answers to digress so long as useful information is forthcoming, but shutting down unproductive lines of conversation.

The most fun I ever had on one of these workshops was with another very experienced facilitator, and a customer who had covered the walls of the room in brown paper so we could capture everything with ease.

Access to people is vitally important, at least one key person who understands the big picture of what you are trying to achieve, and who has the power to make decisions, is necessary for the full duration of the workshop.  Additional people can be called in to cover specialist areas and ideally these would be available at a moment’s notice.

Open questions such as ‘What data do you have?’ are all very well, but they are too open.  More targeted questions are needed to find the detail. Where do your requirements come from? Where are they stored? How do they relate to the design/test? Do you do risk management? What does the project manager need to know about the requirements?

It would be good to have a diagram at the end of this phase consisting of types of data linked with verbs. For instance, ‘System Requirements’ linked to ‘Stakeholder Requirements’ with the word ‘satisfies’.  If you know DOORS then you will see where I am going with this, it is a set of Formal Modules and Link Modules. The diagram should go wider than just requirements, and include everything that might touch the requirements. ‘Project Plan’ ‘tracks’ ‘System Requirements’.  This does not mean that we want fine grained traceability between the project plan and the requirements, and we possibly don’t need any formal traceability, but by defining the relationship we can question the need for traceability and integrations.

I find a workshop of this sort to be exhausting, but in a good way. It requires understanding an organization’s process and data in fine detail in a short timescale. Extracting the necessary information and knowing when enough detail has been discovered is an inexact science. A good workshop uncovers holes in processes and exposes politically charged decisions. The use of the term ‘Crowd Control’ hints at the possibility for chaos, and that is a real possibility. I have never had to deal with a riot, but I have decided to close an avenue of discussion that was becoming too controversial. Approaching the same topics later from a different angle can often be more productive. A slightly chaotic atmosphere can be useful to make people wander further with their thoughts.

Now we have the as-is situation.  In the next article I will look at identifying the to-be situation.