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!"

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

IT Project Success through Corporate Profiling

Check out this SlideShare Presentation:

IT Project Success through Corporate Profiling

View more presentations from Sarah Runge.

IT Project Failure - The Root Causes behind every Reason for IT Project Failure

Simply put, IT projects fail not because of what we do, but because of what we haven’t done!

Conventional wisdom suggests that we can identify a set of reasons for project failures post implementation. As Michael Krigsman highlighted in his blog "Six types of IT project failure", classifying the reasons for failure can often illuminate Root Cause for project failure. However, in my opinion by simply categorizing failures often leads organizations to incorrectly believe that there were only one or two aspects of their project that caused it to fail.

My research has identified that the genesis of project failures is in fact an organization's pre-implementation strategic decision making (or lack thereof). The symptoms or reasons for the failure are easily classified but the root cause is often buried because it becomes almost impossible to unravel the causes after a protracted period once the project has failed.

Furthermore, I have found that simply identifying reasons for IT project failures can in itself lead to "Scapegoating" of the parties that were responsible for that element of the project (e.g. the Project Sponsor, Vendor or Project Manager ).

In the case of the Project Sponsor, mentioned in Michael Krigsmans blog, they need to be given the authority and accountability to make project decisions otherwise they will not remain actively and positively involved in the project. If they are not actively involved (with skin in the game), then they are just the "Go To” person, (which can be a pretty unenviable and arduous position to be in). This is just one example (not assigning accountability) of how poor strategic decision making by the organization before the project is initiated puts IT projects at risk.
 
"Failure is not a single, cataclysmic event. You don't fail overnight. Instead, failure is a few errors in judgment, repeated every day" Jim Rohn.

More often than not, what I have found is that the "Root Cause" is generally embedded in the organization as an underlying and fundamental flaw in its pre-investment strategic planning and pre-implementation strategic decision making processes.

These are executive decisions that provide the strategy for How the project will commence and What and Who needs to be included or involved.

Many of the reasons for IT project failures that I have identified, and that Mike Kavis has covered extensively, can be eliminated by addressing these key strategic decisions at the outset of a project, because the potential Root Cause will thereby be identified and addressed before the project has even begun.

Kind Regards
Sarah Jane Runge

Taking the risk out of IT Risk and Governance

,Do IT Risk and Governance measures really help organizations to avoid IT Project failures?

To coin a phrase used by a fellow Twitterer “No process at all is better than a bad process”.

So how many resources, either dollars or human, do organizations invest in establishing IT risk and Governance frameworks? How much time is spent administering, managing and monitoring these processes and what is an organization’s ROI for their IT governance investment?

For all of the above, most organizations would probably respond “Too much”!

It is surprising to find that many large organizations and government bodies that claim to have or would be required by stakeholders to have stringent IT Risk and Governance frameworks still have rogue, run-away or failed IT projects. The following are some of the many examples of organizations and government bodies who experienced the chaos of rogue IT projects:

• The USA Census bureau $2bn in IT project overruns for a project that will probably need to be scrapped!

• Avis Car rental –Europe ERP Project - €45m IT failure as ERP Project is cancelled.

• Melbourne Transportation Authority Australia – Myki project$1bn later and 18 months behind schedule delivering Project “Myki”

• Australian Ports – Integrated Cargo system$217bn cost blowout for a system that still does not work to the extent it was intended to.

• FBI - VCF project $170m for an IT project that had to be cancelled

• Sydney Water – CIBS project estimated $97m blowout and lengthy delays for a project that was scrapped

If an organization’s IT risk umbrella covers IT governance with a comprehensive IT risk portfolio, then how do organizations still get lumbered with runaway and failed IT Projects?

An underlying cause is that IT Risk and Governance frameworks are focused almost exclusively on the “tangibles” of the organization and the direct outcomes of projects giving insufficient attention to the important “soft” intangibles of their organization. This is most critical at the crucial “pre-investment” IT decision making and process planning phase when identifying and determining how to achieve these project outcomes needs to take place.

IT governance will take into account the amount of human and financial resources required for the project and an IT risk portfolio will monitor IT projects, IT service continuity, service providers, information assets, new and emergent technologies, software applications and infrastructure to ensure they are integrated with management, the business benefits and their alignment with strategy.

As critical as these governance and risk measures are to the success of an IT Project, they will fail to deliver if left to act in isolation. Simply put, IT risk and governance measures do not address the internal psycho-analytical aspects of an organization, including its decision making process. Nor do they analyze the “What”, “Why”, “Who”, “When” “Where” and “How” decisions needed in investing in or undertaking IT projects.

These key decisions are fundamental to organizations in determining whether projects will succeed or not and are the foundations and key drivers for determining IT project success. They must therefore be diligently made by C-level executives and senior management *before* projects commence.

In short, all of these key decisions are uncovered and addressed when applying Corporate Profiling to an organization before initiating an IT Project.

Indeed, Corporate Profiling can assist organizations in achieving their expected ROI and other benefits from their IT and Risk Governance processes in delivering IT projects.

“Nothing and nobody fails as badly as when undertaking something that someone else has failed to plan” (Sarah Jane Runge).

Kind regards
Sarah Jane Runge