I’m pleased to say that my most recent blog article has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.
Is IT just the tip of the iceberg?
Excerpt:
As anyone who has ever read the Standish Group’s “Chaos” report knows, so-called IT projects have a fairly poor success rate. Nick Malik recently built upon this idea in his article “Everything you’ve read about IT Project Failure is wrong.”
Nick argues that, while traditional thinking focuses on looking within the project environment for the root-cause of failure, the most serious root-causes—such as a lack of accountability for success, slow decision making, etc.—are completely outside the project’s control.
I agree with the points raised in the article, and I think it’s possible to extend this analogy even further. I’d argue that there is no such thing as an IT project—there are only business projects that implement, impact, change, or interface with IT. This sounds like a subtle distinction, but it’s deceptively important.
As soon as an organization frames a project as being specifically IT, the project focus tends to shift to the technology. This is rather like the metaphorical “tail wagging the dog”…
Read the rest of the article by clicking the link below:
http://www.techwell.com/2013/02/theres-no-such-thing-it-project
Hi,
this makes sense. But the problem I have is that where I work, IT are given a budget for, and authorized to run, projects. They set them up then call in the BA they (IT) employ. Surpise, surpise, the BA finds the previous “analysis of the business” has (often) not established the real business problem.
Any tips on how not to be the bringer of bad news in such situations?
Hi Mal,
In the situation that you describe, it would be very difficult not to be the bringer of bad news. Being rather blunt, it would seem that there are two choices:
a) Bring the bad news now, highlight what will happen if the real business requirements aren’t met, and let the sponsor make an informed decision
or
b) Keep quiet, deliver a solution that doesn’t meet the business need — at which point the business will probably throw stones very firmly back at the IT team, many of which may land on your door as the BA.
In my view choice (a) is only deferring the bad news. Not only this, many studies have shown that changes to requirements in most plan-driven methodologies cost far less early on in the project lifecycle. By raising issues early, you are likely to save money. Not only this, but you’ll build bridges with the business and enhance the reputation of the IT team. If the discussion is deferred until UAT or production, then the costs of remedying could be very high indeed — or in a worst case scenario, the users might simply choose not to use the solution, falling back on manual processes or ‘end user computing’ applications that they develop themselves in Access and Excel (which are below the radar of corporate IT and aren’t scaleable). Sounds bizarre — but it happens.
There are far too many high-profile project failures which haven’t taken the user’s needs into account. A case in point, the UK’s Public Accounts Committee recently released a report showing that the (now cancelled) FiReControl project will have wasted nearly £470 million, and two of the specific reasons mentioned are (a) the operational environment was more complex than the project team thought and (b) the users weren’t bought into the solution anyway. That’s £470 MILLION. A sobering thought. Two recommendations directly from the report:
“treat IT projects as business change projects from the outset, working to align
the business purpose, the change needed to be delivered and the IT system(s)
to enable project benefi ts to be maximised;”
“ensure end users are fully part of the programme team from the outset;”
References:
For the full report, see National Audit Office Report (HC 1272 2010-2012): The failure of the FiReControl project
http://www.nao.org.uk/wp-content/uploads/2011/07/10121272es.pdf
Hi Adrian
thanks for the reply and comments. The FiReControl is nice contemporary case study which I can quote in a presentation I’m trying to put together. The reported reasons and recommendations clearly support the “all IT projects are really business projects” arguement. The earliest possible involvement of BAs has to be the recommendation to the change governance function, where-ever it sits in an organization.
Hi Mal,
I’m really pleased that you found my reply useful, and it’s awesome that you’re putting together a presentation to get wider involvement.
I’d really like to drop you over some links to some additional resources that might help you. This is a topic I’m really enthusiastic about, and I’ve previously put together a similar presentation. In fact, I spoke about a similar topic at the BA Conference Europe 2012 — so I have some ideas that you may be able to incorporate in your presentation.
If this would be useful, could you drop me a line through the “contact us page” of my blog, so I can reply to you directly? Here is the link: http://www.adrianreed.co.uk/contact-adrian/
That way, I’ll have your e-mail address so I can reply privately to you.
Cheers & good luck!
Adrian.
Pingback: Mind the gap when buying IT | Adrian Reed's blog