IT Projects : Are they all destined to fail?

As harsh as it sounds, it is a valid question for many IT departments. The short answer is no, not all projects fail but these days a successful delivery doesn’t always prevent failure. Failure can mean different things to different people and can come at different times, which makes it difficult to validate whether something has succeeded or not. For the purpose of this post a brief definition of failure could be along the lines of;

“the failure to deliver the intended business benefits or value through the provision of a new service or process”

Continue reading

Requirements elicitation and validation – It’s all about a good story

During any project, the process whereby the business analyst validates the requirements gathered from the project stakeholders is of utmost importance. Getting the collection signed off and frozen is key, but we all know it’s a challenge, and it’s not going to happen at the first attempt.

When I think about how to do this, I always think about the end game. The aim of validating these requirements should create the foundations of a story that ultimately leaves your audience happy. Continue reading

What do you do if you inherit a ‘trainwreck’?

So we’ve all been there.. You’ve heard the rumours, there’s a project which has become a problem.. It’s become a ‘trainwreck’. I’ve used the term ‘trainwreck’ after reading such a post written by Steven in the SLAW website and I thought i’d add some comments.

Trainwrecks happen for many different reasons, whether that be poor requirements, poor project management, limited project resource, poor support from a vendor or incredibly short timescales to deliver. The important thing to realise is that they happen more regularly the people think. Continue reading