How to understand that it’s time to change the contractor, and what you should pay attention to when choosing a new partner.
When problems with a project occur, the customer’s first thought is, “Something is wrong with the contractor. And he decides to change it. Perhaps it is really about the performer. But in order not to repeat the experience of unsuccessful collaboration, it is necessary to localize the problem precisely.
Let us imagine the situation. You implement BPMS in your IT architecture. But the implementer keeps pushing back the deadlines for the final deployment, and the business processes that were supposed to start at the MVP stage are executed incorrectly.
What to do in this situation: “finish” the project with the current team, change the project executor, look for mistakes on your side? Will any of these solutions aggravate the situation?
We do IT development on request, and we often receive requests to continue a project from other IT companies. During the time we have worked on such projects, we have learned that we should not get excited about such requests: often there are systemic problems in project management which the contractor is unable to solve alone.
In the most simplified form, outsourcing in IT is built approximately according to the following scheme: setting a task – re-setting the task – execution. The client, in the person of his manager or project team, assigns tasks to the contractor. The contractor, again through his manager or project team, processes these tasks, analyzes the requirements, formulates an action plan for his specialists.
A problem can arise at any part of this chain. Let us consider each of them in more detail.
Problems in task formulation
There is a problem with the culture of project management in development. IT processes cannot be managed in the same way as, say, a warehouse or a factory – you need completely different methodologies.
For example, there are the following four types of systems:
Streamlined simple – the result is clear and predictable, there are already examples of successful practices to achieve it, the input conditions and requirements for the result do not change. For example, the task “to build a house” is clear and measurable, it does not raise questions for specialists.
Complex – the task is not unique, the desired result is approximately clear, but the best practices in solving similar problems have not yet emerged. The task “to build a city in a swamp” is solved with the help of successful practices in construction, supplemented by common sense and engineering thought.
Confusing – the system has increased uncertainty, the result is affected by changing factors and risks that must be responded to. The understanding of the ideal outcome changes with these factors. Now the team has to build a city on the surface of Mars, optimize its delivery cost, work out life support systems, compensate for possible risks and system failures.
Chaotic – there is no understanding of either the outcome or the best practices to achieve it. Conditions and priorities are constantly changing. Management and the team react to them ad hoc. The task in the example gets complicated to “build a universal dwelling module, which could be “deployed” on the surface of any planet – a gas giant, a planet with a high temperature, an Earth-type planet. No one has yet solved such a problem, so it is unclear what materials, technologies, shapes, etc. would be optimal.
Each system has its own peculiarities, each requires a different approach. If the wrong management format is chosen, the project can simply fall apart.
What is a problem statement in IT? When there is a task to paint the walls, there are no risks. When there is a task to deliver goods, the process is also largely predictable. In IT the implementation of something is the beginning of figuring out how it should be done.
You can, of course, try to manage a messy environment like a complex one – by preparing terms of reference and everything else (see Cynefin framework, Toyota Tao, Agile Manifesto, etc.). But we’ve never seen a single terms of reference in our lives that matched the final implementation, nor have we seen a single agreed-upon design layout that wasn’t adjusted during implementation.
And since we’re dealing with a convoluted system where specific jobs will be constantly changing and refining, we should have project goals and their measurable metrics agreed upon with all team members – this will ensure that we don’t lose focus.
If you’re managing a project as a complex project, the team doesn’t know the goals and metrics and only sees the tasks you set. A lot of business analysts have already worked on the task at the time you set it, a lot of time has been spent on pointless discussions about project architecture (it is useful to discuss project architecture, but bureaucracy should not be a priority).