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 3^rd 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 3^rd 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 3^rd 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, 3^rd 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!"