Five reasons business process improvement projects fail

Even with the best of intentions, even the most sought after business process improvement project can fail. Here are five reasons this happens and some advice for CIOs that want to avoid such failure.

Many CIOs have found or are looking for opportunities to elevate their departments to "business enabler" or "business multiplier" status, with all the rights and privileges therein.  These rights and privileges often include increased respect from business partners and, even if the IT budget doesn't fully escape the axe, a better understanding for the potential impact of such cuts.

Many of these efforts take the form of business process improvement initiatives designed to improve the efficiency of existing work, which could mean having that work take either less time, less money or both.  In many organizations, CIOs and the IT department are well positioned to take the lead on such efforts.

Unfortunately, even with the best of intentions, even the most sought after business process improvement project can fail.  Here, I will outline five reasons that these efforts often fail and provide some advice for CIOs that want to avoid such failure and see their projects succeed.

Lack of support from the top

Regardless of organizational size, attempting to initiate a significant process improvement effort without clear, direct and publicized support from the top will more than likely result in either total failure of the initiative or the eventual outcomes not being everything that they could be.

Lack of support from the top can be perceived by staff as the initiative not being important and not being deserving of the full time and effort that is required to ensure success.  Business process improvement projects can be difficult, so reinforcement from the top that the efforts are necessary and appreciated is critical to the team's success.

Mitigation: Get clear, public support for the overall initiative before starting any work.  Get real support, too, not just words.  Ensure that the leadership team is truly ready and that they won't simply back down when the going gets tough.

Organizational culture

I've been in organizations in which the culture itself made process improvement efforts extremely difficult.  In short, for pretty much any task, individual employees were empowered to simply opt out or refuse to take part.  Given the process improvement efforts have the potential to sometimes uncover individual weakness or group challenges, it's not a surprise that there may be some angst when improvement efforts are undertaken.

In one organization, I was stunned to discover the kinds of items that people could simply refuse to do, seemingly without repercussion.  In that environment, the process improvement efforts were extraordinarily challenging and required much more dedication and time from the project leadership team than I've seen in other efforts.

In another example, for a substantial process improvement effort, a VP had promised access to certain members of her team for a period of months with a verbal promise that no other significant objectives would be put before those people until our efforts were complete.  As you may have guessed, that promise did not hold and the team was pulled in too many different directions, resulting in failure since no one would budge on the due dates for any initiative.

Mitigation: In these environments, take a slow, measured approach to the initiative and make certain that leadership is squarely on board before proceeding.  Ensure that the importance of the project trickles throughout the organization.  Consider tying awards or some kind of compensation to outcomes to ensure reasonable participation.  Further, get all commitments in writing along with fallback dates that are automatic in certain conditions, such as when a team member falls ill or when a promise is not kept.

Non-cooperative team members

In some cases, organizational culture is to blame for the failure of some efforts and for the shortcomings of some members of the team.  However, when the organization itself is sound, you may have a team member that is either hostile or less than engaged in the overall effort.  Because the team is theoretically comprised of those with a stake in the process being discussed, everyone needs to be fully involved in order to get the best results.

Mitigation: Find out what's behind the hostility.  If your organization starts the process improvement efforts with the hope that some people can be downsized as a result, don't expect a lot of cooperation from the individuals whose jobs may be at stake.  Further, if you've decided to undertake a BPI project to correct a personnel situation rather than dealing with the personnel situation directly, expect failure.

Project team is not representative

If you want to see what failure truly looks like, attempt to reengineer a process without ensuring that all of those with a stake in the process are represented during the effort.  Perhaps the most important task is selecting the team that will work on the project.  All stakeholders, from start to finish, need to be represented.  Even if a person has just a small part in a large process, the insights and experience from each individual part of the process must be understood in order to improve it.

Mitigation: Easy!  Be inclusive, even if you're inclusive to a fault.

Initiative is too IT-focused

Although CIOs may be well suited to lead process improvement efforts, the outcomes may not be about technology at all.  Bear in mind that IT plays a supporting role in a company's process efforts; it's not all about IT.  What is important is leveraging technology assets in ways that optimize a company's efforts.  If the process discussion is slanted to a point where it looks like IT is taking over the process, you will end up with one of two scenarios: 1) Failure or 2) IT being saddled with "responsibility" for everything that happens in the organization.  Neither is desirable.

Mitigation: CIOs need to wear their business hats when leading process improvement efforts.


Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...


If you or the lead know the project will fail, why change ? the reason simply show that you have no ground to make the change, so how will it be successful ? no matter how many years of experience you have and millions of methodologies, a failure is a failure. The more IT lead, the more problem will occurs, try to put a non-IT staffs to work as IT that gives you more problem then it solve, beside IT should just be a department that helps business to apply and advice. Not and never be the one to make decision. I still prefer they call it Computing, so you only need to concentrate on computer stuffs not the business decision.


Ive been at this 30 years and the story has not changed. Fundamental mistakes will always end in failure.

Tony Hopkinson
Tony Hopkinson

those projects labelled as Business Process Improvements. You could say the same about any change to any part of a business where there's a significant lack of buy in across the business. It was the CIO's fault? Really? It was IT's fault, really? Substitute any top boy and their department. That could only be true, if there despite there being no buy in, and because there was no oversight, IT went off on one. Or if the resources were inadequate, or became inadequate and that wasn't recognised because there was no oversight, IT started and or kept going. Or if the bunch of incompetents that were hired because they were cheap, were unfamilliar with the term scapegoat. Alignment isn't IT employing psychics to try and figure out where the business will want to go despite not knowing they will yet. It's recognising that we are one busines, one team, with one goal, and if we don't communicate (takes two !!!) , we'll both be scoring at the wrong end. Another consultant telling business leaders what they want to hear, not what they need to. Still you get paid that way eh?


The problem is that management calls for it, IT in good faith builds it and by the time it hits the ground it's doomed for failure. Let's be honest most people in management have no clue about life at the operational edge and make assumptions about what the world looks like. A gentleman called Von Clausewitz once said the best laid battle plan does not survive first contact with the enemy. It's the same for IT. You have to build from the bottom up and you have to stay flexible. You can't build perfect. First fix the main problem then tweak until as near to 100% as possible. It's not a build once and done, it's a constant process of adjustment to meet changing conditions.

sissy sue
sissy sue

"If you want to see what failure truly looks like, attempt to reengineer a process without ensuring that all of those with a stake in the process are represented during the effort." That pretty much sums up what I've seen at this organization. The requirements were written by those who had a superficial understanding of the process and who used it only rarely or who filled in when the subject matter expert was on vacation. One subject matter expert was not consulted at all, and a hardcopy of the requirements was thrown on her desk after the fact -- she wasn't even privy as to where the electronic copy was located and had never been invited to any of the planning meetings! The other subject matter expert was consulted for 15 minutes tops. Needless to say, when the project moved to UAT, it was a absolute disaster. It was at this point that one of the subject matter experts was pulled in, only to find that the process was totally unsuitable. After having spent thousands of dollars, the organization pushed the project onto the back burner for retooling and then months later made a second attempt, still using much of the code from the first try. The process "works" now, with a myriad of workarounds and hands-on management required. If this organization didn't have big pockets, someone's head surely would have rolled for such mismanagement. After having participated in this fiasco, anyone can readily understand why this IT organization's internal applications are absolutely terrible.


In my experience; even in technology-lead businesses, IT Departments very VERY rarely take the lead in process improvements / modifications. Such organisational changes are ususally driven from the very top-down from requirements sent from individual departments. Think about a sales team's requirements for faster processing of new orders. Do they go to the IT department to ask for a copy of ABC Processing Inc.'s latest off-the-shelf software? No, they route their request up through the ranks to ensure that their request fits in with the business' overall key objectives, financial plans, current / planned processing and organisational structure etc. When that sales team changes the way they manually process orders and create delays as a result, the MD / CEO will undoubtedly ask "Why the hell was the IT department leading the change in one of our core processes"? Why is this? Because the IT Department (perhaps CIO-centric) are not the sales specialists of the organisation, the sales team itself is. Change, in a well-structured organisation, comes from the top; from real leaders. This, of course, is the case regardless of the department requiring process modification and I only use sales as an example. CIO Leading process change? If thats what happens in organisations you're familiar with, then the top ONE reason such projects fail is because they were given to the wrong person to lead. Want a SUCCESSFUL technology solution? Follow these simple steps: Business Requirement Technical Specification Technical Solutions Business Acceptance User Acceptance Testing Business Acceptance Deployment Review Review Review Business Sign-off Funny, but I think you may also find Prince2 helps in managing projects PROPERLY.

Editor's Picks