Can IT Companies Learn From ‘Problematic’ Projects?

4 min.

In our last post, we talked about systems thinking being the basis of every learning organization. Even though the concept of systems thinking has been popular as a business topic for decades, there are still many situations where companies are thrown back into reactive old-fashioned thinking. The lack of systems thinking may result in different failure scenarios, which make projects ‘problematic’:

Scenario 1: Project Became Unprofitable

Let’s take an example of a project becoming unprofitable. Automatically labeling this ‘negative’ will only keep the company from learning something new and teaching staff that information. First of all, a number of projects can be used as a trial for fresh tools, technologies, approaches, methods or techniques, or to train brand new specialists. For instance, if a new technology was used and failed, testing it otherwise would require spending from the education budget, so there aren’t any real losses. Second, the technology was used in the field in real circumstances, which gives the trial more practical value and can also increase the motivation of those who are willing to learn new things. Such ‘failures’ are actually good for business.

Scenario 2: The Manager Lacked Control

When a project fails, it can also mean lack of control from the manager, not enough budget control, and sometimes a stark difference in expectations from the company and the client side. The first step to take is for the manger to accept that this has happened. If this happens the first time, there is nothing wrong with it, and it is a natural way of learning together. If a mistake is repeated again, that could be a red flag, and should be addressed thoroughly. The problem here is not the manager alone, because the manager has to be monitored from above while team members also need to have enough freedom to interfere and point out matters that should be fixed. Again, these are systematic processes, and not just the fault of one person.

Scenario 3: Unclear Initial Project Requirements

Sometimes at the beginning of a fixed price project, clients are not ready to present a set of clear requirements. Some of them do not understand why the requirements should be gathered at all. As the work continues, however, small additions and variations to the initial plan start piling up, and while the manager and the team are in the process, they may be so eager to please the client that control over finances relaxes and new functionality results in out-of-budget spending.

When a team is in their work mode, their perspective may be limited and from their point of view, they may not notice the fact that they are slowly sliding down into a financial pit. This is an example where the changes to requirements are so small and subtle, that they do not seem like much when they are made, but at the end of the project, they pile up as financial time management burdens. It is known as the ‘boiled frog syndrome’ where if a frog is placed in boiling water, it will jump out immediately, but if it is placed in cold water and heated slowly, it will be boiled alive, since its body is not designed to react to gradual change. Lack of systems thinking is clear in a situation like this. Remembering that no event should be treated out of context (of a fixed price project, in this case) is something to learn in this scenario.

So Are Difficult Projects A Blessing or A Curse?

It is no secret that working on multiple projects and taking on new ones all the time is a good survival technique. It may seem like the reason for it is continuous growth and higher profits, but it’s not just that. When you diversify into many different types of projects, varying industries and types of clients, it is possible to actually take on unprofitable or ‘problematic’ projects that will have invaluable long-term education benefits. These can be in the domain of industry expertise, knowhow, techniques and tools, or even new contacts.

No money will be made on these projects at the moment of their completion but the gained expertise may help to make great profits later, and evolve as a business. Experimenting this way, taking certain risks and minding the time lags to actually get to the bottom of cause and effect processes at all levels makes work exciting, and allows the company to not to put blame on separate parties prematurely, but to work as a system, as a coherent whole where everything is connected.

So, what do you think about systems thinking and learning from difficult projects? Is it necessary to crack a few eggs to make an omelette, or can you avoid ‘problematic’ projects altogether? Please share your thoughts and stories below.