A Case for Simplifying IT

What is the problem?

Many companies are finding that 60-80% of their IT budget is required just to ‘run’ the business. As a result, growth and innovation initiatives struggle to get the required funding. Most CIOs know this high costs is a result of complexity in the IT environment. Because of this complexity, it costs a lot to support current IT, and costs of implementing new projects increase.

Simplifying technology environment is necessary to create the financial capacity to support growth initiatives.

Why is IT so complex?

ComplexityMost CIOs struggle to answer a simple question like ‘how many applications do you have? A typical IT shop can have hundreds of applications.  Large application portfolios result from legacy systems, mergers and acquisitions, organisational silos, urgency leading to tactical solutions, and vendor over promising.

The issue is then further complicated by multiple technology platforms, some new and others legacy. There is usually a proliferation of servers with unique configurations to run these applications.

Strategies such as ‘best of breed’ can also increase complexity. As different solutions from different vendors (using different technologies) are acquired and integrated over time, the overall complexity keeps growing.

Duplicate or multiple systems

Companies go through mergers and acquisitions. Each acquired company brings some unique business processes, and rules and systems, which support these. This invariably creates an increase in applications that do similar functions, but are different or need a different technology platform.  New interfaces are needed to bring the information together from these systems. In these cases getting accurate stock information is very difficult. Complexity thus leads to reduced accuracy.

At other times, different departments have their own sales tracking or customer management systems, which largely do the same function. In large organisations, due to silo decision-making processes there can be multiple such duplications. A company I worked in had 26 different payroll systems.

Obsolete systems

In some companies there are many applications, but only a limited funding for maintenance. As a result of budget and inertia, most applications are not upgraded for years. They become unsupported, and the company must rely on old technologies. By avoiding or deferring the upgrades, we create a ‘technology debt’, which increases over time like a snowball. This means that when upgrades are required (e.g. year 2000) these become expensive. Application functionality also gets out of date and new functionality cannot be quickly leveraged. Newer applications and more interfaces are then created, thus compounding the problem.

Abundance of Interfaces

SpaghettiNo CIO intentionally wants to increase the complexity of IT. New applications are acquired for new initiatives and business expansion. Many start as stand-alone applications, however, over time interfaces are built between new and existing applications.

As the increase in interfaces is proportional to the square of the number of applications, the total number of interfaces quickly multiples. Many of these interfaces are inefficient, as they are trying to connect two systems with different processing rules, data structures. and data meaning. As the number of interfaces increases, their quality decreases further. Daniel Lebeau – Group CIO of GlaxoSmithKline has called interfaces the ‘cancer’ of IT.

High cost of complexity

Other than the high IT cost to run a company’s business, complexity brings about other costs. When business processes are fragmented across multiple applications, it becomes difficult to get right data. Unsupported technologies increase the risks of failure.

Perhaps the biggest cost of complexity is the reduction in a company’s ability to take advantage of new opportunities presented by the new digital economy. Taking advantage of these opportunities needs streamlined business processes, accurate master data, and a robust foundation of systems. An IT environment that is complex and fragmented with a mix of technologies, and applications is vulnerable to hackers.

Complexity can be justified in some cases. It is usually justified when complexity allows the business to differentiate its offerings to create value.

Why simplify?

Three benefits of simplicity include reductions in operating costs, increases in agility, and the lowering of risk. As Tim Schaefer, CIO at Northwest Mutual, explains:

“There are actually three types of value that we are generating out of the simplification effort. First and foremost, we want to create dollars that can be invested in growth opportunities. Second is the value we get around risk reduction, and in particular, how we can increase the agility of the company. Finally, by simplifying our technology environment, we are actually opening up room and capacity for newer technologies.”

Strategies for the Simplification of IT

It is not easy to cut IT complexity, a sustained and multi-pronged approach is needed.  We recommend three key strategies. These are

1)      Rationalisation of applications;

2)      Standardisation of infrastructure; and

3)      Effective governance.

1. Rationalisation of Applications

For many companies scope for application rationalisation is large.  Boston Consulting Group (BCG) estimate that reductions of up to 40% in the number of applications, and 15-20% of IT costs is often possible.

Application rationalisation involves consolidating duplicate/redundant applications and the progressive decommissioning of replaced applications. Without decommissioning, the cost reductions will only be minor.

Successful rationalisation has three prerequisites:

  1. Top team agreement – As the rationalisation is a longer term initiative and not a quick fix, strong commitment from the top team for the simplification agenda is necessary.
  2. Proper funding for the job – Often the business case for the rationalisation does not seem attractive in the short-term. Ensuring proper and sustained funding is necessary.
  3. Tracking progress – Disciplined measurement of progress is necessary to make sure that goals of rationalisation are being achieved. Aligning IT Executive incentives to the reduction in applications is also recommended (e.g.  5% reduction each year).

2. Standardisation of Infrastructure

BCG suggest that reducing “infrastructure patterns” (configurations of software, hardware, and middle-ware) should be reduced to a smaller number of standard configurations.  Typically the patterns can be cut down by more than half. The recent growth in the adoption of virtualization technologies has broken the ‘one application, one server’ rule, which makes the rationalisation process somewhat simpler. Reductions in these patterns cut maintenance costs, enable better deals from the vendors, and cut provisioning time.

BCG reports that one company had 9,000+ applications and over 1,700 technology patterns. All of these required maintenance. This company eventually determined that just 7 patterns would support 80% of the application needs. This level of standardisation enabled cost savings of 40% over three years.

3. Effective Governance

Effective IT governance is needed to make sustained reductions in complexity. If  business units continue to make decisions in a silo way, and little thought is given to impact on other systems or other business units, complexity will start to grow again.

A clear governance framework and agreed blueprint describing target architecture are essential. Simplification principles should become part of this governance framework to prevent building new complexity. Strict governance enables effective portfolio planning and the optimisation of IT architecture. This is a key to reducing complexity in the longer term.

Summary

In most companies IT complexity grows with time. Tactical systems, mergers and acquisitions, and new technologies all lead to a more complex IT environment. The result is fragmented business processes, lack of correct business data, higher costs and risks, and lower agility. The bulk of the IT budget then gets consumed in keeping the business running.

IT simplification is not easy, but the benefits are large. It frees financial resources, reduces risk, and improves agility. Reducing the number of applications in the portfolio and reducing infrastructure patterns will simplify the IT environment. Success depends on a strong commitment from the top team and effective governance.

Written by: Hemant Kogekar

Real Reasons why IT Projects Fail

You would have probably read about the Queensland Department of Health payroll project, which ended in a debacle with costs estimated at $1.2 billion. In the US, the Expeditionary Combat Support System project was cancelled after the US Air Force spent $1 billion on its development.

The sad fact is that these failures are not isolated instances, but rather, only the most visible examples.  The failure of IT projects is very common. Per industry norms, less than 50% of IT projects finish on time and on budget.
Discussions with experienced CIOs, consultants and project managers show there are many reasons for the failures of IT projects. If you step back from the individual causes, some common themes emerge. Some are obvious, but others are not well recognised.

Fuzzy Goals

Many large projects fail, because they don’t have a clear idea of what they are trying to do. There is no clear problem definition or clarity about the project requirements. The full scope of the project is not understood. One Executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced who add their ideas of what would be best for project implementation. The net result is unclear goals, expanding project scope, and poor project design, which lead to unending debates and sliding timelines.

Over-optimism

Over OptimismSalesmen and internal project champions both want their proposal to succeed. However, in their wish to make the ‘sell’, they often underestimate the costs and over emphasise the benefits. While preparing  business cases, there is a tendency to maximise benefits and cut costs to meet the right return on investment (ROI) At times, the under-estimation is not intentional, but a result of the CIO having a poor understanding of the current situation and requirements. The CIO does not consider, or budget for, the effort to move from installing a system to actually achieving the benefits (new products, customers, new capability).
Over optimism then results in unrealistic schedules. There often is an unjustified faith in technology (product, vendor, or internal capability). Solution complexity is not evaluated. As a result, project risks are not well understood or controlled.

Complexity

ComplexityMajor IT projects have a high degree of complexity due to new technology, the myriad of interfaces with other systems, data conversion. and due to project team having to compete for resources with other projects. Many times the legacy processes have to be replicated or supported in the new system, which adds to the complexity.
What project managers (PMs) and executives do not understand is that the project risks and effort involved in the project increase exponentially as complexity increases. Systems and processes become brittle as people try to cater for this complexity in a tight timeframe and with workarounds. The complexity eventually overwhelms the PMs, and the projects go out of control.

Weak Ownership

Large projects often have multiple executives, each with slightly different agendas as stakeholders. The executives have different expectations of the project’s benefits and options, which are at times incompatible. None of the executives fully support the project, and many projects lack an effective sponsor who is accountable for the project goals, and benefits, and can arbitrate conflicting demands. Weak sponsorship also indicates weak accountability across the project. When dates slip, tasks are not completed or roadblocks emerge, and no one is held accountable to do their job, which results in the project becoming unmanageable. Weak ownership usually results in weak project control resulting in an increased chance of the project failing.

Governance

People accept that lack of governance is a reason for the failure of a project. However, most large projects have the exact opposite problem; there is too much bureaucracy. For example, in one IT project, 80% of budgeted costs were non-productive costs or red tape. In another organisation, a 3 day change request needed justification papers, and the approval of the executive steering committee, which costed more than 10 days of effort. In large organisations, stakeholders such as risk managers, compliance staff, process experts, and architects all have their own governance demands, which greatly increases the demands on the project staff.

Over-engineered Project Management

It appears that Project Management has succumbed to the modern fetish for valuing form over substance. Simply put, there is a greater focus on how we carry out the project, than on the activities, which produce the product. Below is a quote from a CIO on this over engineering:

In the past, we spent time working out how to solve a problem. We explored different avenues of approach, different ways of meeting a target. We focused on the customer’s needs and expectations. We focussed on what was to be delivered.

Nowadays, it seems that the focus is more on planning how you are to do it, coupled with a determination to adopt methodologies and standards. The result is that we spend more time planning the method and approach to the project and not working on the technical requirements of the solution and how we can deliver it. The body of documentation has greatly increased. Now we have plan, plus risk analyses, process flows, summary timelines, and all sorts of forms showing who did what, with and to whom, and when.

That gives rise to a more formally documented meetings, implying a new breed of project administrators who manage the documentation and schedule the meetings, adding to the project overhead, both in time and cost.  A second result is that the poor people at the coal face have, in addition to actually doing the work, a welter of forms to complete.

Wrong Project Manager

The major success reason for projects – large or small – is the Project Manager (PM).  Having certification as a PM is one thing, but having the ability and know-how is another. The PM has to know how to balance the needs of the project with the needs of good governance. The PM has to use the right method, apply it at the right time and in the amounts that are really needed. A PM must have knowledge of the subject of the project. This knowledge not only helps the PM drive the right solution, but also helps them to effectively communicate this solution to the business and the sponsor The notion that a qualified PM can manage any sort and size of project is twaddle.

Failure to Recognise a Troubled Project

Projects never go from being well-managed, on-budget, and on-schedule to outright failure overnight. There is always a transition period during which time the project is “troubled”. If you can cut through the noise to see the real issues, you have a window of opportunity in which the project can potentially be rescued. It is likely that this is the last chance to save the project. Since people involved in a project generally want it to succeed, they unintentionally start ignoring or dismissing the warning signs.

Using external reviewers to detect these early signs and help the sponsor take decisive action can often help rescue a troubled project.

Conclusion

Think Big, but Act Small

As shown in this article, large IT projects fail for a variety of reasons. There is insufficient space in this article to go into the details of mitigating these failures, but one last fact is worth mentioning here.

Standish group research indicates that smaller projects (agile or waterfall) have a higher success rate (76%) than larger projects (10%). Research suggests that delivering product in small doses produces positive results. So you can think big, but you need to act small by making every big project a group of small projects.

You may also be interested in Barriers to Transformation.

Written by: Hemant Kogekar

Three Tips for a Stronger Business Engagement

Fostering strong engagement with business partners continues to be a challenge for many IT leaders. For periods of time, such as when, a major project is underway or when a strategy is being developed, relationships with business partners can improve, but in matter of months it drops again. CIOs know that effective business relationships are key to their success. What can be done to sustain business engagement in an ongoing way? What techniques do successful CIOs use? Continue reading “Three Tips for a Stronger Business Engagement”

Can CIOs avoid politics?

Typical CIO Attitudes to Politics

Many CIOs are scared of organisational politics and think it is a dirty business. Often CIOs come from a technology background and technical expertise is their forte. Politics, and wheeling and dealing are not their comfort zone. They focus their energy on finding the best technology solutions for the business’s problems. The CIO’s daily battles are about up-time  service delivery, and project delivery. They shy away from business level politics wherever they can. Many CIOs see politics as a ‘necessary evil’ or some sort of ‘game’ to play. Those who tend to look at politics in this way tend not to be very good at dealing with company politics. Continue reading “Can CIOs avoid politics?”

Understanding the Project Sponsor Role

Many executives become project sponsors, because they want a new product or a service to improve their business operations. Everyone expects the sponsors to know their role, and how they are supposed to work. While there are qualifications required to become a project manager (PM), there are none for a sponsor. The sponsor’s role is an important role, but what exactly are they meant to do? Continue reading “Understanding the Project Sponsor Role”

Attributes of Great Project Managers

Delivering successful projects is a key need for all businesses and IT groups alike. But as we all know, many projects fail or are only partially successful. Projects represent a large proportion of a business’s budget, so when projects don’t succeed a lot of money is wasted. Improving the chance that a project succeeds should be a goal of CIOs. Having the ‘right’ project or program manager (PM) increases the chances of successful project delivery. But how do you find the ‘right’ PM? And what attributes should the  ‘right’ PM have?

I came across a study from the CIO Executive Board that identified what differentiates good from average PMs. Here are some of the Board’s findings:

Skills and Experience

The first selection criteria many organisations use for candidates for PM positions is project management certification. The Board’s study found that mere certification does not predict PM effectiveness.  The results also revealed that PMs with a strong technology background do not necessarily make good PMs.  This is because, PMs with diverse experience across both technology and business areas are typically more effective. Similarly, the study found that PMs that have ability in a broad range of technology or other domains were more effective than specialist PMs with ability in only one field. The implications from these results are that organisations should look to hire PMs that have diverse sets of experience in business and technology, and not rely too heavily on certifications alone.

Knowledge of the Business

Effective PMs understand not only ‘how’ but also ‘why’. They know the goals of their projects and know how these goals fit within the overall goals of the organisation. Effective PMs understand the organisational context within which the project operates. We all have seen too many PMs, who are so focused on their own project goals and success that they ignore everything else. In these cases, even if the project meets its goals, the project fails to deliver the benefits expected.

Understanding the organisation’s goals and strategies enables PMs to broker consensus from the conflicting agendas of the various stakeholders. If PMs lack this organisational knowledge, providing them with a mentor, who has the right organisational knowledge can help increase PM effectiveness.

Managing Stakeholders

High performing PMs become ‘business partners’ and not just ‘order-takers’. Order-takers typically focus on delivering what is specified even if it is incorrect or even if the circumstances change. On the other hand, ‘business partners’ improve their own credibility and gain the trust of the project sponsor, due to their understanding of a variety of project scenarios. As a result, ‘business partners’ are able to tailor their communications and frame their problems to overcome difficulties or  find the correct way forward.

Effective PMs develop relationships across the organisation so that they understand organisational dynamics, conflicting agendas, and the different personalities of key stakeholders within the organisation. This enables these PMs to consistently avoid barriers and successfully steer through complex issues.

Smart PMs tailor their communications to suit the needs of the key project stakeholders. Technology projects have both technical and business stakeholders with quite different needs and knowledge. Good PMs can convey the project’s progress and challenges with the right level of jargon and detail to different audiences, while at the same time maintaining their engagement with the project. Technical PMs typically use language that is foreign to business people. When key decisions are not understood or endorsed by key stakeholders, this can lead to costly consequences.

Team Leadership Ability

The importance of team leadership skills is often underestimated when businesses select PMs. Effective PMs understand what the team needs and tailor their communications with the team to drive the team’s performance. These PMs correctly assess and leverage team members’ skills, and are able to gain the trust of their team members.

Poor PMs, or ‘bullies’, run the team into the ground while the project is delivered. Although PMs with a poor track record of team leadership may make some short-term visible gains, these PMs often constrain the long-term success of the project. Team morale is a good indicator of a PM’s effectiveness. Good PMs not only deliver the project outcomes, but build a team’s capabilities throughout the project.

Ownership and Commitment

According to the study, two of the top three drivers of PM effectiveness are “passion to succeed”, and an “ability to meet internal deadlines”. When selecting PMs, leaders should seek potential candidates, who show these attributes.

Good PMs understand and help define the project success criteria. These PMs then become internal project champions by demonstrating passion in delivering the project and holding themselves accountable for the project’s success. Good PMs don’t find excuses for non delivery, rather, they strive to deliver the best outcomes.

Effective PMs follow the standard project processes, but look for ways to improve these process to remove bottleneck, time-consuming step, and other inefficiencies. CIOs should support and allow effective PMs to suggest process improvements where right.

Managing Project Risks

Effective PMs are skilled in anticipating the risks that will come up throughout the project life-cycle. These PMs not only identify risks, but are also effective in developing strategies to mitigate these risks. Effective PMs also communicate these risks to other stakeholders, to gain support for the mitigation of these risks.

The study found that there was a large difference in the ability to anticipate and manage risks between the top and bottom performers. So it would be advisable to use this as a filter in selecting PMs for critical projects.

Grace under Fire

Projects are stressful; a smooth running project is a rarity. Good PMs can maintain their cool and stay level-headed in times of crisis. They maintain composure and guide their teams through the myriad of crises and challenges that projects encounter.

Problems Solving and Quick Learning

The best PMs are experts at solving the problems that a project encounters. These PMs deal with insufficient or ambiguous information and are quick learners who rapidly draw lessons from unfamiliar situations and concepts. The best PMS are able to modify their own behaviour based on these lessons learnt.

Driven to Success

Good PMs are ambitious and success oriented. Organisations need to recognise this and create development pathways for PMs to progress to more senior roles. If organisations fail to look after good PMs, they will find challenges and opportunities elsewhere.

Summary

Project success depends on having the right project managers in place. I hope this article has given you useful guidance on the attributes of successful PMs that you can use in the PM selection and development process.

What other attributes you have found that characterise good PMs? Please let me know.