Technology – The IT departments achilles heal.

In my opinion change needed and needed fast. It’s time *IT professionals forgot about the technology (to begin with) and focussed on people and culture, over delivering the shiniest and latest technology. Technology is no longer the silver bullet to issues and problems as business’s have evolved, and thanks to the consumerisation of IT, people (outside of IT) are dramatically more IT savvy than they used to be.

Sound harsh?  Continue reading

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

IT Marketing and Communications officer – The internal salesman?

I was reading a post by Simon May (@simonster) called the new heroes of the next gen IT dept.. and I wondered who currently fulfilled the IT Marketing and communications role in your IT dept? I know the post covers three roles but I’m only focusing on the last one.

Well does it sound familiar? Do you have a dedicated role to fulfill this responsibility? I’m guessing the simple answer is no. I’m sure there are people in various teams who fulfil the parts of the role but there is no single point of responsibility. 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

Underdocumented elements of business analysis…

A LinkedIn update from Giles the other day read “Working on more reliable mechanisms for the transfer of the underdocumented elements of business analysis. Osmosis doesn’t quite cut it.” I’m not sure what exactly he meant (is underdocumented a word) but I joked  that perhaps he should use the ‘back of a fag packet’ approach. It got me thinking about requirements and the how best to share them and ultimately get them signed off.

What is a good requirement? 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