Interim Management and Project Recovery
-
"The attribute I personally valued the most, was his direct, honest and efficient communication which left no room for uncertainties..."
-
"I was particularly impressed by Henrico`s ability to command a room and get people on board - even people who were initially on completely different pages..."
-
"I was very impressed by his efficient communication skills and deep technological expertise, not to mention his down-to-earth personality and great sense of humor..."
Saturday, January 09, 2021
- Labels: Project Recovery
Can a Task Force Rescue Your Failing Project?
Saturday, January 02, 2021
- Labels: Change Management, Leadership
How a Transformation Office Can Help Your Transformation Initiatives Succeed
The Transformation Office
Core Competencies
Single Source of Truth
Parallel Organization
References
Sunday, December 13, 2020
Project ≠ Program ≠ Portfolio ≠ Strategy
I have had many heated discussions around these terms. People mix these up and it confuses your organization and its people.
This is my take on it.
If your organization is running many projects at the same time it is impossible to make the right decisions if all projects are performed in isolation. Therefore projects are managed in logical groups to use resources efficiently and effectively.
There are two kinds of such groups. Programs and portfolios.
The distribution of projects under a program or portfolio depends on the nature and the type of project. Programs are managed through program management and portfolios are managed through portfolio management.
Let’s start with the diagram below. It shows very clearly the relationship between the three P’s of Project Management.
Project
A project is the lowest level in the hierarchy of project, program, portfolio, and organization.
According to the PMBOK Guide, “A project is a temporary endeavour undertaken to create a unique product, service or result.”
So, you can say that the nature of a project is temporary; once the project achieves its objective, it no longer exists, and the objective of the project is to create a unique product, or develop a system to provide you with a service or the result.
Project management is the application of people, process, technology, knowledge, and skills to achieve successful completion of specific project goals and objectives.
Good project management means teams and team members are constantly developing and improving, giving the business a competitive advantage. Good projects are typically short and fat.
Program
A program is a group of related projects and program activities managed to contribute to the same business objective or benefit. The program as a whole has clearly defined goals, and each project within the program assists in meeting those goals.
So please do not call a large project a program. It is not.
Program management allows your organization to have the ability to align multiple projects for optimized or integrated costs, schedule, effort, and benefits.
Program managers look at cross-project dependencies, risks, issues, requirements, and solutions, and may coordinate with individual project managers to achieve these insights and keep the overall program healthy. They’re less concerned with the success of every single individual project, and more focused on the success of the overall initiative and achieving the larger benefit.
Program managers are also concerned with making sure the right projects are chosen or prioritized in order to achieve the most business value. Successful programs work towards improvements that will have a long-term impact on your organization, and unlike projects that have a specific end date, programs may be ongoing initiatives.
Portfolio
Portfolio is a collection of projects, programs, and sub-portfolios managed as a group to achieve strategic objectives. All these items may not necessarily be interdependent or directly related.
For example your organization has different investments, products or services, but has a global strategy to maximize the ROI. The four goals of portfolio management are:
1) Maximizing the value of your portfolio
2) Seeking the right balance of projects
3) Creating a strong link to your strategy
4) Doing the right number of projects
Portfolio management provides a big picture of your organization's projects and programs and supports leadership to analyse and make the right decisions.
Project management is about executing projects right, portfolio management is about executing the right projects. It is a way to bridge the gap between strategy and execution.
Strategy
As stated before, a portfolio is a collection of projects, programs, and sub-portfolios, managed as a group to achieve strategic objectives. So it comes naturally that for each strategy there exists a portfolio to achieve this strategy. This is reflected in the diagram below.
This also means that if you only have one strategy you should manage all your projects in one portfolio.
In a nutshell: A project is focused on creating a unique product, service, or result. A program is a collection of projects that need to be managed and coordinated together. And, a portfolio is a collection of projects and programs that are managed as a group to achieve strategic goals and a business value.
Thursday, November 26, 2020
- Labels: Project Failure, Project Success
Project Failure Is Largely Misunderstood
For many years, organizations, researchers, and practitioners have analyzed how to manage technology projects successfully.
Among them is the Standish Group, which regularly publishes its findings in its Chaos reports. In 1994, Standish reported a shocking project success rate of only 16 percent; another 53 percent of the projects were challenged, and 31 percent failed outright. In subsequent reports, Standish updated its findings, yet the numbers remained troublesome.
The numbers indicate large problems with technology projects and have had an enormous impact on software development and project management.
They suggest that the many efforts and best practices put forward to improve how companies manage and deliver technology projects are hardly successful.
Scientific articles and media reports widely cited these numbers. Many authors used the numbers to show that technology project management is in a crisis. The numbers even found their way to a report for the president of the United States to substantiate the claim that U.S. software products and processes are inadequate.
The numbers’ impact and their widespread use indicate that thousands of authors have accepted the Standish findings. They’re perceived as “truth” and unquestionable.
However, the Standish definitions of successful and challenged projects are problematic.
They defined software project success and failure by creating three project categories:
> Resolution Type 1, or project success. The project is completed on time and on budget, offering all features and functions as initially specified.
> Resolution Type 2, or project challenged. The project is completed and operational but over budget and over the time estimate, and offers fewer features and functions than originally specified.
> Resolution Type 3, or project impaired. The project is canceled at some point during the development cycle.
Standish defines a successful project solely by adherence to an initial forecast of cost, time, and functionality. The latter is defined only by the number of features and functions, not the functionality itself.
Standish states the following in their report: “For challenged projects, more than a quarter were completed with only 25 percent to 49 percent of originally specified features and functions.”
This means a project that’s within budget and time but that has less functionality doesn’t fit any category, but I assume that Standish has put these projects that don't comply with one or more of the success criteria into the challenged-project category.
So, Standish defines a project as a success based on how well it did with respect to its original estimates of the amount of cost, time, and functionality.
But in reality, the part of a project’s success that’s related to estimation deviation is highly context-dependent. In some contexts, 30 percent estimation error does no harm and doesn’t impact what the organization would consider project success.
In other contexts, only 5 percent overrun would cause much harm and make the project challenged. In that sense, there’s no way around including more context (or totally different definitions) when assessing successful and challenged projects.
The above illustrates some problems with the definitions. They’re misleading because they’re solely based on estimation accuracy of cost, time, and functionality.
The Standish definitions don’t consider a project’s context, such as benefits, value, and user satisfaction.
Starting with the Chaos Report in 2015, the Standish Group seem to have discovered their own mistake. They changed how they define success. This new method coded the dataset with six individual attributes of success: OnTime, OnBudget, OnTarget, OnGoal, Value, and Satisfaction.
The new definition of successful projects is OnTime, OnBudget, and with a satisfactory result. This means the project was delivered within a reasonable estimated time, stayed within budget, and delivered customer and user satisfaction regardless of the original scope.
This definition encompasses both a success rate for the project management of a project and for the project itself. In my opinion, this improves the definition, since we probably all have seen projects that meet the triple constraints of OnTime, OnBudget, and OnTarget, but the customer was not satisfied with the outcome.
In changing from the OnTarget constraint to Satisfaction, they avoid penalizing a project for having an evolving target, which all projects have, even the very small ones. Customers have a clear opinion on the satisfaction level, whether or not all the features and functions they asked for at the beginning of the project are realized.
They support these changes with their own data. They found that both satisfaction and value are greater when the features and functions delivered are much less than originally specified and only meet obvious needs. And they found that most features and functions of software are not used. These additional features increase cost, risk, and quality but do not necessarily provide value.
But in my opinion, these definitions still have a serious flaw. The Chaos Report, and numerous articles citing it, label canceled projects as “failed” and imply that all of them were canceled because of poor project management.
This implication is both false and dangerous.
It is false because, particularly in an era of rapid change, a lot of technology projects are properly started, well managed, and properly terminated before completion because their original assumptions have changed.
It is dangerous because it often leaves project managers with the following thoughts: “It’s becoming clear that continuing this project will waste company resources. I should probably have the project canceled now, but that would make me the manager of a failed project and wreck my career. I’ll be better off if I say nothing, keep the project going, and look for a new project to transfer to.” See “Why Killing Projects Is so Hard (And How to Do It Anyway).”
So what is project success?
Simply put, project success occurs when the outcome of the project adds value to the organization. And the value of a project is defined by subtracting all of the costs from all of the benefits the project delivers.
Value = Benefits - Costs
This can be roughly translated to three levels of project success:
1) Project delivery success: Will the project delivery be successful? Essentially, this assesses the classic triangle of scope, time, and budget. These are your costs.
2) Product or service success: This refers to when the product or service is deemed successful (e.g., the system is used by all users in scope, up-time is 99.99 percent, customer satisfaction has increased by 25 percent, and operational costs have decreased by 15 percent). These are your benefits.
3) Business success: This has to do with whether the product or service brings value to the overall organization, and how it contributes financially and/or strategically to the business’s success. This is your value.
Overall, a successful project depends on the combination of these criteria. Some argue that product/service success is the same as business success, or argue that product/service success automatically means business success. But this is not true. See “Product or Service Success Does Not Automatically Mean Business Success” for more on this topic.
When you look at project financials and translate the above to dollars, you can fairly say that a project is a failure if it has a negative value. This means the total of all the benefits is lower than the total costs. See “What Are the Real Costs of Your Technology Project?” for more on this topic.
You can even argue that a project is a failure if the targeted return on investment (ROI) is not achieved. This is because you could have done another project with a higher ROI in the same time with the used resources. See “What Are the Real Opportunity Costs of Your Project?” for more on this topic.
But what you should not forget is that project success and project failure are NOT absolutes. It may not be possible to be a little bit pregnant, but you can be a little bit successful.
Every project has multiple success criteria related to business results, product/service results, and project delivery results (cost, schedule, scope, and quality).
Some criteria are absolute, meaning they must be completed on or before the original planned date, and some are relative, meaning they must be completed by a date acceptable to the client.
Project success is determined by how many of your success criteria are satisfied, and how well.
Whether or not a project is successful also depends on who you ask—
> the very happy project manager that implemented the SAP project as scoped on time and below budget (I know, this will NEVER happen),
> the end-users, who absolutely hate the complexity and slowness of the new system,
> or the COO that has seen IT costs double whilst none of the expected savings materialized.
These stakeholders may all have very different opinions on the success of the project.
Project success also depends on when you ask.
Twelve months after the go-live, the users will have a better grasp of the system and initial performance problems will have been solved. And slowly but steadily, the expected savings will often start to materialize as well.
So in order to determine the success or failure of your project, you should define all the criteria relevant to your project, define how you will measure them, and define when you will measure them.
In a nutshell: In order to determine project success (and, as a consequence, project failure), you must define all the criteria relevant to your project, define how you will measure them, and define when you will measure them.
Saturday, November 14, 2020
- Labels: Project Success
User Enablement is Critical for Project Success
Any system is only as good as how well it is used.
If it's a CRM, ERP, or any other system, when users don’t know how to use the system effectively the benefits of the new system for your organization will be small, or even negative.
This means user enablement is critical to the success of a project.
It is not enough to simply have your new system in place two weeks before your go-live date.
Your users need to know:
1) Why you’re implementing the new system. When it comes to organizational changes and operational logistics, many employees will be instrumental in the change you’re promoting. It’s important to tend to their needs throughout the change journey.
2) How existing processes will change and which new processes will be introduced with the new system.
3) How to use the system. Your user base can range from people who have spent their entire careers on the “green screen” (yet still don’t know how to use a mouse to copy and paste content) to millennials, who are so accustomed to touchscreens that they don’t know that it’s possible to strike the arrow icon on the keyboard to move an object.
4) Who to contact in case they require support with any problems or questions. If you’re working with an internal service desk, make sure that they’re equipped with standardized scripts. Alternatively, if you’re working with an external service provider, make sure you’ve selected a partner who can provide the highest level of support required for the new system.
5) Whether they can offer feedback and make suggestions to improve the system. One of the best ways to build support organization-wide is to give everyone a voice and a platform to share their views throughout the transition.
Of course, transitions and change management require not only time, but also a stable and working system that can be used to create training, user guides, videos, and user acceptance tests.
So if you are still building and testing your system shortly before going live your user enablement will suffer greatly.
You will have neither the necessary time, nor the necessary trust in the system, you need to achieve user enablement and acceptance.
And with that your benefits will be limited.
In a nutshell: when users don’t know how to use your new system effectively the benefits of the new system for your organization will be limited.
Saturday, October 24, 2020
- Labels: Case Studies, Project Failure
Case Study 14: How Texas Wasted $367 Million on an Unusable Child Support Enforcement System
After investing $367.5 million in a child support enforcement system, the only thing that the state of Texas has to show for is some hard-won lessons.
Initiated by the Office of the Attorney General (OAG) in 2007, “T2” aimed to deliver a secure, web-based system to automate manual functions, streamline daily operations, enable staff to manage case information online, and offer multiple platforms for parents to communicate with the Child Support Division (CSD). Other planned improvements included a comprehensive electronic case file system, standardized forms, an integrated solution for reporting systems, automated generation of child support case documents, and enhanced automation to efficiently establish and enforce child support orders.
Fifteen months behind the original completion date of December 2017 and saddled with a budget that had ballooned from $223.6 to $419.6 million, as of May 2019, state workers were still without a workable system to standardize and simplify child support applications. This angered federal backers to the point where they decided to absorb the loss of the 66% of funding they had contributed to T2.
Senator Jane Nelson, a Flower Mound Area Republican who co-chairs the House-Senate budget conference committee summed it up with: “Stop the bleeding.” This was echoed by Rep. Giovanni Capriglione, a GOP budget writer, who pointed out: “This was a $60 million idea — $340 million ago.”
Perhaps not surprisingly, the project was abandoned four months later.
To be clear, this decision has not affected payments from non-custodial parents to their children and former spouses. After all, a clunky “T1” mainframe system of record keeping – complete with glowing green computer screens that date to the mid-1990s – is still in use by state workers. As they continue to use the system designed by Accenture, under an earlier contract, most workers would be lost without their “quick reference card” that is crammed with acronyms they need to enter before inputting a client's personal information.
Even with their antiquated system, Texas child support workers managed to collect $4.4 billion in the last state fiscal year — the largest amount collected by any state.
Before we continue with this case study...> For an overview of all case studies I have written please click here.
Timeline of Events
2007
In 2007, talks commenced on the need to update the child support enforcement system to establish orders, enforce compliance, and collect and disburse payments.
Soon after, Deloitte was hired to make tech recommendations and create a roadmap to implement the new child support enforcement system.
2009
In 2009, the OAG estimated that the system would cost $223.6 million to develop and would be completed in 2017.
2010
Since August of 2010, the T2 project has been under federal independent verification and validation (IV&V) by the Office of Child Support Enforcement.
That October, Accenture was awarded the contract to develop the system, which was valued at $69.8 million.
2011
A research team at the University of Texas’ Center for Advanced Research in Software Engineering (ARiSE) was contracted to complete semi-annual reviews on quality and progress in July 2011.
2012 - 2014
Deloitte delivered its final blueprint in 2012 and exited the project.
From March 2012 to November 2014, there were 27 change orders initiated by the CSD that inflated the value of Accenture’s contract to $98.3 million.
2015
Ken Paxton took over as the attorney general in 2015, succeeding Greg Abbott (who became governor).
In an excerpt from the October 2015 IV&V report, it was noted that the T2 project was: (1) being driven by an “unrealistic schedule”; (2) the quality of the code components Accenture delivered were “below the expectations” of the OAG; and (3) uncertainty about the development strategy would likely have a “negative effect” on the work environment (including cost increases, staff turnover, and lower productivity).
On November 30, 2015, the OAG was notified that federal funds for the T2 system development contract were frozen pending the approval of an updated project schedule and corrective action plan. The following month, legislators were given a rundown of how the project went off the rails. Their reactions ranged from stunned and confused to frustrated.
"I am kind of speechless," said Rep. Helen Giddings, D-DeSoto.
"I’m just going down a rabbit trail to Wonderland," explained Rep. Dawnna Dukes, D-Austin.
When a reporter referred to the project as "a challenge," Rep. Borris Miles, D-Houston, had this to say: "I’m not going to call this a challenge. There are some other words I’d like to call it, but we’re being videotaped."
At the same time as Accenture took responsibility for some of the failure, its spokesperson seized on University of Texas software expert Herbert Krasner's testimony that Deloitte's $46 million system blueprint was "not worth the paper it was printed on." Deloitte’s media representative responded that when they exited the project in 2012, neither Abbott's office nor Accenture voiced any concerns over their blueprint.
2016
The OAG's office and Accenture agreed to a major contract amendment in 2016. It called for increased reporting to a new state executive steering committee, payments that were commensurate with the quality of the work, and a $20 million "hold" on Accenture's final check until it was clear that the federal Administration for Children and Families would sign off on the work.
Along with the project governance, Amendment No. 1 reset the T2 delivery date to December 2018 and increased the contract to $150.1 million.
2018
Due to changing federal form requirements, Amendment No. 2 (issued in January 2018) reset the T2 delivery date to March 2019 and increased the Accenture contract to $156.9 million.
2019
In September 2019, Ken Paxton’s office confirmed that the (much-maligned) T2 software project had been abandoned, and that they were seeking a cheaper alternative:
“The costs of moving forward with those challenges, when coupled with the ongoing costs to maintain the system upon completion, can no longer be justified when newer technologies exist that are capable of providing the necessary functionality at a lower cost to build and maintain, thus providing a better value to Texas taxpayers.”
What Went Wrong
Exploding Costs
In January 2007, Deloitte’s contract to update the model for OAG’s child support services had an initial value of $1.8 million. Following the OAG’s 5 renewal options, the final contract was valued at $46 million. In that same vein, the system development contract (awarded to Accenture in October 2010) was valued at $69.8 million. After the OAG issued 30 change orders, the value increased to $156.9 million.
According to the Legislative Budget Board, from the idea phase through to January 2019, it cost $367.5 million — $124.9 million of which was state funding.
Outsourcing Challenges
In order to turn a profit, Accenture had to outsource much of their custom development work to 165 programmers in India. Despite security concerns, the Indian programmers were given access to state data and worked on code remotely.
Reviewers repeatedly noted they were “concerned with the low level of quality for work products and deliverables submitted by Accenture.”
Performance Issues
On multiple occasions, the IV&V team reported that T2 had resulted in sub-standard processing speeds, and that switching on key security software only made the issue worse. Although improvements were made over time, the performance was never deemed satisfactory by IV&V.
Defects and Integration Issues
In the summer of 2018, OAG staff ordered additional joint system testing of T2, which revealed over 1000 defects – ranging from minor typos to severe security issues that had to be resolved before proceeding.
Compounding the issue, the process to pull financial data from the original T1 system into T2 was not working correctly.
Infrastructure Updates
Due to delays, the core security software had lost vendor support and needed to be upgraded before T2 could be deployed. This upgrade could not begin until all system defects were addressed.
How OAG Could Have Done Things Differently
In response, Capriglione claimed that, while researching Accenture's work in other states, he spoke with people who'd tell him "it's really not a software company, it's a contracting company. They make very good contracts. It's very difficult to get out of [them]."
Capriglione, who spent two sessions as head of the appropriations sub-committee probing the state's contracting woes, said of Accenture: "I'm totally torqued at them. Now, if there's any good that can come of this, it is that we are now learning all of the things we should never do when we write contracts."
On a related note, I recommend reading "10 Important Questions to Ask before Signing your Cloud Computing Contract."
Being Transparent and Realistic
As early as 2011, ARiSE researchers noted significant problems that only worsened over the years. The records detail how state officials – under Abbott’s chief of child support, Charles Smith – failed to hold Accenture accountable as the project missed major deadlines and morphed into an overly complicated tangle of hundreds of software bundles.
Records show that each time a deadline was about to be missed, state officials simply extended the timeframe (this occurred on at least seven occasions). Officials in the Child Support Division referred to this as a “re-baseline” – a maneuver that obscured the project’s failings, increased costs, and delayed completion.
For more insights on this topic, please see "8 Signs of Troubled Projects for Project Sponsors."
Executive Sponsorship
In many companies, these projects tend to fall under the category of “group responsibility.” Extending this thinking to, say, an incoming Attorney General, it is easy to pass the buck ("Oh right, that project that was led by my predecessor").
Every software project must have a competent director who owns it and is responsible for both the successes and failures from idea phase through to completion. Without end-to-end managerial involvement, today's business software projects are doomed to whole and half failures. Anyone who does not understand this would do well to postpone new projects.
See "Successful Projects Need Executive Champions" for more on this topic.
Be a Responsible Buyer of Technology
In any organization, it’s crucial to buy technology and implement services responsibly, not to mention work well with suppliers. More than any other factor, projects fail because these skills are lacking.
While some people may argue that suppliers should have all the skills that are required to make a company’s project a success, that’s a matter of wishful thinking or good luck. Responsible buyers are capable of spotting when a supplier and/or the product is failing, and can mitigate risks by taking decisive actions.
For more insights on this topic, I invite you to read "Be a Responsible Buyer of Technology."
Closing Thoughts
At the time of writing, state workers are still clinging to their "quick reference cards" to input acronyms and fill in their client's personal information. They wait in limbo for the system that was supposed to help them get rid of paper files, access services remotely, and benefit from automated prompts and the ability to generate drafts of court filings. These employees and American taxpayers are the real losers in this debacle.
Free Project Complexity Assessment
Other Project Failure Case Studies
References
> Overview of the Texas Child Support Enforcement System 2.0, February 2019
> Legislative Appropriations Request for Fiscal Years 2018 and 2019
> Legislative Appropriations Request for Fiscal Years 2020 and 2021
> Paxton drops contractors on tech project that's $107 million over estimated cost
> After $367.5 million, Texas gets no new child support computer software
Sunday, October 18, 2020
- Labels: Leadership, Strategy Execution, Technology
The True Cost of Excluding Executives from the IT Decision Making Process
Throughout the past 15 years that I’ve been working as an independent project recovery consultant and interim CIO, I have observed executives’ frustration – even exasperation – with information technology and their IT departments generally. Some of the more common refrains are:
“I don’t understand IT well enough to manage it.”
“Although they work hard, my IT people don’t seem to understand the very real business problems we’re facing.”
In fact, the complaint I hear most often from CEOs, COOs, CFOs, and other high-ranking officers, is that they haven’t reaped the business value of their high-priced technology. Meanwhile, the list of seemingly necessary IT capabilities continues to grow, and IT spending consumes an increasing percentage of their budgets.
So why is this happening, and what can you do to prevent it?
Though it may come as a surprise, one of the most effective measures you can take is to ensure a senior business executive plays a leadership role in a handful of key IT decisions. I say this because when business executives hand over their responsibility for these decisions to IT executives, disaster often ensues. You need look no further than my project failure case studies to see the sheer number of botched adoptions of large-scale customer relationship management (CRM) and enterprise resource planning (ERP) systems.
It would be easy to assume that the CRM and ERP disasters resulted from technological glitches. However, the problems generally occurred because senior executives failed to realize that adopting the systems would create business challenges – not just technological ones.
To be clear, IT executives are the go-to people for numerous managerial decisions, including choosing technology standards, advising on the design of the IT operations center, providing the technical expertise the organization needs, and developing the standard methodology for implementing new systems. But an IT department should not be left to their own devices to determine the impact these choices and processes will have on a company’s business strategy.
In an effort to help executives avoid IT disasters, and, more importantly, generate real value from their IT investments, I have made a list that outlines the measures they should take and the decisions they should oversee. Whereas the first three bear on strategy, the latter items relate to execution. At the risk of a spoiler: IT people should not be making any of these decisions, because, in the end, that’s not their job [or their area of expertise].
1) How much should we spend on IT?
Given the uncertain returns on IT spending, many executives wonder whether they will reap the benefits of their investment. So the thinking goes: If we can just get the dollar amount right, the other IT issues will take care of themselves. For this, they look to industry benchmarks to determine “appropriate” spending levels.
In my experience, they should be approaching the question very differently. First, executives should determine the strategic role that IT will play in their organization to establish an organization-wide funding level that will enable technology to fulfill their objectives. After all, IT goals vary considerably across organizations – from streamlining administrative processes to feeding a global supply chain, providing flawless customer service, or cutting-edge research and development.
Clearly, fulfilling these objectives requires different levels of spending, planning, and administrative oversight.
2) Which projects should be funded?
I’ve seen relatively small companies with 100 IT projects underway. Despite the fact that they are not equally important, executives are often reluctant to make choices between the projects that will likely have a significant impact on the company’s success, and those that will provide some benefits but aren’t essential.
Leaving such decisions in the hands of the IT department means that they will be the ones prioritizing business issues, or, just as troubling, they will attempt to deliver on every project a business manager regards as important. When presented with a list of approved and funded projects, most IT units will do their best to carry each of them out. But this typically leads to a backlog of delayed initiatives, not to mention overwhelmed and demoralized staff.
3) Which IT capabilities need to extend company-wide?
Business leaders are increasingly recognizing the significant cost savings and strategic benefits that come with centralizing IT capabilities and standardizing infrastructure throughout an organization. Leveraging technological expertise across a company enables cost-effective contracts with software suppliers, just as it facilitates global business processes. On the other hand, standards can restrict the flexibility of individual business units, limit the company’s responsiveness to diverse customer segments, and give rise to strong resistance from managers.
When IT executives are left to make decisions about what will and will not be centralized and standardized, they typically take one of two approaches. Depending on the company’s culture, they either insist on standardizing everything to reduce costs, or they grant exceptions to any business unit manager who raises a stink (recognizing the importance of business unit autonomy). Whereas the former approach restricts flexibility, the latter is expensive, limits business synergies, and drains human resources.
It’s worth keeping in mind that, in some instances, using different standards can be counter-productive – resulting in a corporate IT infrastructure whose total value is less than the sum of its parts. Knowing this, executives must play a lead role in weighing these crucial trade-offs.
4) What IT services do we really need?
I’ll get right to the point: An IT system that doesn’t work is useless. Reliability, responsiveness, and data accessibility come at a cost, but that doesn’t mean every system must be wrapped in gold. Ultimately, executives must decide how much they are willing to spend on various features and services.
For some companies, top-of-the-line service is non-negotiable. As a case in point, investment banks cannot afford to engage in a debate over how much data they would be willing to lose if a trading system crashes. They require 100% recovery. Similarly, Cloud providers cannot compromise on response time or allow for any downtime, because their contracts penalize them when their system becomes unavailable. This not only incentivizes the provider to ensure that their services will continue to run despite floods, tornadoes, power outages, and telecommunications breakdowns, it gives the client peace of mind and justifies higher costs.
Granted, not every company is a Google or a Goldman Sachs. Most can tolerate limited downtime or occasionally slow response times, and they must weigh the problems this creates against the costs of preventing them. Once again, decisions concerning the appropriate levels of IT service need to be made by senior business managers. Left to their own devices, IT units are likely to opt for the highest levels – i.e., Ferrari service when that of a Ford will do – because the IT unit will be judged on such things as how often the system goes down.
5) What security and privacy risks are we willing to accept?
Like reliability and responsiveness, companies must weigh the level of security they want against the amount that they are willing to expend. In doing so, there’s another trade-off to consider: Increasing security involves not only higher costs but also inconveniences users. As global privacy protections are increasingly mandated by governments, security takes on a new level of importance because well-designed privacy protections can be compromised by inadequate system security. Executives must assess these trade-offs.
Bear in mind that many IT units will adopt the philosophy that absolute security is their responsibility, and thus deny access anytime safety cannot be guaranteed. They would do well to float that idea by a bank’s marketing executives, who are counting on simplified online transactions to attract new customers.
6) Can we assign blame when an IT project fails?
Finger-pointing often ensues when teams fail to benefit from new systems. There must be something wrong with the IT function in our company, they presume. More often than not, there is something wrong with the way that non-IT executives are managing IT-enabled change in the organization.
I invite you to reflect on the well-publicized examples of ERP and CRM initiatives that failed to generate quantifiable value. Invariably, the failures resulted from assumptions that IT units or consultants could implement the systems while business managers went about their daily tasks. The bottom line is that new systems have no value; they derive their value from new or redesigned business processes.
Quite simply: To avoid disasters, executives must take responsibility for realizing the business benefits of an IT initiative. These “sponsors” need the authority to assign resources to projects and the time to oversee the creation and implementation of their projects.
This includes scheduling regular meetings with IT personnel, organizing training sessions, and working with the IT department to establish clear metrics for determining the initiative’s success. Such sponsors can ensure that new IT systems deliver real business value.
In a nutshell: one of the most effective measures you can put in place is giving senior business executives a leadership role in a handful of key IT decisions.