Another solution design pattern looking for a base

Its a shame this programme doesn’t have access to a Content Management System, because there are so many aspects of the planning and solution design that are just crying out to be (single source) stored in a structured and related content-base, ready to be pulled out using different views for the various levels of stakeholder.

There are simple elements (such as the list of 8 projects comprising the 47 technical components that will deliver the required scope), where it might make sense to place them into a couple of related tables. Ok, its not so straightforward to create related lists in SharePoint 2003, our current collaboration platform, but at least it’s basic RDBMS style stuff that could be done there give time. However it starts to get far more difficult if you want to try and get the mix of document fragments like multiple paragraphs and bulleted lists to fit into what you know is a useful and logical structure. It will probably become clearer if I describe the type of pattern that I’d like to represent in a content-base.

Project

  • Explain the purpose of this project with a multi-paragraph Description.
  • Give two textual lists of top-level Scope items – those In and those Out
  • Textual list of any Assumptions worthy of mention at this level

All of these are, however, merely an edited summary of what comes in the individual Components delivered as a part of each Project, which leads us on to:

  • Item list of Components this Project comprises

Finally there are a couple of fields that are important considerations for the business case, but are too difficult to break down at a lower level than Project, because they relate to the current state (before we deliver):

  • Paragraph list of Key Differences, outlining what will change most dramatically if we compare before and after
  • Textual list of Benefits that the Project will bring to the service consumers, or to the internal teams that provide the service

Component

As I mentioned, the Project level content fields are just summaries of the Component level fields, so you won’t be surprised to see them repeated:

  • Explain the purpose of the component with a multi-paragraph Description.
  • Give two textual lists of Scope items – those In and those Out
  • Textual list of any Assumptions that need to be aired and perhaps challenged

So far so good? Yes, OK, its a shame that some poor fool has to copy and paste a bit of this between documents, and reconcile differences later, but that’s kind of what happens on change programmes, isn’t it? Well unfortunately yes, but you see there’s more. Because we’re thinking about the way Scope splits and meshes between various Components, and because we want to save this to help with later planning (resource schedules and deliverable deadlines) we also add the following content:

  • Two item lists of Component Dependencies, depending upon and dependant of

I will admit that these are the two senses of the same relationship, but don’t forget this is still a Word document, so we have to do them both manually for now. And because we are locking this valuable information away in the bowels of a word-processed document, then it will merely lead to more copy-paste-reconcile later.

But this is only the start – once the design starts to flow down like a waterfall you start to find all manner of information wants to maintain relationships. These Assumptions may actually have had some influence on what was In or Out of Scope, so that would be a relationship worth tracing. And beyond the realms of this document, into the detailed design, it makes sense to relate the constraints and choices back up to these Assumptions and Scope lists.

Those become valuable notes later when some scope creeps, or any worms turn, later – project change requests are usually more inevitable than exceptional. Yet relying on someone to copy and paste all of this down the design levels is asking for facts to be overlooked. And we all know what are the chances of having both top-level documentation and detailed designs updated properly and in tandem post- change acceptance – a big fat zero.

This is why I say, it seems so lemming-like to load this information into a flat document when it should be drawn out properly across a structured, related content-base, so it flows automatically and efficiently to everyone who needs to know it. Oh well, haven’t got time to sort this out now – our masters have set very tight deadlines for us to reach that jumping cliff. Geronimooooooo!

Advertisements

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: