Disclaimer: Today we will talk exclusively about unsuccessful projects, so we will not name names, passwords and attendances.
All failed cases from my and my friend's experience can be divided into three types according to the sources of problems:
1. Working with stakeholders
The reason for many of the project's problems is that we do not listen or hear the customer. This is especially critical at the very start, when there is a risk of missing the answer to the question "Why is the project initiated?"
Case 1
We were faced with a simple task - to block all possible financial transactions under contracts that are not agreed within the company. We calculated the effects and worked, as it seemed to us, all the risks. However, during the discussion, the main user argued that this would not work: "We will have a production process." It sounded like an excuse, and the main customer confirmed our hypothesis and insisted on just doing it.
On X-day, according to the plans, we launched the functionality, and about an hour and a half later, our main customer, in a not very good mood, called and asked to roll everything back: “It doesn't work!”.
How was it necessary?Listen to the concerns of the user, who knows the specifics of the organization from the inside, and work out these risks. There is always an opportunity to find options that suit everyone.
Case 2
It was a functional customer who perfectly understood the task and the system that we had conceived. But we did not take into account the interest of the IT department in the implementation of this project and came to them rather late: at the stage of developing the architecture. I had to revise the project and move the deadline for its delivery. We lost time, money and reputation by overestimating the influence and capabilities of the functional customer and underestimating the internal relationships between divisions in a large corporation.
How was it necessary? To involve all stakeholders in the work on the project from the very beginning and take into account their interests, despite the assurances of the customer.
Case 3
And this was a case that almost became unsuccessful. The functional customer, represented by the CEO, wanted to change the cost accounting methodology and, according to all calculations, the effect of the changes should have been significant. The team from the financial block was ready for changes and by the time the task reached the IT analysts, the decision had already been made. And here we did the right thing and asked: Why? How will it work? Who will support the process? How did you consider the effect?
As a result, the effect was recalculated taking into account changes in the ERP system and the costs of maintaining the process and tool. Not only did the effect “disappear” in the money, but additional risks were also discovered. The project was closed, and for employees of the internal automation division, it became a rule to ask questions at the start, even if the task came from the CEO.
conclusions
- Always look for a reason, purpose, effect. Argument your position. As one friend of mine (a class manager) says: "Listen, not sell ... Then listen again ... and only then sell";)
- Live one day with direct users of the product and get to know their routine in detail. This will help to anticipate all possible nuances.
- Work through all the risks that seem significant to you, the functional customer and any interested person. Pay special attention to the most negative clients / users towards the project. They clearly know something! ;)
- Don't miss a single participant in the process. There cannot be one participant in the process, and the IT department must always be taken into account!
2. Description of requirements
The holy of holies for any analyst is a description of the requirements. Let's consider errors in this area on the other two cases.
Case 1
One of the development teams received a project that required revision. The system came with documentation, where the description of the logic of the system was written using SQL queries. By the time the work began, the system had already been seriously redesigned and SQL queries were no longer relevant. I had to spend some time doing reverse engineering to understand the logic and functionality of the system.
How was it necessary? Recheck documents for relevance and compliance with the level of development of the project. Especially when passing it on to other developers.
Case 2
It was an interesting project to automate all processes within the organization. The project involved 5 systems of various classes, which had to be integrated with each other in order for the process to continue without interruption. The team was designing the architecture of the solution for about two months, when I was connected to the project.
In the process of communicating with the customer, I realized that he sees it in one way, and the developers in another. These were the minimum agreements in words that completely changed the project. I had to start from the very beginning and work through all the requirements from scratch: Why? What? How?
How was it necessary? Clearly describe not only the requirements for the implementation of processes and sub-processes (how it will work), but also how the final result will look.
conclusions
Often, teams are afraid of customer comments and run to develop when they hear "well, sort of like that." We can assume that you found a common language with the Customer only if he himself began to make adjustments with his own hands. Some people find it convenient to read texts, others - schemes, and others - interface layouts. It's worth trying everything until you find a common language, even if it will be “drawings on napkins”.
3. Development of an idea, product or solution
These are stories about product management, when the idea floods the mind, and everything else does not matter.
Case 1
We had a great product for automating routine tasks within an organization: from entering information to answering any questions from employees. And everything was great: we found the first customers, understood the market - it seemed there was a lot of money - we launched a couple of projects and successfully completed them. And at that moment we opened our eyes: no one calculated the cost of supporting the solution. And it erased all possible attempts to make money to zero.
How was it necessary? Carefully calculate all aspects of the project: from development to solution support.
Case 2
Another story is when we did not work out the market. An idea was found for a good product that had no competitors in the market, but had customers. At least one, and he was willing to pay and invest. We got into this project and were faced with a complete lack of a theoretical basis for the development of such functionality, but we managed it.
And after entering the market with the product, they realized that it was not in vain that there were no competitors. Many people neglect this feature despite all the effects it guarantees.
How was it necessary? Think about why there are no competitors in such a profitable market sector and get to the bottom of the truth.
Conclusions:
Check the viability of the project within the framework of not one customer, but competitiveness - according to the current market situation.
Culture of failure
In order to overcome difficulties and not get caught up in them again, you need to find a reason. More often than not, it lies in the culture of failure that is adopted in organizations. There are two bad ways to respond to failure in organizations:
- Condemnation / Punishment
Condemning mistakes, we kill initiative. Employees are afraid to be creative and only make safe decisions. This leads to stagnation in the company.
Solution: define boundaries for errors. It is necessary to allocate a resource for the manifestation of initiatives and check them at checkpoints. Well, track the success of the project according to strict criteria agreed in advance. - Silence
This tactic leads to repeating the same mistakes over and over. And this, in turn, leads to the loss of the company's position in the eyes of customers, competitors and the market.
Solution: build a system of experience exchange between employees. Discussion of possible solutions to failures ultimately leads to a methodology that helps to avoid these mistakes.
Reasonable reflection helps to develop, but this is not a reason to surround yourself with failure only. Look for balance, because learning from successful projects is much more enjoyable