EA Voices – Page 724 – Aggregated enterprise architecture wisdom

Everything you’ve read about IT Project Failure is wrong

December 10, 2012 by Nick Malik

I did a scan around the web to figure out what many of the leading thinkers were saying about IT project failure and the root causes. Numbers varied between 20% and 80% of projects failing to deliver on their business case. The root cause analysis that follows from these failure numbers spends a lot of time looking at the IT project, but most forget to look at the causes of failure that are outside the project’s control.

In the diagram below, the central blue box represents causes of IT project failure that are inside the control of the IT team. As you can see, there are many more causes of IT project failure that are OUTSIDE that blue box than inside it. Yet, countless articles have been written on the factors INSIDE the box. I think it is time we take a slightly wider lens to the problem!

The factors outside the project are as important, or more important, than the ones inside the box. I have worked on many projects over the years, and if I look back at the ones that ended up cancelled or scrapped, the reasons were not ones in the blue box. They were usually ones from the top box: where the project should not have begun in the way that it did. Let’s look at these six factors:

Lack of accountability for success – Sometimes, in an organization, an interesting situation will arise. I call this the “can’t lose” scenario. In this scenario, the CIO will suggest that the business can benefit by doing some particular initiative, and his or her people will set out to find a business sponsor for the initiative. In this case, the sponsor will reap the benefits of the initiative, not the CIO. (Let’s say that the CIO has suggested a Business Intelligence initiative, and signs up the Chief Marketing Officer to sponsor it). If the project succeeds, the sponsor wins. If the project fails, the CIO (not the sponsor) loses credibility. After all, it wasn’t the sponsor’s idea. The CIO dreamed it up, after all. In fact, the sponsor may not do any real “sponsoring.” He may sit in an occasional status meeting and check his e-mail while the program manager he assigned from his team answers questions… and keeps him protected from any blowback. The sponsor in this case is not accountable for success. No one is. The odds of this project succeeding are small. (Note: a good IT Governance system prevents this condition).
Failure to get buy-in from above – Often, a senior executive will ask his operational leaders to suggest IT projects for the planning cycle. The executive (let’s say Tina Smith, Vice President of Sales) assumes that the leaders (William, Ashok, and Lee: all three are General Managers) will ask for projects that align to their individual strategic needs. One of those General Managers, William, decides to create an IT project to implement a SOA service bus. He wants the bus because he is investing in replacing an application and his IT team tells him that a bus is a good idea. After all, if everyone in the Sales group uses it, everyone will benefit. But William doesn’t get Tina Smith’s buy in. He implements his SOA service bus, but when subsequent IT funding requests come up to move other sales applications over to the bus, his peers Ashok and Lee are not interested. Their priorities don’t include moving to the bus. William bought a white elephant. Because he didn’t get Tina’s buy in, none of his peers will reap the benefits. Is the SOA bus a failure? Well… it’s not a success.
Misaligned prioritization – Lee James, General Manager of Sales for the Western region of Contoso owns a sales strategy for the enterprise. The strategy is to make the sales force more productive by moving the company over to a new CRM system. The CRM system has out-of-the-box support for a long list of reports, but his team tells him that he shouldn’t use those. Instead, he should put in a Business Intelligence system in the cloud. Lee wants to trust his team to pick the right solution. They tell him that the cost of this system is $4 Million over two years. The company is moving to a new strategy that de-emphasizes the direct sales force. Instead, the company will be relying on social networking and direct eRetail to make sales. To make the new strategy work, there are eight projects totally $8 Million that need funding. There is a competition for dollars in the IT budget. Lee goes to bat for his $4 Million commitment. It’s important because “we are already here, so we have to complete the job.” This is an example of misaligned priority. The new BI project can be safely cancelled or scaled WAY back to support a strategy elsewhere, but that other strategy doesn’t belong to Lee. The one that he owns needs money and he’s going to keep fighting to fund it because his boss, Tina Smith, isn’t aware of the tradeoff. Lee fights, and Contoso loses. Which project will fail? Both of them.
Slow decision making – This one is related to the other problems in that it is often, but not always, caused by a poor governance system or poor prioritization of the effort. In this scenario, the team implementing the project needs the sponsor to make a decision, often one that requires consultation with his or her peers or counterparts in another part of the company. The sponsor may be unwilling, unable, or incapable of having a difficult conversation. On the other hand, they may be indecisive. Regardless, this situation can cause serious delays in a project. For example, Ashwin’s application sends EDI-formatted messages to a health insurance provider. The provider had indicated that new fields are allowed in the messages that are very valuable to Ashwin’s line of business. However, he has to upgrade his EDI translation software to get the new fields. The EDI translation software is also used by the Finance group to send banking transactions. Ashwin knows that the finance group will get a benefit out of the upgrade and wants them to help cover the costs. This upgrade will add $25,000 to the cost of his project and he’s on a tight budget. The software team offers to write a small component that will insert the fields into the data stream, but its complicated and fragile. Ashwin cannot decide if he should ask the finance team for funding or if he should upgrade the software. The project team cannot proceed without a decision.
Lack of authority to drive change – This one is quite common. Ashok reports to Tina Smith, VP of Sales for IBuySpy. He has told her that he wants to take the lead on one of her strategies: to consolidate all of the eCommerce systems in the company to a single outsourced vendor. Tina things that this will reduce costs all around, and Ashok is happy to take on the challenge. His business analyst does a survey and it turns out that the services and support team offers customers the right to buy replacement parts online. In addition, the “outside services” team allows customers to buy a service contract on their own area of the website. The main sales site, of course, uses a high-volume low-cost vendor that Ashok is comfortable with. Ashok sets up meetings with the owners of the other applications, but they choose not to provide the needed transaction cost information or the cost estimates of changing their internal systems. His data is light but he strongly suspects that there is a good business case for switching. Unfortunately, he doesn’t have the data to prove it. Without data, the Tina won’t take the case to the CEO to require the other teams to jump onboard. The strategy fails. Neither Ashok, nor his manager Tina, have the authority to require their peers to adopt a lower cost system.
Lack of influence to rally peers – In many organizations, the prevailing attitude is that the boundary between “centralized” services and “federated” services is intentionally fuzzy. In these companies, there is no policy that requires a function to be centralized vs. federated. For example, if a company has ten divisions, three may have their own financial processes, while the other seven share a common finance unit. The decision to use the central finance unit, or to own a federated unit, can be made and unmade depending on who the leaders of the business are. (Note: leaders change, and with them, these decisions change as well). This kind of policy is good for flexibility, but creates both inefficiencies and often, confusion. This is simply a tradeoff in the design of organizations. It is neither right nor wrong. In this environment, any business can create a “centralized” function by convincing more than one business leader to come together to create a shared resource. The flaw comes when a group wants to create a “centralized” (or simply “shared”) function, but they lack the influence needed to get multiple businesses to join the initiative. Difficult questions of shared funding can be demotivating, and the political need to create “alliances” can be difficult for junior executives that, in many ways, are competing with one another for the next rung on the career ladder.

Each of these conditions has the potential to kill an IT project. I would suggest that MANY IF NOT MOST of the failures of IT projects can be traced to one or more of these conditions, but these conditions rarely get counted in the statistics for “Causes of IT Project Failure.” Why? Because, in most cases, projects that suffer from these conditions are either never funded, or are reworked so that the political problem is simply avoided. The project business case does not reflect the problem, so the criteria for failure (doesn’t meet the business case) is never met. Efforts are made to avoid (but not address) the problem before the business case is written!

This is the world of the Enterprise Architect. These are the kinds of “failure” that fill the eyes and ears of an Enterprise Architect. If an EA focuses on only these six causes, he or she will deliver real, tangible, and unique value to their enterprise without ever overlapping the roles and responsibilities of an IT architect, business analyst, or technologist.

Co-Production of Strategy and Execution

February 28, 2013December 9, 2012 by Richard Veryard

#antifragile In my post
Structure Follows Strategy?, I discussed the reciprocal relationship between strategy and structure, and discussed my friend Patrick Hoverstadt’s mission to connect enterprise architects with the strategy processes in an enterprise.

My thoughts about strategy are influenced by Mintzberg, who
sees strategy formulation as an emergent process of trial and error that
takes place during implementation. A company may start with a
broad-brush deliberate strategy, but this strategy often overlooks some
significant issues and risks.

These weaknesses need to be addressed as
part of the execution of the strategy. Thus a more complete and correct
strategy emerges out of the execution process.

Senior
management sometimes take a long time to recognize and acknowledge the
fact that the defacto (emergent) strategy is now better than the
original (deliberate) strategy.
And in some companies the original strategy is so bad, and the
senior management so pig-headed, that there is little chance of a more
sensible strategy emerging.

In order to see strategy and execution as co-evolving, we need to link both strategy and execution to outcomes. If the outcomes turn out unsatisfactory, it is surely a subjective
judgement whether this is blamed on weak strategy or weak execution. And if the overall outcomes turn out to be satisfactory then we may suppose that any weakness in strategy was compensated by excellent execution, and any weakness in execution was compensated by brilliant strategy.

This of course depends on our notion of excellence. Some people might think that perfect execution means doing exactly what it says in the strategy, no more or less. Alternatively, we might define excellence in terms of achieving the best possible outcomes, thus excellent execution may need to depart from the official strategy if that’s what it takes.

Which brings me to Nassim Nicholas Taleb’s notion of antifragility. If fragility means that something is harmed when bad things happen, antifragility means that something becomes better or stronger when bad things happen.

So let me try to apply this notion to the current discussion. A fragile strategy is one that would fail if there are any deviations in execution. A robust strategy is one that would be unaffected by the quality of the execution. And an antifragile strategy is one that would grow better with deviations in execution.

Partly based on my contributions to a Linked-In discussion I wonder what the EA team is doing? (One person has deleted his contributions, so the discussion as a whole no longer makes much sense.) See also Fragile Strategy or Fragile Execution? via Storify.

Carole Cadwalladr, Nassim Taleb: my rules for life (The Observer, 24 Nov 2012)

John Crace, Antifragile by Nassim Nicholas Taleb – digested read (The Guardian, 2 Dec 2012)

David Runciman, Antifragile: How to Live in a World We Don’t Understand by Nassim Nicholas Taleb – review (The Guardian, 21 Nov 2012)

Gamification and infinite-games

December 9, 2012 by Tom Graves

What’s the point of gamification? Could it have useful applications in enterprise-architectures? I’ll admit straight off that I’ve never been one for most kinds of games, whether in school-days or anywhen since. I’ve never been able to see much point…

Reflecting on IT service management issues for 2012

December 9, 2012 by Navin Anand

Reblogged from COMMUNICATIONS & MANAGEMENT BLOG: Well as we almost enter the festive season it is perhaps time for reflection regarding the challenges you faced as IT professionals in 2012. I was reminded by a colleague of an article at … Continue reading →

Leveraging Roadmaps to Link Business and Technology

December 8, 2012 by Leo de Sousa

Enterprise Architects have used roadmaps as a standard model to describe the transition from the current state architecture to the future state architecture. Many of my fellow enterprise architects have described the many different ways to create a roadmap and to show how they link to an organization’s strategic goals. Nick Malik (@nickmalik) wrote […]

The post Leveraging Roadmaps to Link Business and Technology appeared first on Enterprise Architecture in Higher Education.

DSM: A useful tool for process improvement efforts

December 7, 2012 by Ming Fai

Design Structure Matrix, or DSM in short, is a tool I frequently see during my year here at MIT. It is often mentioned in “System Thinking” talks, as well as talks on designing complex system. While the DSM’s uses are many, my project team mates and I focused on process improvement and successfully used the DSM to help our sponsor company improve its processes. Our sponsor company is a aircraft maintenance, repair and overhaul business, and the process we focused on was the aircraft upgrading process, which spans from defining requirements for the upgrade, to drawing out the design, to implementation, to testing and finally to delivery.

How the DSM helped

1. Reduce long rework cycles – imagine the nightmare scenario where a project gets to almost completion, and then have to loopback to the beginning for reasons such as a major design error. It is like the chutes and ladders game. The DSM helps to reduce long reworks by reordering the tasks. For example, in our project, initially there were four rework cycles that would set the project back by more than 20 tasks. After the reordering, there were none.

2. Challenge the status quo task ordering, while respecting task dependencies – in the reordered task list for our project, we realized that a number of documentation tasks were pushed to the bottom of the list. These tasks dealt with the development of internal test reports, flight manual and maintenance manual.

Initially, we thought that meant that the company should do those documentation tasks last. However, on investigating further, we realized it was because no or very few other tasks depended on those tasks. We thought about that further, and a revelation hit us: if no other tasks are waiting on those documents to be developed, does that mean that employees could develop those documents late and to the lowest quality but yet not affect the entire process in any way? How can the company ensure the timeliness and quality of those documents? Our sponsor validated that concern, and in the end, we recommended adding sign-offs of those documents to resolve this issue.

This is just one of the many examples. The DSM challenged the status quo task ordering, in a way that respected the task dependencies, so the new ordering still made sense and provided ideas for how the current process might be done better.

3. Facilitate understanding of the current process
The DSM creation process required us to get our hands dirty into understanding the process. We needed to think about what level of granularity we need to get down to, and what kinds of dependencies we should capture. These activities helped us think more about the process, and thus added in our understanding.

In addition, the DSM also provided a visual map of the process. At one glance, we could see which are the tasks that have many dependencies.

Additional Information about the DSM

For readers interested in finding out more about the DSM, I have included some basic information here.

DSM might seem rather technical and intimidating at first glance. And that fear is well justified, as DSMs are matrices, a mathematical artifact that inspire fear into people’s heart by the mere mention of its name. However, if you spend 10-15 understanding how it works, you will find DSM a useful tool to include in your toolbox for process improvement projects.

Creating the DSM

To use the DSM (for the purpose describe in the article), we have to provide three main pieces of information:
1. The list of tasks in the process.  For example, in the design phase, creating the high level design would be a possible task, and doing preliminary design review would be another possible task.
2. The dependencies between tasks.  This information will specify that for Task A to start, what tasks would need to be first completed. For example, preliminary design review needs to be completed first before detailed design can commence.
3. Possible loopbacks.  This indicates scenarios where rework need to happen. For example, after preliminary design review, the proposed design might be deem unsuitable and the project will need to go back to high level design.

These three pieces of information can be visualized in a graph like the following:

Here, the tasks are represented by the boxes, the task dependencies by the black arrows and the loopbacks by the red arrows. This graph is not needed for DSM creation, but is included here to illustrate information needed to create a DSM.

With the required information, a DSM can easily be created. Using the same example, the DSM will look like this:

The DSM contains the same information as provided by the graph, but putting it in a matrix allow us to apply some tools that will help in our process improvement task. Then, to do the task re-ordering, you just need to use a tool to “partition” the matrix. Tools, such as PSM 32 and a DSM Excel Macro, can be found DSMweb.org.

The partitioned DSM will have the new ordering, like the one described in this article. Analysis and recommendations can then be made based on the partitioned DSM.

Credits

This work is not solely of my own. A lot of credits to my team mates Haibo Wang, Davit Tadevosyan and Kai Siang Teo.