ImageI think back to a course I took in college simply called “Introduction to Systems”.  With great expectations I imagined a program that would take some 5 years of field experience and round out my understanding about the topic and add some contextual perspective to my exposure.  It seems that my quote that “expectations is the road to disappointment” is quite true.  What I ended up with was a more global thinking on how various systems interplay.  My post class opinion was that it was a big waste of time, energy and value.  Some 30 years later I now understand, appreciate, apply and have drawn my own perspectives on the topic.

All activities whether involving technology, business or human existence is surround and involves systems.  Some are manual, others are fully or partially automated.  They are share one common element and that is precision (tolerable level mainstream management while succumbing to non-mainstream exclusion).  How we detect, treat, control and manage the exceptions plays a significant role in future system maturing.

What Do YOU Want?

ImageThe key word is “Requirements” but in using such a simple self-defining word we introduce risk.  We have a tendency to think in singular terms and fail to consider the multitude of other contributors to the specific “system” solution that sits on our project to-do table.  This system is often the melding of technology and manual participants.  It’s present state the culmination of years of change, some to address new opportunities and external mandates and others addressing delivery issues (often thought of as errors or bugs).

Each and everyday we are need of change.   These systems we have concocted involve various stake holders and constituents.  Many think that we have a single person, often the funding source or primary users, and that is all it takes to produce system solutions.  Far be it to consider other stakeholders who may be responsible for adjoining/interconnection systems.  Far be it that we overlook that there are solution providers, such as information technology or service contract company (aka outsourcer), who is likewise needing to be taken into consideration.  The real issue behind requirements issues include a failure to,

  • Include and address other involved parties,
  • Have sufficient regular experience (when you have this you need help),
  • Use means and models to lower omission risk,
  • Employ ‘clear thinking/green field’ approach (our rush to solutions places us asking what we had only with a bit of a face lift),
  • Think in the long term but define in the near term requirements that are impervious to change not the whipping post to common conditions,
  • Understand what is needed, what is nice to have and what is simply a big wish, and
  • Understand the importance of roles in defining what you what.

I’m NOT a Big Fan

ImageCall me different but I get turned over by thinking that one size fits all.  Whether it be a horizontal solution (usually driven by functions such as accounting, finance, procurement…) or vertical discipline (pharmaceutical, manufacturing, commerce, logistics…) you can try to make that size 10 foot fit into that size 8 shoe but it will be painful and will often require modifications that will be clearly visible.  Not to mention it will be felt throughout the life of the system solution.  We all know that we seldom see systems go away.  If anything they endure the test of time, albeit often ungracefully, and there often times that it would have far better if we cut our loses and moved on.  Some while back I wrote about the durability of applications which follow a very similar life pattern to individuals.  They progress from conception to elder years with all of the stages and characteristics of humans.  Some reach old age, into senility while the organization remains committed to keeping it on life support.  When this occurs a red flag needs to be raised because we are placing business values at risk.  These will often include customer service, efficiency, accuracy, timeliness and the all important increase in service costs.  So why do we keep the albatross afloat when its terminal?  Simply… the belief that a system is perpetual.  I can’t think of many things in life that last forever, when used, without a need for replacement.  The few often were engineered with change in mind and permitted element replacement will retaining the design.  It should be pointed out that from a general system perspective that design endures time much better than implementation (aka detail design).

Let Me Revert

ImageGetting what YOU want is a personal issue.  It makes use of your education, experience, exposure to those non-mainstream occurrences, understanding of risk and constituent systems and most importantly free/clear thinking without prejudice to the ‘how’ (unless absolutely necessary).

I’m not a big fan of written, book form, requirements.  They are difficult to use, analyze, maintain and are highly inflexible.  At the same time they will be required for a vast variety of purposes (internal control, future maintenance, training, study/analysis, etc.).  I am a big fan of facilitated story boarding.  This involves a series of facilitated free thinking sessions each geared to eek out requirements.  In complex and/or broad system situations there will be a need for multiple group meetings (culminating in a combined familiarization and closure meeting) and the use of tools such as ‘focus sessions’ and preparatory reverse engineering input.  Don’t overlook open issues as a part of these solutioning sessions, Issues point to unresolved matters and areas where complexity (sometimes ‘rightness’ comes into question).

You can achieve quality requirement generation results in 10 hours.  This is hard to believe for many since it is often a journey that is much much longer, seems to never quite settle down and becomes a nightmare to maintain.  Behavior is often linked to group debate and contention, ever changing ‘rightness’ in terms of needs and value, and the general inability to digest a substantial specification (let alone measure coherency and completeness).  The use of story boards make visible requirements, needs and thoughts.  One needs to avoid subjecting them to critical evaluation until they are considered complete enough to proceed further.  At that point discussions can take place, risk and effort can be considered, merits can be examined and delivery scheduling and be undertaken.  We want to make absolutely sure that we don’t start shooting down someone else’s ideas until we have get all of our thoughts out on the table.  Furthermore the needs are based on merit and not based on whether someone has a bigger stake or not.  What might seem trivial to you may be absolutely needed by the other party… be responsible enough to consider this factor.

Conclusion

ImageObviously there are allot of other things to consider when dealing with requirements (or needs).  Trace-ability, test-ability, segmenting epics/sagas, estimating effort, engineering a total solution (whether a piece or the whole) and maintaining control over change.  Change is our enemy if we fail to manage it but at the same time change can keep our business in the game.

A solution is the end to a vision and not the glory of accomplishment.  System solutions is about achieving goals that are important and doing so in a complete solution fashion (without one sided prejudice).

Advertisements