When should a change be considered?
When a project is ongoing, it can be difficult to promptly identify whether any problems are temporary or whether they require immediate action. There are a number of symptoms indicating a project crisis that is best dealt with by terminating cooperation with the existing provider. These are:
- Shattered trust (i.e. a discrepancy between promises, commitments, and delivery on the provider’s side)
- Lack of responsiveness
- Unwillingness to cooperate
- Lack of a proactive attitude on the part of the provider
- An increasing number of errors, and no system stability prospects (the project due date is drawing close, but no progress is observable)
- Increasing costs, resulting from a change in the project scope on the provider’s side
- Problems with subsequent system rollouts, particularly to other countries/regions
- Failure to deliver on key performance indicators (KPIs) on the part of the implemented solution
Numbers seven and eight – problems with roll-outs and failing on KPIs – require special vigilance; these issues tend to be ambiguous and are thus frequently overlooked.
It may happen that the project seems completed (e.g. a working e-commerce system has been delivered), yet it does not meet the business goals (e.g. does not generate more sales). In other instances, a system is created and works well in one country, but the supplier is not able (or willing) to perform a rollout to subsequent countries. This can often happen because the new market is significantly different from the country of origin and requires major modifications of the original solution. Country-specific challenges also occur in subsequent rollout processes.
So, what happens, supplier-side, that causes these problems?
Reasons why an IT supplier can’t deliver
Properly identify a problem, and you’re halfway to solving it. If you can identify what’s causing that problem and why, so much the better. Being aware of the common issues underlying an IT supplier’s failure to deliver can help you avoid such issues in the future. Plus, it can also make finding a new partner a bit easier. Thus, it is worth knowing the most frequent mistakes made by suppliers:
Underestimating project scale and complexity
It can happen that, at the start of the project, the supplier does not include all project conditions in their considerations. Perhaps they lack a complete vision of the solution or they start their planning processes while missing key information. This can lead them to disregard the fact that the scale of this project exceeds their operational capacity; it can also obscure the fact that the projected timetable is unrealistic. Their initial estimate may not account for the above-mentioned aspects, meaning the actual implementation cost will be higher than planned – which makes the project unviable.
This under-estimation can take place at various levels, particularly at the:
Technological and tool-related level - Due to insufficient knowledge of some technology, the supplier does not know its complete potential – or its limitations!
Business level - Due to insufficient analysis of the client business, the supplier is unaware of the business’ complexity, its real needs, and the processes and business conditions to be covered.
Staff and subcontractor issues
Problems in a project can also occur for external reasons. These are not related to the project itself.
One of the most frequently external reasons for project failure is a change in the supplier's team: an internal rotation will take place, or employees will leave for other organizations. The departing employee is especially problematic, as the company often loses vital competencies when a highly-skilled team member departs.
Occasionally, a similar problem is seen with the provider’s subcontractors. In this case, supplier-subcontractor agreements gone wrong will disrupt efficient task implementation.
In these circumstances, there are two possible paths: closing the project, or finding another IT supplier.
Preparing to transfer an e-commerce project
As a company to which projects are handed over, our experience has shown that three things are essential when preparing to hand a project over to a new technological partner:
- Project inventory: The departing supplier should conduct a project inventory before they leave, and you should make sure that it’s executed properly. This stock-taking should involve:
- Infrastructure documentation
- Architecture model
- A detailed description of the modules implemented, including the integration model
- A list of the applied licenses
- All preliminary assumptions made prior to the implementation
- Reevaluation of project assumptions: Have these been changed during the project work? The scope of the project may expand during the development; the solution itself may divert from the original path (e.g. it was originally assumed that e-commerce should serve ROPO (research online, purchase offline) needs and direct customers to physical stores, but later it became obvious that customers prefer to buy online).
- Audit: Ordering an audit before changing IT suppliers is always a good idea, and the best party to do it is the potential new supplier. This audit can be of a technological or UX nature. Or it can be something completely different, depending on the nature of the project and the problems uncovered. Regardless of the type of audit, it is important to perform an audit BEFORE signing a contract. This provides an evaluation of the scale and status of the project; it also allows companies to identify possible errors and assess the approach and expertise of the potential new provider. Note: It’s not unheard of for a departing provider to indicate a project has been completed or is almost completed when in reality it still requires much more work. Tread carefully!
What to look for in a new IT supplier
When looking for a new tech partner, conduct careful market research first. Look for more than just experience in selected technologies and in your industry; search for a partner that’s experienced in taking over an in-progress project.
Why be so specific? Because taking over a project requires different competencies than starting one from scratch. It also implies different challenges: your new supplier must dig through various layers of the created solution to understand how it was built and to find the source of the problem; this is particularly hard when documentation is scarce.
Apart from experience in project takeovers, the new supplier should:
- Have a wide and comprehensive background. Look for companies who have a proven understanding of your business context, industry knowledge, experience in international roll-outs, and UX skills. You need more than just a group of experts in various technologies.
- Demonstrate their engagement with your project. When a project is handed over, the previous supplier rarely has strong motivation to provide all necessary materials, which undermines the morale of the whole project team. This is the time for the new supplier to demonstrate their clout and determination.
- Be able to say no. This is a major indicator of the new supplier’s quality. It is a good sign when a new partner can discourage a solution and justify their stance; it shows they understand the complexity of the project and think in terms of realistic implementation.
Before changing mid-project, consider
A project crisis that forces a supplier change presents an opportunity: a new horizon opens up. We advise you, however, to make sure your company is ready to hand your project over to a new supplier. Take stock of the current state of the project and its assumptions, and have a thorough evaluation and audit performed.
If you are considering changing your supplier, we’d be happy to help you navigate the process.