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

Overcoming IT Project Complexity with Business Simplicity

Albert Einstein said:

“Things should be made as simple as possible, but not any simpler”. 

However, all too often, organizations seem to ignore these sagely words preferring to “complicate everything as much as possible, and no less so”.

Why is it then when so many industries strive to adopt simplification measures (or a "Simplify and Repeat" process) to create consistent quality outcomes that deliver "stakeholder delight", eliminate superfluous handling, reduce costs, and minimize wastage, when at the same time the IT industry consistently does precisely the opposite?

Meaning that layers of unnecessary complexity applied through methodologies, frameworks and processes that promise to ensure project success rarely ever do so. On top of this, although IT project failure is a consistent outcome, it is obviously not the outcome we seek but it continues to happen consistently.

There are several opinions as to what exactly defines complexity. Roger Sessions focuses on the unnecessary overcomplexity of architecture, or technical aspects.  

Peter Kretzman on the other hand, identifies complexity as more cultural and sociological in that people want too much functionality. There is poor implementation (technical debt) and a lack of leadership. 

More recently, John Zachman has responded to organizations' objections about costs, the time and complexity of adopting EA frameworks for the purpose to which they are not intended.  

These definitions of complexity provide insights as to how organizations are changing their mindset from cumbersome, costly and complex solutions to looking for a more cost efficient, simplified and fresh solution to delivering up corporate information.

In my opinion we have facilitated this complexity by over-specialization of every aspect of IT planning and delivery. Don't misinterpret me. There is a time and a place for specialization but it cannot take precedence over the business planning process for IT projects.  If specialization has crept in, you can bet dollars to donuts that business has crept out and have wiped their hands of any involvement.

Have you ever taken a long hard look at how complex the process of planning and delivering an IT project has become? I am not talking about the complexity of IT systems themselves, rather about the exclusive frameworks, processes and methodologies required for the supposed successful delivery of IT projects that we have allowed to morph from smart simplicity into corporate complexity (or perhaps a better word that I came across the other day is Dumbplexity).

“Dumbplexity” sums up how organizations habitually add unnecessary and dumb complexity when in actual fact what they really need is “Smart Simplicity”. And in the IT industry we have Dumbplexified what were and still should be relatively simple processes.

Unfortunately corporations and government tend to follow suit with a blind belief that complexity is a guaranteed recipe for IT project success. But with this additional and unnecessary complexity comes communication and collaboration issues, poor visibility, no accountability and over-inflated costs (which to most organizations is also another measure for success). But nothing could be further from the truth.

As a key decision maker, CEO, Business Owner etc, you are probably frustrated by the number of people required to pass around pieces of information regarding their views on the facts and accurate status of your IT project. And more than likely, you're up to your eyeballs looking at extravagant Gantt Charts with overdue tasks.  Coupled with the complexity of the above mentioned processes, your time spent filtering through the many versions of the truth still cannot guarantee the successful delivery of your IT project.

In this day and age of cloaking simplicity with complexity, it possibly takes an Enterprise Architect, Information Architect, Business Analyst, Project Manager and an “Information Sanitizer” to provide you with the information you’ve waited days (or weeks) for. And it still may only be the information that they want you to hear.
Unnecessary complexity results in delayed information which in today’s environment does not support a nimble, agile or timely decision making process. Complicated processes and frameworks that underpin IT delivery are unlikely to be a guarantee for success, and they also certainly have little chance of putting you and your colleagues on the same page.  Particularly when everyone is singing from a different Hymn book and speaking in jargon related to their own particular specialization.

Another key issue for CEO’s and business enterprises when there are various IT specialists is that it also fosters a culture of "Kingdoms", Silo’s and disparate entities that pride themselves on sole proprietary and exclusivity of information that is not readily shared or made accessible to business. When in actual fact business are the people that absolutely need it, and it is them that need it in plain business English not in some jargon that they cannot understand.

How do you cure “Dumblexity”? By applying “Simplicity”. See the process for what it is and remove the additional layers that have made the process unnecessarily complex.

The three key pillars for IT project success that you need in place are:
•    Visibility across your organization upwards, downwards, right and left;
•    Accountability for quality information and decisions, and empowerment;
•    Collaboration with the appropriate people, parties and layers of your organization.

When you have these pillars in place you can remove the majority of unnecessary complexity that strangles successful IT project delivery as well as your business's profits. You will have your finger back on the corporate pulse, timely access to accurate information, open communication, bi-directional feedback and one organization pulling together to achieve the vision – IT project success, instead of “Us and Them”.

If you are serious about the success of your organization and your IT project outcomes,  ensure that you take measures to mitigate against dressing simplicity up as complexity, "Prima Dona’s" masquerading as "Self appointed experts" and jargon that business executives cannot understand and therefore feel that they don't need to be involved because it belongs in  IT's domain. 




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 Information Architecture Genius!"

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

Bridging the IT and Business Terminology Chasm.

With CIO’s becoming more business oriented and CFO’s becoming more IT savvy, where does this leave the CEO and how should they change or adapt to fit into the IT planning puzzle.

How can your technical teams adapt and change to help bring your business and CEO into IT pre-implementation planning discussions?

I attended a Prince2 User Group meeting in New Zealand late last year where presenters and attendees discussed typical issues that they encounter when communicating IT project planning needs to business or non-technical executives.

One example given was in:

‘Discerning what “Tolerances” to factor into a project’.

Business people not versed in Prince2 terminology didn’t grasp the significance and implications of “Tolerances” leaving IT hanging without a satisfactory response that they could factor into their planning.

Another instance was where the terms “Actors, Artifacts and Use-Cases” were thrown into the conversation at a business meeting. Needless to say – Blank looks abounded!

One key issue with having so many different technical and methodology specific terms and jargon, is that the chance of business executives understanding what you are talking about is pretty remote.

In the event that business doesn’t understand what IT is talking about, often the question will be side-stepped or they may even agree with what you are suggesting without even knowing what it is that they are agreeing to because business executives are not inclined to question techno-speak!

Acknowledging that qualifications in Enterprise Architecture, Process and Business Analysis, and Project Management methodologies are hard won, it is no wonder that we like to use our specific terms when we can. It is also certainly handy to have commonality of terms across IT teams.

However, business and executives require business terminology for understanding and clarity in order to be more involved, committed, and accountable for the “pre-implementing planning and IT investment decision making phases” of IT projects.

This is where "Profiling-Pro" comes into the picture.

In a nut-shell, Profiling-Pro is a cloud computing service that produces presentation quality reports in business-speak aimed specifically at the pre-implementation planning and decision-making phase. It bridges the chasm between IT people struggling to get their IT Projects approved and on the right track and C-Level executives who need to be reassured that all bases have been covered and that matters such as diligence in requirements gathering have been addressed.

Because these phases are critical to project success it is a very good idea to ensure that business, IT and executives are all speaking the same language and understand what is being proposed or asked for at the outset.

Consequently, CEO’s need to have a very clear picture and a broader view from a business perspective of what elements need to be addressed  during IT project pre-implementation planning phases if they want to begin bridging the chasm rather than just going along for the ride with their cheque book.

Additionally, we need project teams that can not only think like Architects, Analysts and Project Managers but can also relate specialty technical concepts in business terms to mitigate any cross communications or understandings.

A small change can make a big impact!

Kind regards

Sarah Jane Runge

Top Down Accountability For IT Project Success

So how can we manage C-level executives of organizations before their next IT Projects commence?

Specifically, they need to be kept fully accountable for their initial input and project decisions that they make *before* the project commences. This is because these are the critical investment and pre-implementation decisions that will drive subsequent business processes for these IT projects.

As HP CEO, Mark Hurd, went on to say about the job of the CEO: "At the end of the day, [the CEO has] gotta get this part [business processes] of the business right to be able to align IT throughout the company. It's no different than aligning your sales organization, aligning your R&D, aligning any other piece of it."

Rather than letting CEO’s and Chief executives lay the early foundations for IT project failures (through poorly made, unfounded and unaccountable decisions), organizations needs to manage and delegate upwards. This will prevent them sitting back while their minions, who actually execute the project, take the fall for what they could have prevented at the projects outset. By making better decisions and hence ensuring robust project processes,  accountability of all executive strategic project decisions will be assured.

A point that James Taylor makes in his article, “Make Better Decisions”, is that organizations, and especially senior executives, should conduct some form of decision making discovery. This is a critical issue that I support and one that I believe should predominantly also include C-level executives.

Even the best Project Managers and project management tools, cannot ensure the success of a project if the initial strategic investment and project decisions made by C-level and senior executives are poor, devoid of input, lack hard facts and where the executives making them are not held accountable.

Critical project discipline decisions, as outlined below, all result in the development of important pre-project planning and business processes. If these decisions are delegated, glossed over or taken without sufficient collaboration and input from the *appropriate* parties, then the supporting business processes will thereby also lack substance.

    * Communications
    * Requirements gathering
    * Stakeholder support and involvement
    * Management support
    * User support and involvement
    * Strategy alignment
    * Success and Progress Metrics
    * IT Risk and Governance
    * Solution and Vendor Selection
    * Change Management
    * Training and development

Each of these strategic project disciplines and business process decisions should be orchestrated at the top of the organization by the CEO and C-level executives. In order that these disciplines don't become "Reasons for Failure", critical decisions about "Who" and "How" to execute and manage each discipline must be made at the top of the organization.

Because many of these disciplines and business processes are already incumbent within organizations, a general blaze attitude to addressing them can become prevalent. For this reason, C-level executives unfortunately often abdicate any responsibility for making these discipline decisions, thereby removing most of their accountability.

This may all seem a bit harsh, however I have rarely (if ever) seen any CEO or C-level executive become a scapegoat for a failed IT Project - (other than the unfortunate CIO).

Kind regards

Sarah

IT Project Success through Corporate Profiling

Check out this SlideShare Presentation:

IT Project Success through Corporate Profiling

View more presentations from Sarah Runge.