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

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

Unbundling complex organizations to simplify IT Projects

How to simplify organizational complexities in order to understand and analyze the “What”, “Why”, “Who”, “When” and “How” of an IT project.

The first step is to “Unbundle” an organization into it’s constituent categories, functions (or business units/departments), and processes. In so doing you are then able to profile these components and analyze and understand how and where they are interconnected with each other and their relationships.

Unbundling the processes will also give you visibility into what, where and how manual (and often undocumented) processes are interconnected with automated computer-based processes. This is important because as one interconnected process is changed it will likely impact upon other processes which will in turn impact on further processes and so on creating a ripple effect (the butterfly effect). It is essential to identify common interfaces between manual and/or computer-based systems in order to better understand what and how processes are influenced.

Once the functions, departments, business units and processes have been unbundled, you are then able to identify the most appropriate parties that need to be involved and included in the IT project. Often only the most obvious or prominent parties are identified as essential for the project, however, by unbundling we are able to identify the more obscure or indirect parties and processes. These additional parties and processes can often be a key source of project requirements and will need to be solicited for their input and involvement. It is also helpful to identify key communication points, informal and formal information sources, possible areas of change resistance or support and who needs to be involved in the decision making process.

Unbundling the external value chain will identify if, where and how suppliers and customers integrate into an organization’s incumbent IT systems, functions, departments and processes. This is also a major source of project requirements and will allow the parties to understand precisely how they will be impacted and what they need to do to adapt to the change.

Remember 80% of an iceberg is out of sight and similarly the vast majority of project requirements are largely hidden.

Unbundling the Pre-implementation process enables us to break each step down into specific disciplines. At the outset of a project these disciplines all require strategic decisions to guide them so that they can be successfully established, executed, managed and adopted by an organization throughout the projects life-cycle.

1. Pre-investment decision making process
2. Communications
3. Executive, stakeholder and user support
4. IT governance and risk
5. Success metrics and strategy
6. Change process
7. User input and requirements gathering
8. Training and process development
9. User adoption
10. Vendor and solution selection

In my next post to this blog I will investigate the first of these disciplines the all-important “Pre-investment decision making process”.

Kind regards
Sarah Jane Runge

IT Project Issues and Causes

It is still incredible that people expect IT projects to proceed successfully when they have not done sufficient planning at the outset?

It’s a bit of a Catch-22 – you cannot plan if things that have not yet been fully decided and agreed upon and at the same time you cannot manage something that has not been planned.

When a project starts to go off the rails, chances are that the root cause of the problem can be easily traced back to poor project decision making processes before the project commenced. So in order to understand the many possible reasons and causes for IT projects failing (to varying degrees), we need to review events at the *inception* of IT projects rather than analyzing problematic outcomes *after* the proverbial brown stuff hits the fan!

Specifically it is an organization’s pre-investment decision making and pre-implementation planning processes that needs attention – not scapegoating and other such unproductive exercises. If these strategic processes are either not established or lack structure and rigor, decisions will be insubstantial with a lack of accountability for the outcomes. The flow-on effect of weak decisions is guaranteed to adversely impact the project once it gets underway.

My in-depth analysis of failed IT projects clearly demonstrates that problematic project outcomes are almost always directly attributable to insufficient or poor strategic project decision making at the outset.

The following issues and associated causes may well ring a bell!



The above sample of issues and causes is by no means exhaustive but is indicative of common causes of IT project failures.

A final word on strategic decision making is that these decisions *cannot* be made in isolation by a single person who “deems” themself to be the chief decision maker. For decisions to be accurate and also supported by an organization and peers they require collaboration and accountability.

Kind regards
Sarah Jane Runge

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 failed or derailed IT projects. Everyone is responsible for the project and no one is accountable for its outcomes. This issue will become even more apparent as the project progresses. 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 investment and 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? 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 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?

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).

Kind regard
Sarah Jane Runge

Causes for IT Project Failures

A lot of blogs out there are dedicated to analyzing IT projects once they have failed and the cause nearly always tend to be the same. I want to make a difference!

I am a Kiwi (New Zealander) born and raised, which makes me a straight talker, no BS and you won’t need to read between the lines. In 1985 I moved to Australia to pursue my IT career. Back then NZ didn’t have a lot of opportunity for IT professionals to advance (things have changed now). Being a “pseudo” Aussie means I am objective, confident, don’t mind being wrong and love to hear other people’s opinions.

This blog, myself and my company (ITPSB) are dedicated to helping organizations minimize the risk of their IT projects failing, under delivering business benefits or the dreaded budget and time overruns. Most of these issues are avoidable provided that sufficient pre-implementation planning and execution of strategic decisions are undertaken before projects commence.

Having been involved with both the business and technical side of IT projects for over 24 years and also having conducted numerous research investigations and interviews into why IT projects continue to be hindered in some way or another – there always appears to be a myriad of reasons given as to why individual projects failed. Reasons that are identified in hindsight: such as poor management, communication problems, lack of project support, lack of technical expertise, over-promised and under-delivered, vendor issues and so on.

However, the single key issue that I have isolated as the primary cause is the Strategic IT Project Decision Making and Execution (or lack of) in those decisions. If strategic project decisions such as “why are we investing”, “who is responsible”, “how is the organization is going to secure project support”, “actively involve users”, “communication strategy”, “identify requirement sources”, “training”, “project sponsorship”, “management support and leadership” are not made before the project commences then planning their execution becomes mission impossible!

Over the next 10 days I will post to this blog on the subject of Corporate Profiling.

Corporate Profiling will detail the various organizational disciplines that must be addressed by the organization and its executives before they undertake their next IT project. So I look forward to your feedback and comments.

For a preview of my book “Stop Blaming the Software – Corporate Profiling for IT Project Success” please feel free to view my SlideShare.

Kind regards
Sarah