Mar 112014
 

P1010487In the previous two articles I looked at discovering the as-is situation. This article will focus on identifying the to-be situation. If we don’t know where we are headed then we can’t expect to get there, or recognise if we do get there.  An agreed view on the to-be can sometimes be hard to achieve, and a practically realisable, agreed view on the to-be is often a challenge.


As a reminder, this series covers:

  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

IAWIn all the work that was done on extracting the as-is situation from the workshop, a lot of information was also exposed about the ideal to-be situation. At this point, somewhere close to 70% through the workshop time, we should have a good idea of what is needed, and some thoughts on how we might get there too. The next stage is to openly talk about the to-be as the main point of the discussion.

Here we decide what data should go into DOORS and what integrations will be useful, and what is to remain outside of DOORS. We think about how much needs to be migrated and how much can be archived in its current form. Reuse, version and variant management, change control, reviews, signatures all need to be addressed here. These should all have an as-is component as well, and in most cases, the to-be situation would have been at least partially covered during that stage of the workshop.

It is natural to be thinking about implementation from the start of the workshop, but it is important not to make firm decisions on implementation until the discovery phase is complete. This part of the workshop is still very firmly discovery, although some options may be offered for process change or data restructuring.  It is incredibly difficult to change a tool and a process simultaneously, but also sometimes necessary. Ideally I would prefer to make the tool support something very close to the current process, and then evolve the process later. Successful wholesale changes to process and tools are rare, and only happen with a very good change manager and an organisational culture that is open to change.

The to-be solution describes the data that will be in DOORS, the analysis and reporting requirements and the interface requirements. Other related processes will also be described in sufficient detail to cover their impact upon the DOORS data.

If the facilitators were concentrating during the as-is conversations, much of this to-be solution will be a question of stating and checking assumptions.

In the next, and final, article, I will look at the plan for moving from as-is to to-be.

 

  4 Responses to “DOORS Information Architecture Workshop. Part 3 of 4”

  1. Hi Hazel, you wrote: It is natural to be thinking about implementation from the start of the workshop, but it is important not to make firm decisions on implementation until the discovery phase is complete. This part of the workshop is still very firmly discovery, although some options may be offered for process change or data restructuring.

    I need to remember that – I have a tendency to leap to decisions before the discovery phases are complete – good reminder – thank you !!

  2. Maureen, it is normal to dive into the comfort of detail that we think we understand. The trick here is not to BE different, but to avoid becoming emotionally invested in an idea before all the facts are present. This is a way of working that plays to my strengths, but some people are naturally more driven to act on a more limited set of information. That has advantages in some situations but needs to be reigned in in this sort of a workshop. In fact, the IAW does only give a limited amount of information, and so the result is based on an imperfect set of data. The information extracted also depends upon the questions asked, and those questions are the result of assumptions and design candidates.
    So, dig in to some detail, but don’t dig too deep, and consider implementation options, but use them as a different viewpoint on the problem rather than committing to a design.

Leave a Reply to Hazel Woodcock Cancel reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)

This site uses Akismet to reduce spam. Learn how your comment data is processed.