I’m standing on the train station waiting for the 22:16 train but now it is 20:20??? The screen still says the train is due 22:16 – weird. Just arrived on a late flight and now the train is late as well. Oh – now the speaker lady now tells me the train is 10 minutes late!!!

While waiting at least another 10-15 minutes I can’t help to analyse the situation – it might be sad but at least it makes the time fly.

I stand there and ask myself:

  • Why didn’t they tell me before the train was due – time is now 20:20 of cause it is delayed then!
  • The nearest station is 20 minutes away – maybe it was late already then?
  • The information screens never told me they train was late
  • Strange using the speaker system when they got all these screens

Without knowing anything about the company and their information systems I can guess some of the following problems are present:

  • The system does not deliver to client satisfaction – me it is!
  • Information was not timely – definitely not
  • The information source for the screens is apparently wrong
  • Surely somebody somewhere must know the train is late – at least the train driver
  • Do they not track trains with GPS or similar?
  • The information system is not being used for ad-hoc messages – at least not this time
  • Maybe the speaker lady does not know how to announce on the information system?

The list could go on and on – but the core problem is apparent:

  • I’m not timely and correctly informed!!!

So have this system actually missed its purpose? Maybe not seen from the people who made it – but how often haven’t we come across a system that misses the purpose only realised after going live? Just look at numerous websites that is unusable or extremely awkward to use or software projects failing due to usability problems for the end users. Also financial systems that deliver data too late or invalid data prior to month end close.

How can we ensure the correct requirements are met for the right people?

Look at your own development projects and check for these typical warning signs:

  • Wrong definition of who is the client or the end user.
    This is key to gathering the correct requirements. Who is actually the user? Who’s input is the key to make this system a success? Often the client is confused with the customer who is paying for the system but who’s not necessary will be the end user. Keeping the customer happy is important but that may not necessary produce a good system.
  • Lack of proper client/end-user involvement in the requirements phase.
    It often already fails in the tendering phase where the initial requirements are over complicated or misleading. The software supplier then tenders for an overly complicated and overly expensive system which eventually will fail after the budget has been blown. Did I mention any government projects here?
  • Lack of client/end-user feedback in iterative development or pilot schemes.
    Both phased and RAD development cycles often focus on feedback from super users which may over complicate a system without reason or may request functionality which is rarely used. Many systems succeed as simple applications for later to add complexity.
  • Requirements are not precise and concise.
    Do you understand all the requirements when you read them? Are they clearly stated? Are all the statements short – ideally a single paragraph? It seems obvious but quite often subject matter experts have a hard time to explain what they do in a simple way. Keep it to simple statements of truth. State what the system should do rather than how it should do it. Avoid stating what it should not do.
  • Lack of ownership.
    Each requirement must have an owner or/and a sponsor. This enables the requirements to be validated and in case of changes a way to manage this involving impacted parties. This also ensures that requirements are linked to budgets which is useful when it comes to cutting the scope.
  • Unclear documentation.
    Many projects fail on bad documentation. This includes documenting the requirements in the early stage of the project. Clear structure and extensive cross references are important. Requirements must be tagged with types likes legal (or external), functional and non-functional (or technical). Lack of version control, change management and traceability also adds to the documentation problems when new revisions are made.

Requirements are a necessary evil but it has to be done by professionals who ensure to involve the right people. You may think the above is obvious but in my 25 years of IT experience I have seen it going bad too many times.

The English reader might think this bad rail information system is all due to the privatisation and must be due to communication problems between providers – however this incident happened on a Danish train station and this part of the Danish railways are still in public ownership!

This entry was written by Kent Willumsen , posted on Monday October 13 2008at 10:10 am , filed under Change Management, Requirements Analysis . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

Comments are closed.