When is a Project Successful ?

A seemingly simple but essential question is when is a project successful? The usual and probably most evident answer is when it delivers on time, on budget and within scope. But is this the right answer?

If the project reaches its objective, it is successful. If not it is a failure. Objectives allow people to work together in a same direction on a same mission. But more than that, people are evaluated on their ability to reach the established objectives.  Rewards are often linked to objectives. Erroneous objectives and a improper reward system based on these objectives may cause a lot of havoc in the company. We shouldn't take it lightly.
First, let's take a closer look at the iron triangle objective.


The Iron Triangle

A project which delivers late or exceeds the budget is not successful. The established time and budget are compared with the project execution. If the comparison is false, then the project is a failure.  

established time and budget   <,=,>?   project execution

If the project isn’t successful, we assume the execution wasn’t right. If the comparison turn out to be wrong, at least one of the two sides of the comparison must be wrong. So what if the project has been executed efficiently and effectively? What if the right side of the comparison is right and the left side is incorrect? After all, time and budget are only estimates. What is more likely to be wrong, the estimates or the project execution, which is the reality? Can we assert the estimations to be absolutely right and the reality to be wrong? Are estimations more important than the obtained results?

 

Time and budget are estimated too low.

The persons doing the estimations are too optimistic. Maybe they wanted to save money. However, thee estimations of time and budget are too low.

The team members may seek to respond to the expectations. They want to preserve their reputation. They want to be evaluated well and get rewards and promotions. Whatever the reason, most team members will do their utmost to achieve the objectives. They will do what is needed to deliver on time and maybe also on budget while respecting the scope, even if the estimations are too low. Undoubtedly, this will put the project under pressure. The lower the estimates, the greater the pressure, unless the estimations are more than ridiculous low.

To be successful, the team has not much choices. It must apply tactics like trusting the demand and information of the business community, working overtime and taking short cuts. Maybe, the product will respect the scope, but it isn’t sure it will be of great value to the business. The demand, the scope, the requirements and the specifications will be interpreted in such a way that the minimum will be implemented to comply with them. Anything that is not specified, even if needed, won't be implemented. The most simple version of the solution will be built. The quality of the product will suffer. The result is a too simplistic, poorly designed solution, having awkward or lacking features. Important characteristics, like configurability, maintainability, flexibility or evolvability will be weak. This will increase the operational cost, as well as the cost of future changes.

The work climate is likely to deteriorate and conflicts may arise between the team members.

Using time, budget and scope increases the risk of problems, increase of cost and/or prepare for a more difficult evolution.

The project can be delivered on time, on budget and accordingly to the scope but :

·         the project members may be frustrated or completely exhausted at the end of the project.

·         the delivered quality is poor.

·         no business value has been created.

·         although the specifications has been perfectly respected, many issues are created possibly creating downtime. The data is unmanageable or unreliable. Clients are lost. It loses credibility. Reputation of the company decreases.

 

Time and budget are estimated too high.

A project manager has to be responsible. He doesn't want his project to fail, or to be perceived as a failure. He/she wants his/hers project to be successful. That’s very easy. He/she simply provides estimations that are x times more than needed. The project delivers successfully but much time, budget, resources and opportunities have been wasted.

 

Measure of the Iron Triangle?

What does the iron triangle measure? In fact, the iron triangle is not a measure of success of the project at all. It is at its best an indication(!) of the performance of the project manager to estimate the project and manage the execution against the agreed estimations. Why is it only an indication? It doesn't represent with 100% certainty his/hers performance. A project manager never has a full control over what happens in the project.

Delivering within the iron triangle

Delivering within time, budget and accordingly to the scope makes more sense when it is feasible. Therefore, certain conditions must be satisfied. The product to be built must be fairly well known. All the specifications must be detailed enough. The estimations must be reliable and realistic. Moreover, no important incidents may occur. But even then, other criteria can be added.

Not all projects are the same. Installing a technological infrastructure or an in-house software development project are completely different projects.

During most software development projects the client's needs, the problem and the context are investigated. This investigation may be done partly before the project begins and continues during the project execution. For these projects, the product is not perfectly known when the project starts. Estimations are then more unsure.

Time, budget and scope can be variable. They can be regularly reviewed during the project execution. The sponsor and client may not like this. He/she is more likely wanting to know what a project will cost, what is the delivery date and what he/she will get before approving the project start. However, in some sense, Agile projects works with variable constraints. It is presented differently and not named like that. The time, budget and scope are established per iteration and is established just before the start of the iteration. The total scope, duration and budget is the sum of the scopes, durations and budgets of all the individual iterations. Thus, this total scope, time and budget of the whole project varies on every iteration. This makes it easier to deliver within these criteria.

Project Success Criteria

Do we really need to know if a project is successful? Although this may be interesting, it is maybe not what we really seek to know or what matters most. This will be clarified.

The PMI defines the project as a process. A project can be defined as successful when it efficiently produced the product it is intended to produce.

Using only success criteria based on the process (project execution), doesn’t put much responsibilities about the final product on the shoulders of the project team. The project team can be judged successful because it produced efficiently the product demanded by the sponsor and/or by the business community. Nevertheless, the product can be completely unusable for the business or may even be harmful for the business. Basically, some project management skills and technological knowledge suffice to achieve this. This approach has clearly detrimental effects.

Product Success Criteria

The sponsor wants to get, as return on his invested budget, a product that suits him. His investment is motivated by the result, not by the building process (project). The product is more important. It makes sense to deduce that the success criteria should be based on the project’s product. The question has then to be reformulated as “Is the produced product successful?” To be successful, the team need to understand the operational environment and how people will use the product. Technological knowledge doesn't suffice anymore. More skills, like analysis and design skills, are needed.

Hereby, we must note that, measuring its success at the end of the project is just a snapshot of its business value. During the lifecycle of the IT system, after the project ended, its business value will continue evolves.

Business Success Criteria

The product can be useable by the end-users, it has to contribute to the business as well. This matters more. It's not a bad idea to link the project to business objectives. The project team will then be contributing to these objectives.

But again, things are not that simple. There is rarely a one-to-one relation between the business objective and the project’s product. The product created by the project contributes to reaching the business objective. But it is not the only factor. For example, a new sales support software application contributes to increase the sales. But the marketing campaign and the sales force influence the sales volume as well (and probably even more than the software application). Factors, external to the project, do play an even greater role. Reaching a forecasted higher sales volume is not a direct measure of the project’s product success.

 

These criteria require the IT team (not all the team members) to have some insight and knowledge in the business. It also requires a greater information exchange and some more collaboration between the business people and the project team.

One more level higher

Beyond the level of the business, there is one higher level: the enterprise. As the IT department should contribute to the enterprise, it is (also) from that level that objectives and criteria should be derived. This doesn’t only require additional knowledge and skills, it also re-positions the IT department.

Selecting Success Criteria

Success criteria should be selected with care. The most obvious criteria are derived from the objectives (project objectives, product objectives and business objectives). The facilities and machines have an accounting value. Similarly, the IT infrastructure and the information systems have a business value. Augmenting this business value can be used as a success criteria as well. We may also look at the more global desired outcome like end-user satisfaction and client satisfaction.

Or, we may get inspired from the resource-side of the initiative. Through projects, new skills can be acquired. There are factors that may seem to be not important to measure the success but which may undermine future successes. The resources may not be exhausted at the end of the project. They should be fresh to start on a new project. Unorganised or unreliable documentation or an inelegant design may not be a barrier to achieve the present objective. But they may be an obstacle to reach future objectives. Today, the failure or the success of tomorrow is prepared.

An organisation can establish a catalogue of success criteria by analysing projects and brainstorming. For every project, it can then consult this catalogue to establish a list of criteria for that project. Then, it can add more criteria specific to that project. The organisation can do the same for the product.

This is quite a lot of effort. But, why do we want to know whether a project was successful or not? It is important to know it. But today, in practice, except declaring a project’s success, what is really done with knowing that a project was a failure or a success? I have heard about failed projects that where nevertheless declared as a success and even project managers of projects that were admitted to have failed to be promoted.

CIT’s Problem 2: Business Distorted Picture of IT

Today, the business community plays a determinant role in the final outcome of the project. They formulate their needs, provide information, take decisions and determine priorities. They have also expectations and goals. They interact and collaborate with IT. Decisions, choices, attitude, approach and positioning are all in accordance with the image they have of IT.

The business community has a certain perception of IT. This picture they have in mind is based on their knowledge of IT. It is based on their experience with IT and on what they see of IT. This mental picture determines their belief system and will guide their decisions and give shape to the collaboration with IT. This doesn’t only concern the collaboration inside or outside the IT projects. It influences the positioning and collaboration at higher level as well.

The business community is working for years with computers. Most possess their own computer. They have also worked with plenty of end-user software. The business community knows that part of IT that is visible to consumers and end-users. This is only the surface of IT. This is what the market presents to them, the hardware, the content on the screen and the user experience. They got accustomed with only a certain facet of IT. Their experience is rather one-sided.

One of the roles of IT is to hide complexity from the end-users. The business community, or non-IT people, has much lesser the opportunity to dive below the visible surface and to learn IT from different perspectives.

Consequently, the business community has a distorted picture of IT. This picture leads to a reference framework of beliefs driving their thinking, their attitude, their expectations and their judgement. Since the picture is distorted and incomplete, the reference framework is biased picture.

What is this picture look like? The common main aspects are the following:

·         IT is about technologies

·         IT is toyish

·         In IT you can just try things out

·         IT is easy

·         IT offers high quality products

·         IT products can be acquired very easily and quickly. It takes no time to create IT products

·         IT is about plugging things together

·         Everything is possible in IT

First of all, IT is about technologies, or at least this is the essence. Does “IT” not stand for “Information Technologies”? And the IT department has competencies in these technologies and they manage them.

There are plenty of computer games on the market. Multimedia is another domain offering a lot of fun. But also modern software and websites are colourful and contain plenty of pictures, funny sounds and animations. From operating system to smart phone, they all look like toys. Who is scared of toys? They don't harm. They are fun. This idea sells. IT is like a toy.

The toyish appearance of IT products and their intuitive interfaces invites users to experiment. It makes the IT products more accessible. They stimulate people to try things. If it isn’t right, a user can easily correct or change it or even throw it away and restart. There is no need to think too much upfront. To support the trial-and-"correct" approach, the manufacturers implement different concepts like cut-&-paste, drag-n-drop, templates, do and undo, wizards and WYSIWYG. This reduces the risks for the user. The products are nearly fool proof. IT is about trying things out.

People become technology savvy. They can create quite a lot of interesting IT products through extremely flexible interfaces, wizards and the WYSIWYG-concept. What can we not do with only “one click”? The user interface perfectly hides the underlying size and complexity of the system. “Plug and play” is another concept that supports simplicity. Some people have some programming experience with writing macro’s in spread sheets or personal databases. Plenty of tools are available to develop personal websites. With little knowledge and even without experience one can already develop quickly a small software application. IT is really not that difficult.   

The computerised devices in the shops are getting always smarter and more powerful. End-user software, ranging from office software to games, has extremely powerful and flexible interfaces. All this technology and end-user software creates high expectations in terms of properties of the software.  People expect high quality IT products.

Technology comes to us very fast. IT offers plenty of technological innovations. Every day new computerised devices and new software applications appear on the market. People can simply buy it and use it. We don’t have the time to learn a product. A new version is already available in the shops or the competitor offers something better. Marketing pushes people to buy all kinds of new products and to replace old products by their latest version.  Plenty of services are developed and can be bought. Buy and you have it. It’s that simple. This is what marketing guys let us to believe. IT products can be acquired very easily.

We see more and more new technologies and products appearing on the market that works together. Just plug it in on with little configuration and they can work together. It’s just a matter of assembling components. There is even the story of two bankers planning to merge their banks who thought that, to have two computers of the two banks to work together it was just a matter of putting the two computers together and to connect them. IT is about plugging things together.

Everything is possible in IT. It is amazing how many times end-users think that computers can interpret situations, take decisions or read minds. This becomes apparent when business people tell you that “the computer knows that ...”. Often, they are not able to explain the exact process behind this knowing. Of course, there is “artificial intelligence” (AI) and tools to scan the electromagnetic waves of the brain. But when we consider the project and its budget and time schedule, it is clear that it is not realistic to make use of them.

There was a period that the motto “the sky is the limit” was associated with IT. This motto reflects a general idea of IT that creates high expectations. Is everything really possible in IT? Yes, but …

When we consider all these factors together, it is not surprising that the results achieved by the IT department may have been a great disillusion.

These beliefs may be present in different degrees in the picture business people have of corporate IT. And from the perspective of the end-user and consumer, this appealing picture might appear as being correct. But it remains a very superficial and one-sided picture when we consider corporate IT.

The business community may, to some degree, be aware that there is a part of IT that is rather unknown to them. They may consider this as a black box. Sometimes they may suppose that what happens inside the black box, inside the IT department, is very complex. And sometimes they may suppose that it’s all magic or that it isn’t that difficult at all and that everything is possible.

If these incorrect beliefs are used to influence or guiding IT, then we might be in serious trouble.