Showing posts with label IT project failures. Show all posts
Showing posts with label IT project failures. Show all posts

Wednesday, July 25, 2012

8 Popular Misconceptions about IT Projects


Steering clear of the Kool-Aid Drinkers in Project Planning!

As the two certainties in life are “Death & Taxes”, so too in IT Projects are the certainties “Success or Failure”.
At some point in our lives we will have been involved with a Project, either the project planning, project delivery or perhaps another phase. Whether it was an IT project, business planning, change management or a construction project, the difference is irrelevant. Because projects will either succeed or fail, it is just the amount of variation between the outcomes that provides us with the grey pieces in the middle.
And no doubt at some point during that project you will  have heard blatant excuses by business executives for making the wrong decisions, had discussions driven by decibel  domination or encountered one of the scenario’s described below.
 Enjoy!
 1.   Believing 3rd Party Vendors know your business better than you do
It’s alright to delegate and outsource tasks, but you absolutely cannot delegate or abdicate from your responsibility of identifying your business requirements to a third party vendor by allowing them to dictate their notion of the business requirements for your IT project are.

HOW TO TAKE ACTION: Kool-Aid time is over. You need to identify your own business intelligence experts and free them up to undertake your business planning and business requirements gathering work. They have to know exactly and accurately where and from whom your business requirements should be sourced.

2.   The Top-Dog must be right (or How to stop the H.I.P.PO “Highest Paid Persons Opinion” mentality dead in its tracks)
Hippo’s have either the authority, expertise, or power to edify themselves and their decisions to the point where no one questions or challenges them.
HOW TO TAKE ACTION: Ask the hard, overly obvious or dumb questions regarding their decisions because they never expect to be challenged. And make sure that they understand that they are held accountable for their decisions.

3.   Incompetent Vendors and 3rd Parties or inadequate software packages cause IT Project Failures
The fact is that vendors are rarely incompetent and software packages are very seldom inadequate.
You will be amazed at how many IT project failures have occurred simply because one or two people insisted on a course of action that was flawed and the vendor selection was based upon a bias selection process by C-level executives. Or a self appointed expert inaccurately deemed business requirements to be accurate and comprehensive based upon their understanding of the business. And based upon those requirements a solution was selected or the external party was asked to deliver to those requirements.
HOW TO TAKE ACTION: Stamp out the H.I.P.P.O. mentality, promote meaningful and intelligent collaboration and establish a rigorous vendor selection process rather than just appointing an incumbent provider for the sake of “One Stop Shopping”, or because of exclusive relationships with key decision makers or the lowest quote (that never works).

4.   Build it and they will come!
If it doesn’t meet business objectives, business won’t support it.
If end users don’t like it, they won’t use or adopt it.
If it does not include external customer & supplier requirements, they can’t use it.

HOW TO TAKE ACTION:  Create visibility to identify, ask, involve and collaborate with the appropriate people and parties. Otherwise you are flying blind and will end up with a very expensive White Elephant.

5.   The vendor, systems implementer or developers didn’t deliver what we asked for!
More than likely they did. But what business asked for was possibly inaccurate or lacked adequate scope at the outset.
This is the risk you run when you either delegate requirements gathering to 3rd parties or alternatively, if business doesn’t have the required visibility across your business architecture to identify correct and complete requirement sources, they will garner inaccurate and incomplete business requirements with obvious disastrous consequences.
HOW TO TAKE ACTION: Get back into the drivers seat of your IT Project business planning, create visibility and transparency to identify accurately what the business needs before involving external parties which inevitably only muddies the waters.

6.   Our organization’s size, massive budget and the resources committed to this Project will guarantee it’s success (or size matters)
How many times have you seen unlimited money thrown at a problem? No, it absolutely won’t guarantee success!  More likely the opposite will happen because a big budget and long time frame (more than 12 - 18 months) is a recipe for failure! No other way to tell you. Sorry!
HOW TO TAKE ACTION: The universal law of IT failure is big + expensive + long delivery = failure. And the recipe for IT success is simplicity, incrementalism and small budgets. Take a look at Roger Session’s information about Project size and why it matters.

7.   IT Departments must always be in charge of all aspects of IT Projects because they know better
Well this response is fine as long as they are installing hardware, upgrading software licenses, developing code or something other than planning or implementing a business solution. IT driving business projects is the tail wagging the dog.
HOW TO TAKE ACTION: You need to put Business in charge of the business requirements and business outcomes of IT Projects. IT (and yes I am looking at you PMOs) can claim to know everything about business and to understand business better than business (which they often claim to). But what would happen if we had business experts claiming to know everything about IT just because they may be proficient at networking, routers and Visual Basic.

8.   When it comes to IT project planning, Business doesn’t know what they need which is why IT has to step in
The truth of the matter is that business generally does know what it needs, but what they articulate is not fully comprehended by IT, 3rd partys or vendors. This is due to a tendency for premature elaboration and interpretation of what other people understand about the business needs. To make matters worse, specialists shroud communications with jargoneze that only they understand.
HOW TO TAKE ACTION: Cut to the chase by ignoring IT and specialist jargon. If they cannot tell you in plain language what they understand business to require, then go back to the drawing-board.
Business planning for IT projects requires a cross functional team, IT and business. However, the IT guru’s need to sit down, zip it and listen very hard to what business is saying and asking for. 

Kind regards
Sarah Jane Runge

 PS. Do you need to put the "B" back into the business planning for your IT Projects? Then take advantage of our complimentary 30 day free trial to our Profiling-Pro cloud solution at www.profiling-pro.com. 

PPS. Or register here to attend our upcoming Seminar:
"The Path to IT Project Success through Business Architecture Genius!"

Tuesday, July 24, 2012

IT Project Failure and The Art of Scapegoating


 With Scapegoating still high on the agenda of Executives,  Boards and CEO's I figured it was time to readdress this issue and ask the question:
"Is your organization geared up for IT Project Success or will a Scapegoat suffice?"

IT Project Failure and The Art of Scapegoating

Have you or someone you know ever been the scapegoat for a failed IT project? If so read on. This may give you a déjà vu feeling.

And as the saying goes, “A good scapegoat is nearly as welcome as a solution to the problem”!

This is often a sorry consequence of derailed or failed IT projects. Everyone is responsible for the project and no one is accountable for its outcomes. This issue will become even more apparent through the project life-cycle. Over a period of 1, 2 or 3 years people will either leave the organization/project or will otherwise forget who was actually accountable for having made the critical IT investment and project planning decisions in the first place. Time has a tendency to blur the facts! So what can project sponsors do when they get that sinking feeling that an IT project is heading into deep waters? Hunt for scapegoats! (shhhhh people don’t readily admit that this is what actually happens). Who wants to be held accountable for a train wreck of that magnitude? Nobody – hence the scapegoating!

Unfortunately, organizations typically identify vendors, project managers and CIO’s as the obvious parties (read scapegoats) responsible for under-delivered and over-budget IT projects.

In actuality, the causes generally lie in the camp of the C-Level, senior executives and presidents themselves. Why? Firstly, because often the business executives lack visibility of critical business architecture information and business intelligence upon which to base vital project planning decisions. And secondly, because strategic decisions to invest in IT systems are always made at the top level of an organization.

They should instead be asking themselves where they messed up and analyze whether, why or how their IT investment and project planning decisions were under-analyzed, under-scoped, under-supported, under-communicated or under-trained. Did they make the critical strategic project decisions and follow through with an execution strategy to establish key project procedures or not? Information cannot be expected to be communicated via osmosis or hearsay.

Ask yourself who was responsible for identifying and collecting project requirements and were they empowered and accountable? Were they the most appropriate people or just the most senior or worse still – self-appointed experts?

The other key question that vendors and customers should be asking themselves is “did we assume that extensive requirements were collected and correctly documented from the most pertinent and pivotal parties?” Most of the time both parties just assume that the important task of requirements gathering has been diligently carried out (which is where the slippery slope begins and scapegoats are sought out).

PS. Do you need to put the "B" back into the business planning for your IT Projects? Then take advantage of our complimentary 30 day free trial to our Profiling-Pro cloud solution at www.profiling-pro.com. 

PPS. Or register here to attend our upcoming Seminar:
"The Path to IT Project Success through Business Architecture Genius!"


Kind regards
Sarah Jane Runge

Monday, February 13, 2012

Gearing up for IT Project Failure!

You sometimes have to wonder why Government and even Corporates think that they are immune to the risks of IT project failures. One would think that prior to making such a massive IT investment decision they would at least have understood and applied the simple rule of IT success:
  "The 1st law of IT project outcomes" - Big budget & Long time frame = Guaranteed failure. You can choose one or the other - but not both.

Even where "Agile" or "Incremental" development methods are applied, they will also fail when the plan is extravagantly "Grandiose", typically with deep pockets, no plan and very likely no accountability. Even Prince2 or Gateway Methodology are not silver-bullets to solve such large-scale endeavors (as is evidenced by numerous UK Government IT Project failures).

History has shown time and time again that throwing big money at a big problem almost always end in tears (except of course for the beneficiaries of the tax payers' dollars who are cajoling Dunne down this doomed highway to Hell).

I am not sure how the IRD (Inland Revenue Department) come up with the figures and statistics or why the New Zealand Revenue Minister, Peter Dunne is apparently agreeing with the statistics and facts referenced in this article at http://budurl.com/q5yx, but this project is already on the road to Hell by virtue of his budget from Hell. 
Kind regards
Sarah Jane Runge

Tuesday, February 26, 2008

Welcome to IT Project Starting Blocks

Welcome to Stop Blaming the Software - Corporate Profiling for IT Project success.

IT Profiling is a simple yet comprehensive process that delivers an in-depth blueprint of the organization, its people, its process, its customers and their relationships.

This is the first step to undertaking an IT implementation.

Only after an Organizational Profile has been established should the company even contemplate investing its hard earned IT budget.

Only then will you know that the investment decision is based upon comprehensive accurate organizational information from the appropriate sources.

Profiling identifies where the interlinked relationships occur within the organization and its immediate external value chain. Profiling also identifies any common or causal factors between corporate, business and IT and more significantly it elucidates hidden or not so obvious factors that would normally be over looked.

In order for comprehensive Profiling to be undertaken there must be a common objective between the three business components and a level of executive support and cohesion that will drive tri-directional communication channels throughout the business components.

Since each component contributes to the development of the organization’s operational, management and implementation processes, they are the key identifiers to profiling the Organization, the enablers of a successful IT Project and ultimately the "sustainers" for future IT change.