Failure Rate ] Failure Causes ] Project Specificities ] [ Success Assessment ] Failure Examples ]
  Success Assessment
Where is the limit between success and failure ?

For it is your business, when the wall next door catches fire.

Horace Epistles

About Us
Core Tenet
Consulting Svcs
Project Recovery
Web Development
Contact Us
Site Map



When asked to define project failure people generally answer that a project fails when it is not delivered on time and within budget. Keener people will add that a project also fails when it falls short on meeting its original expectations (be they expressed in terms of functionality or business edge). But, is this the end of the story ? Are these absolute and complete failure criteria ?

Where does the responsibility over project failure start and end ? A project is never a closed system and consultants love to work with closed systems. Their business could even be summarized with the motto : "bringing order and clarity into closed organizational systems". Unfortunately businesses or public institutions or projects are everything but closed systems : they are open to all sorts of external influence, unexpected events, unstable conjuncture, ever-growing requirements, changing constraints, fluctuating resource flows, reshuffling of power among the stakeholders. The natural trend of large projects or business endeavors is not toward order and clarity (see our comments over the complexity drivers in large organizations). On the contrary, one meets the devil by diving into the operational details. The willingness to "close the system" is a consequence of the reductionist approach that most consultancies tend to follow whereas IT Cortex emphasizes a holistic approach which alone can yield total success. 

The following considerations broaden the list of criteria defining the success at large. They also stretch the perspective from which any attempt to improve business efficiency should be addressed and, ultimately, they demonstrate that IT Cortex Strategic Simplification targets project success in its broadest possible sense.


If IT projects have a definable lifecycle their product, or result, are never final. They keep on evolving. When an IT application has been developed and handed over to the exploitation team or packaged for commercialization, it will not only have to be further maintained but it will also have to be enhanced, extended and adapted to new or changing platforms. In the IT world there is no such thing as a final product. The only way to make it final is to dispose of it. Developers keep adding features, functions, capabilities. Just think about the differences between the first version of your favorite word processor, spreadsheet, exploitation system and the one that you are currently using. IT products do evolve but some IT products evolve better than others. The growth, or evolutionary capability, of an IT application is an essential aspect of its quality and its value. Some IT applications reach very quickly their limits : they can not be further extended, enhanced, generalized (mostly for architectural reasons) whereas others have been so well designed at their outset that they are open to (almost) any extension or enhancement. The primary reason why legacy systems are replaced is that they have reached their evolutionary limit. So, what is better : an application that has been developed on time and within budget but whose further evolution will be hampered by its built-in limitations or an application whose development was over time and over budget but that has outstanding growth and evolutionary capabilities (and whose full life will consequently be much longer even if unplanned investments are required at the outset) ?

An IT project can also fail by lack of growth and evolutionary capabilities of the solution it delivers.

Consequence : Success or failure of a project can not be determined at one single point in time but over the full life of the solution delivered by the project. The project success criteria extends therefore beyond the life of the project.

bulletIT Projects are no goal "per se". They are not launched for the sake of getting an outstanding piece of IT engineering. They are not built by dilettantes for the sake of achieving technological excellence. IT projects must have a business value. Even if the final solution could be specified to the slightest detail and precisely budgeted at the outset of the project, the business value of that project would still be largely unknown. Budgeting a project - although very difficult - is much easier than forecasting the business value of its delivered solution over its full lifecycle.

Consider, for example, the case of a project that goes way above budget, is delivered much too late but, all in all, turns out to be a very profitable investment (yes, that exists). Would you speak of failure in that case ? Alternatively, take a project that finishes on time, within budget and delivers the specified functionality. Unfortunately that project turns out to be a dreadful investment (yes, although rarer, that also exists). Would you speak of success in that case ?

Your answer will probably differ depending on your role in your organization or on your contractual status. What ultimately matters is the added value of the project deliverables to the business. 

An IT project can also fail by lack of business sense.

Consequence : The overall project profitability is a much more relevant success criteria than the strict respect of the initial budget. Estimating the overall profitability of a project at its inception is even harder than estimating the budget of a to-be-delivered solution. Does this P&L responsibility falls within the project team and how far does the project team stretches ? Who is in, who is out ? For large and strategic projects all key functions within an organization might be in, so the project becomes congruent with the whole business.

bulletIT projects are never isolated from their organizational environment. IT projects are made for end-users and not "in spite of" end-users. On the other hand, end-users should never expect IT to solve problems that they can not solve themselves (like organizational issues or to compensate for the lack of professional skills). The synergy between the IT functionality and the business model is always a crucial success factor. If an IT application is not an intrinsic part of its business environment it will inevitably fail to meet its expectations. The adaptation effort has to be bi-directional: an organization has to adjust itself to host a new and comprehensive IT application and an IT application has to be designed according to the needs and capabilities of the organization for which it is destined. Consequently, if the decision has been made to reengineer or replace a legacy IT application a concomitant and parallel decision needs to be made to reengineer the organizational environment. Addressing organizational issues is not less important than addressing technical issues.

An IT project can also fail by lack of integration with its business environment.

Consequence : The integration of an IT application into its business environment should get as much attention as the technical capabilities of the solution delivered, thereby making the boundaries of the project reach far within the business organization.

bulletProjects always involve a significant amount of learning, even for the best professionals in the area where the project takes place. By essence, no project is a routine. Not everything about its size and scope is therefore known at its inception. But its budget, deadline and overall objectives are always set prior to its start. They are indeed the traditional requirements to get the project go-ahead. So, if a project goes over budget, over time and falls short of its expectations, who is to blame ? Those who have set its budget, deadline and requirements or those who have not been able to meet them ? As everybody realizes, it is much easier to set objectives for others than to have to meet oneself objectives that others have set. Moreover those who set objectives wield usually more power than those who are assigned to meet them. But, on the other hand, objectives have to be set - even dynamically .... and met - even dynamically (i.e. as the project goes along). No project manager should ever get a blank check or an open-ended budget. The challenge is to achieve consistency between initial requirements and final solution. This alignment is both an ongoing effort (as opposed to a one-time shot) and a joined responsibility between the project sponsors and the project team.

An IT project can also fail by lack of consistency between its means and its objectives.

Consequence : No project has an absolute and predefined measure of its success (since initial budget, timeframe and expectations are all but best guesses produced when not much is known about the project)

As one can infer from the above considerations, there is no clear-cut boundary between success and failure, just a very large grey area. Moreover, the period over which the success of a project should be evaluated has no clear limit in time and in space. The evolutionary capabilities of the delivered solution extends the project repercussions in time and the organizational integration makes the IT project boundaries fuzzy in space. Project components can not be isolated and addressed individually. The whole is more than the sum of its parts.

This all points out toward the need to address IT and organization in a holistic manner: as an integrated whole taken within its business environment. This is the perspective that IT Cortex systematically takes to assist you in achieving a healthy and growing business.

These additional failure criteria also emphasize how universal IT Cortex strategic simplification is. It addresses and meets all four additional success criteria listed above.

  1. It delivers a clear, efficient, well structured, well designed business solution that can grow along with the streamlined business.
  2. It is the epitome of business sense.
  3. It ensures perfect synergy between the project and its business or public environment. 
  4. It aligns the means and the objectives of the project.

IT Cortex warmly recommends that you resort to its business pre-automation service before you embark on a always high risk, high stake business automation project.

IT Cortex

Failure Rate ] Failure Causes ] Project Specificities ] [ Success Assessment ] Failure Examples ]