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.
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”
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 →
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 →
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.
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 →
It’s been a while since my last post but I am back…
A previous post was written in answer to a questions from a colleague wanting to understand more about what is required to become a business analyst. I talked about the tools of the trade. I was thinking about what should ‘part 2′ consist of, I was reminded of a post on the batimes website written by Cecilie Hoffman. She talks about her view on the essential competencies and skills (referencing BABok).
My list isn’t really skills or competencies but a blend of them both into a short list of ‘guiding principles’. It’s not designed to exhaustive but more of a conversation point, so please add yours to the comments below. In no order; Continue reading →
I’ve been asked by a colleague how they can up-skill from their current position to become a business analyst. This is part 1 of the answer and it relates to the “tools of my trade”. I don’t anything too fancy with any of these but all play an important part in almost all the projects I’m involved in. The first four seem like obvious statements but tools don’t always mean technology..