Can a Task Force Rescue Your Failing Project?

We’ve all witnessed projects in trouble—the ones that required a quick and firm intervention in need of help from a task force to bring it back on track.

No executive wants to be in such a difficult situation, especially not with one of his or her own projects.

But how do we, as the executive sponsor, handle saving a troubled project? Can it be as simple as mandating a task force?

Let’s start with exploring what a project task force is and when it could be useful. 

A project task force starts with a mandate given by the organization’s project sponsor or senior leadership to an experienced leader with the goal of finding the best option for resolving a particular problem in a very short amount of time.

A task force team is a small group, usually four to twelve people, that brings together a specific set of skills and experience related to the problem at hand.

A task force is a useful management mechanism that should be only used in exceptional situations. It generally requires disrupting other project activities and deploying the best people to solve the problem under possibly highly stressful and energy-depleting conditions.

So how do you handle this? 

I have been part of several task forces and have led a few as well. I have had both good and bad experiences. In order for task forces to be effective, you will need:

A Clear Mandate: It needs to be communicated to all stakeholders that the project is in task force mode, as well as who is leading the task force (see next point). You will need your stakeholder’s help in receiving quick turnaround times on information requests and decisions. You will need the best people in your organization for your task force team, so people need to understand it is urgent and important. 

An Experienced Leader: It can either be a senior project manager or a leader experienced with crises situations. Single leadership is the key to getting the job done! The last thing you would want is having two or more leaders debating how to drive the task force; one person has to call the shots.

An Expert Team: The task force leader will need to quickly assemble an expert team, formed with the best people who have the required field expertise to quickly understand and resolve the problem. The smaller the team, the easier it is for the task force leader to motivate and steer the team towards finding the right solution.

Laser Focus: The particular problem the task force is working on has to be clearly defined and known to the entire task force team. The objectives they will be working on also have to be clear to everyone involved. Several other project issues may come up along the way, thus, to be effective, the task force must remain focused on the specific problem.

Executive Support: At times, the reason a task force is needed in the first place is due to internal politics and resistance to change. One of the worst things that can happen to a task force is that they have no backing from their leadership to cut through this. 

Expectation Management: Many times, a task force can improve the status quo significantly, but you should not expect miracles. Further, you should strive to not communicate your desire for miracles upfront. Make clear to everybody that the goal of the task force is to find the best possible solution under the given circumstances.

A Short Time-Frame: Given the urgency and the high level of the task force team’s energy, they are only effective if conducted in a short time frame (a matter of days, or a few weeks). If efforts go on for longer, it is likely not a task force, as the energy and effectiveness will lower over time.

Simple Logistics: Due to the intensity and possible stressfulness of the situation, task forces require an isolated project space—or war room. This space needs whiteboards to facilitate brainstorming and for capturing the results of the task force (notes, action items, assumptions, decisions, solutions, etc.). Yes, we all learned during COVID-19 to cope with this remotely, and yes, for international teams, it is not always feasible either. But trust me, in a time of crisis, it really works better this way.

Solution Options: The task force’s outcome should include one or more options that lead to a solution to the problem, including a recommendation for the best option. This option, even if it is technically the best that the expert team can recommend, might not satisfy the risk appetite of the person or organization that has mandated the task force. Therefore, every option should also provide the related pros and cons.

Qualified Assumptions: Beware of unqualified assumptions. If the identified options are building upon assumptions that are not fully validated, highlight the risks or needs for confirmation before making a final decision.

A Clear Ending: To end the task force, its leader and the expert team will have to reduce the complexity and summarize the outcome of their work (options with pros and cons, along with assumptions and their risks or opportunities). Ultimately, the task force leader will communicate the outcome, confirm the decided solution, and conclude the mandate of the task force.

If set up and executed properly, a task force can be an effective tool to resolve crises situations in projects. 

Typically, these situations occur relatively late in the project when nothing else has worked. Interestingly, they usually work relatively well, as they are given the highest priority. 

Due to their ability to solve such issues, task force leaders are often celebrated as heroes. 

But task force teams work only at the expense of all other projects! All other projects endure even more pressure and are good candidates for further task force teams. Thus, they should be deployed wisely.

In a nutshell: A task force can be an effective tool to rescue failing projects if set up and executed properly.

Read more…

How a Transformation Office Can Help Your Transformation Initiatives Succeed

A new year has just started, but also in 2021 companies will be talking about digital transformation often. I think digital transformation is a terrible description for what is just another transformation. See my article “Digital Strategy Does Not Exist” on why that is. 

But we shall use the term for a moment to analyze the situation. Digital transformation is nothing new. It is a daily reality for all companies. Some are the disruptors and others are disrupted. And Covid made this even more clear. 

All understand that digital transformation—not evolution—is required to maintain a competitive edge. That is why so many digital transformation initiatives have been started around the world. 

But it seems that 70 percent of all digital transformation initiatives do not reach their goals. In 2018, of the $1.3 trillion that was spent on digital transformations, an estimated $900 billion went to waste. [1] 

Companies need to shift their approach to ensuring they reap business value and desired business outcomes from digital transformation initiatives. Across industries, most organizations are using standardized project management practices such as a traditional Project Management Office (PMO).

But digital transformation requires much more than status-tracking and risk escalation—it requires a robust capability that drives execution with a value-realization focus: A Transformation Office. 

This is not just semantics, not just a lift-and-shift, not just a glorified PMO. It is a truly different undertaking to ensure digital transformations deliver on their promise. 

And the same is valid for any other critical transformation initiatives your organization is planning. Not just digital transformations.

Transformation can take many shapes, from transforming business models to cater to a shared economy to transforming the way that critical services are delivered to clients. 

The Transformation Office

A Transformation Office enables organisations to manage multiple program and project management initiatives towards one common goal. It is more than a PMO with a fancy name – it’s about bringing strategy to life.

The Transformation Office is responsible for driving complex initiatives on both operational structures and the strategy of the organisation. It is a critical link between the executive vision and the work of the organization. 

Some companies call this function a Strategic Implementation Office, while Gartner refers to this as a Strategy Realisation Office. 

Regardless of the name, one element that sets a Transformation Office apart from most PMOs is that the C-suite proactively supports the Transformation Office’s mandate to transform the organisation entirely, which ensures it has the highest priority when implementing and affecting change.

They will be the strategic architect working with the CEO to integrate and drive and choreograph a transformation agenda. They will have to play the integrator function as well because often if you are driving customer agendas on one part of the organization, cutting costs in another part, going after a digital agenda in a third, all of those will be interrelated, and there will be interdependencies that someone will need to play air traffic controller for.

Core Competencies

The most effective Transformation Offices will house several core competencies necessary for successful transformation, including:

Enterprise Architecture to define an updated or even an entirely new structure for the organisation with which transformation activity can be planned around and clearly communicated to everyone involved. This includes Design Assurance to safeguard its integrity across projects and alignment with the vision set out in the business architecture. This critical role aligns IT and other support functions behind the business design.

Project Portfolio Management including prioritization to ensure investment flows to the highest value initiatives and that the investment method is transparent and collaborative.

Project Management to track, govern and manage the transformation whilst reporting progress.

Change Management to ensure users and other stakeholders adopt the changes that the transformation brings. 

Benefit Realization Management to ensure execution delivers the intended benefits and outcomes, by continually monitoring progress and adjusting to keep the delivery on course.

The Transformation Office not only sets the schedule and the tone of the transformation, but it also keeps score, with consistent ways of measuring and tracking business value. It ensures everyone has access to the same simple rulebook and is trained to understand its unambiguous processes and policies. 

The Transformation Office is a coach to help the organization grow and get better with the responsibility of ensuring that efforts are not stifled by old-fashioned bureaucracy that the company might have become accustomed to.

Single Source of Truth

Any organization undergoing a transformation will have a pipeline of improvements, subdivided into actions, owners, and dollars at stake. An important role of the Transformation Office is to ensure that all participants have a “single source of truth.” A transparent view of what flows through the pipeline and a central record of the progress of each initiative owner.

Tracking and approving initiatives can be done through a structured stage-gate process that goes from initial identification to final realization.

Armed with the truth, the Transformation Office has the credibility to spot potential conflicts or overlaps among work streams, raise the issues with stakeholders in its regular meetings, and work with owners and executives to achieve the best outcome for the business. 

Without this sort of planning and intervention by the Transformation Office to remove bottlenecks, one or two project teams can cost an organization millions of dollars.

Parallel Organization

The Transformation Office exists in addition to the line organization. Now why is that? 

Most organizations rightfully say, "We prefer that the line should just implement the change. The line organization needs to own and embrace the change."

And that's an understandable and very aspirational ambition that you should have for a well-run company. But the reality is that while in a transformation phase the line organization will need to change as well. 

The operating model, the kind of executives you had, the skills in the organization that made them successful in the past may not be the same as what you will need to have in the future. 

And so, as you are transforming the line organization, you will need this kind of office to create a bridge until the newly transformed line organization—the redesigned and transformed organization of the future—can actually inherit the initiatives and operate them smoothly.

In a nutshell: A well-executed Transformation Office can improve your transformation across four areas: value, design, execution and business adoption. Think of the Transformation Office as a risk mitigation insurance policy on your most critical transformation initiatives.

References

[1] Harvard Business Review, "Digital Transformation Is Not About Technology", March 13, 2019

Read more…

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.

Read more…

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.

When you need some guidance on how to define and measure project success have a look at my Project Success Model here or by clicking on the image.

Read more…

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.

Read more…

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

Better Contracts

During a recent hearing, Accenture T2 project executive sponsor, Ben Foster testified to Capriglione's sub-committee that the company "did not deliver the value you expected of us." However, since the 2016 contract amendment gave the company financial "skin in the game," Foster said, "We've made tremendous progress."

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

This assessment will guide you through the 3 dimensions (structural, sociopolitical, and emergent) of project complexity by asking you 38 questions.

At the end of the assessment you will get a score between 0 and 38. The higher your score, the better you have a grip on the complexity of your project. Most questions have detailed feedback with links to more insights on how to handle this part of project complexity.

Other Project Failure Case Studies

> For an overview of all case studies I have written please click here.

References

> Texas Child Support Enforcement System 2.0, Overview of System Development and Project Monitoring & Oversight, December 2015

> Overview of the Texas Child Support Enforcement System 2.0, February 2019

> An Audit Report on The Development of the Texas Child Support Enforcement System 2.0 at the Office of the Attorney General, July 2011

> 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

Read more…

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. 

Read more…