Its all about Design and Development (and Sharing!)

Recently I was looking at a new project for one of my clients – worth noting in the context of this post that it is a relatively small company. As you would expect the project started with an outline of what was required.  Then as normally happens, at least for me and I’m sure many others, there are a cycle of iterations with clarifications, revisions and new requirements.  Within a few days we had agreed that we both felt that there was a reasonable working specification.

[Note: as I progress through this post I’m going to raise some points as I go i.e. within context!  Point 1 – the nature of the specification is dependent on many factors with one of the most important being the nature of the relationship that exists between the client and their supplier – and this needs to be clear in your mind when you start the process.]

Clearly as part of the process of pulling the specification together I was already looking at how I would produce the required product, looking at the general design approach and what options I had as well as identifying areas of risk and how I could mitigate them.  With this information it was possible for me to put together a proposal that I could discuss (and hopefully agree) with my customer.

[Point 2at the specification stage it was necessary to do some outline design and even some coding to check out a few unknowns!]

Fortunately the client was happy and the project was started.

[Point 3 – it is worth noting that  I found out that the customer used EA to capture their specification which was auto-generated from their model.  So in this process I was able to get a working version of their model and add my own workings into the model and even reverse engineer bits of code I’d used to test a few items to include with the proposal.]

So where am I going with this ..

Well it all started the other day whilst taking my morning coffee in one of my favourite cafés, I was contemplating this new project, and what fun it should be (always good to see the fun in a project), as it not only using stuff with which I was familiar but pushed me into areas where I needed to learn some new stuff. Whilst musing it came to me that at other times when working for or with large organisations, it was all so much harder getting to this point where there was a clear specification and way forward; rather than a few days it could take weeks.

Why – simple answer – “Communication and Understanding”

So what do I mean by this and this is where the answer gets a little more complicated.

  1. Different skills, different interests – In the larger organisation there are groups of people with different skills, different interests and each group/sub-group will have their own agenda (and dare I say non-aligned objectives in their organisations).
  2. Process challenges – Many factors can influence the process, for example –  i) the type of project, ii) who or what is driving the project the specification could be product marketing or engineering  and iii) who is managing the communications between customer/supplier – which can lead to a filtering of information.
  3. Different ways of working – It surprises me that with the availability of tools many continue to use basic word processors and spreadsheets.  Why? i) For many projects there is a need for the different disciplines to interact and share information and this can drive the tools choice.  ii) A lack of knowledge of tools that are available that could meet the need to share documents and in the required digestible forms iii) Not my problem – they abdicate responsibility to an analyst and magically think their information will be captured in an excellent specification.

So what could improve the situation:

  • Having a means for each person to contribute in a way that is natural to them
  • Be able to keep information in a single place AND accessible place
  • Be able to view/review other contributors information

So what are the factors that should be addressed in trying to improve the situation:

  • A lack of context – if I writing a list of requirements I will endeavour to include information that will make it meaningful to the reader. However, there may be readers with differing interests so how can I ensure that I have included the information that is relevant to their needs.  I can’t!  The assumptions I make are based on my view of the world and may not reflect the world of others.
  • A lack of relationships between information – having established that the context may not be complete or satisfactory how can I get a sense of other related stuff that may be able to provide me as a reader with additional clues.  Yes, I could cross-reference materials but that could also be included out of context.
  • No single place for the information – If people need to work together and share information it just makes sense to being able to store the information in a form and format that is accessible to all, with each part understood by the respective parties i.e. the content and its format can be delivered as needed whilst ensuring the integrity of the whole
  • A means to capture and communicate feedback – having established that the form in which I might receive the information is less than ideal how can I provide feedback, potentially in parallel with many others, in a form that is digestible and meaningful the the author/reviewers.
  • Checking that it’s possible– As part of the development of the specification it may be necessary to verify if something is possible, there is little point in putting a specification together that is not feasible, so often worth looking at the specification cycle and the possible inclusion of some validate projects before spending too much!

If I now put my EA hat on I can suggest a tool that can do this stuff, allbeit with some challanges for some classes of user, but work arounds are possible.  For me it has the ability to capture the information on objects and their relationships (much of what we need to produce a specification and more) – providing both visual and textual content, even if some of the user haven’t got a clue what UML is!  It supports team environments (I’ve run global teams without too any issues) and probably most of all information is in a single repository.

I’m also a fan of using Wiki type systems and have used simple systems such as PmWiki as a tool to capture information with links and most importantly they provide a shared repository.  Of course, they don’t provide the range of facilities provided by EA but at least they are an improvement on some of the other approaches!

So the main point I’m leading to is why don’t more people tools that have been made for the task.  Yes, many agree to look at new ways of doing stuff but soon revert to the tools and techniques that they have used for years – and more often than not tools that have not been designed for the job in hand.  Why? Perhaps because nobody is mandating their use – why would they?

Some have and I hope that if I have influenced it there has been a positive outcome, whether measured in increased efficiency, the shear fact that it made the task possible or just makes life easier for the individuals involved.

One of the big challenges I’ve faced in organisations is the way people work, theirs and the organisations resistance to change and the general lack of investment in training on tools that could make significant improvements to the way some of the work is executed.

With my project managers hat on one of our key tasks is to get clarity on what we are trying to achieve.  In doing this we seek to ensure that ALL relevant parties are involved at the optimal time and that their inputs are clearly understood.  The better the information we have the more we can understand the project and hence better manage and mitigate risks to benefit the project.

So where is the incentive (and investment) for deploying tools?  It does happen but there are many more who could benefit.  Needless to say this is not just in the area of producing specifications or similar.

Well, I don’t have the answers but can just reflect on some of the points.  If we go back to why working for the smaller company is often so much easier:

  • It is easier to have a close working relationship with the people that matter
  • The recognise that tools can make their tasks more efficient and increase productivity
  • The management can see the benefit
  • They seek the competitive edge that tools new ways can provide
  • Sharing of information is less of a challenge
  • There is a knowledge base that can be used in the future – if needed.

Then for the larger organisation why don’t these things just happen – possibly it’s just not on the radar of the right people!

Other learnings –  many I’m sure which I’ll reflect on these in the future.

Real point of the post is that we need to review how to produce (and maintain) good specifications… Are we doing it the right way for the project? At least try and learn from potential opportunities.