In my view, projects don’t go wrong because of ‘requirements’. Requirements are merely a convenient hook on which to hang any issues encountered on the project – whatever they may be.

Projects go wrong because of a lack of understanding of how the requirements actually fit into the global game. This in turn is simply down to a lack of knowledge. There is no need to philosophise further. If you have pre-existing systems and infrastructure – as almost all projects nowadays will have – then this problem will increase dramatically if that pre-existing landscape isn’t understood. And frequently it isn’t.

I once attended a post implementation review for a project that had encountered overruns and a host of other issues. Much time was spent recounting tales of woe about the requirements. Yet it was pretty obvious to me that it wasn’t really the requirements at fault at all. The knowledge deficit (which was not the team’s fault, I would add) meant that any piece of work – big or small, simple or complex, would have caused them a problem. Even leaving requirements out of it entirely and having a bug to fix would have been a major challenge.  The only ‘safe’ way out would have been not doing anything at all.

By contrast, more recently I was involved in a complex set of changes to one of our key systems. The requirement from the business area was little more than ‘make it work’. Yet this was implemented relatively smoothly as it turned out, because – more by luck frankly – we had a knowledgeable team. We were able to shape what needed to be done based on our knowledge and come up with a set of actions that could be played back to the business for comment. In effect we were writing the requirements for them. They would then approve, reject or modify.

The whole situation could well have been very different and potentially disastrous with different people involved.

None of the above is actually to do with the ‘requirements’ per se in my view. Whilst some would argue that we should not even have gone ahead without something more substantial to start with, you also have to recognise that not everyone is good at articulating requirements. They are not always able to get their objective across, even if buried within it is the kernel of a good idea (which in my experience there generally is).  We in IT have to be alive to this. We should be prepared to put ourselves in the customers position and if necessary help create the requirements for them. The ‘alternative’ (if that’s what it is) is to do nothing and wait. This is futile and does untold damage to the reputation of our industry.  We should be in there proactively collaborating, assisting and doing whatever we can to move things forward swiftly. Not pushing people away and waiting.

Difficulty in creating requirements and expecting IT to help create them, doesn’t in any way mean the customer is disinterested or lacking in knowledge and commitment. In the example above they were anything but. They simply needed IT need to take a creative lead.  Once that had been established, they were more confident and more involved.

Neither does it mean there is some sinister rule violation taking place in IT or a flaw in our processes. I personally have no problem with IT getting involved like this and it is central to what IT should be doing in my opinion.  But it is possible only if you have a knowledgeable team.

How to get there is the big question. Sadly this is a much larger challenge than it perhaps should be.

 

« »