In March 2009 the UK Ministry of Defence, faced news headlines as it was severely criticised over the installation of a new payroll computer system, which had led to thousands of personnel receiving the wrong pay. The Parliamentary House of Commons Defence Committee said there were “basic and fundamental” errors in the design of the system which wrongly paid out almost £29m. At the heart of the implementation of the payroll system was computer giant EDS.
The term supplier is defined ‘”make up for, deficiency need loss” (Oxford English Dictionary). Delivery by and management of suppliers is now an integral part of the majority of IT project deliveries, frequently from different countries, thus significantly impacting the project manager role. Suppliers can offer services such as solving business problems, solution design, development, testing, management, and implementation. Increasingly work is conducted off shore, or by a supplier from a different country and culture. The degree to which suppliers are involved and responsible varies but the more complex the project the greater need for suppliers.
A 2009 Standish CHAOS Chronicles report (as reported in Rosenhead, 2009) revealed that at any one time 24% of projects had failed, while 44% where in trouble, late, or over budget while failing to meet business expectations. One of the key reasons cited for project failures are suppliers.
This perception by clients that suppliers are a key cause in project failure is borne out by a study from Peerstone Research (Brown & Thompson, 2005). This research demonstrated that while the key reason identified for project failure was lack of senior executive leadership, the second through the seventh reasons all focus on shortcomings on the part of the software or services vendor to acculturate into the business of the client (Exhibit 1). The implication of these results from a client's perspective is that project failure is caused from outside of the organization rather than within the organisation, i.e., suppliers.
Exhibit 1 – Results from Peerstone Research
So is it always the suppliers fault, or is it really just a client perception? What are the typical supplier issues? Why do these issues happen? Are issues magnified when working with offshore suppliers? What are the options for resolution when suppliers fail to deliver? What can be done to mitigate these issues?
To address these questions, this paper will illustrate, through real case studies, some of the supplier issues that arose when delivering and recovering troubled IT projects. It will consider whether working with offshore suppliers is any different to that of working with a supplier who is based in another country, review the options for resolution when supplier problems occur and provide some practical guidance for avoiding the pitfalls of poor supplier performance, based on the lessons learned.
Relationships
Clients may solicit a range of supplier services from appointing additional resources filling a skills gap, hiring a supplier for hardware and software installations, to entire outsourcing projects and maintenance of the solution.
The service and organisational culture of the client will influence the type of governance and relationship that the supplier will have with the client, which can be a significant contributing factor in the outcome of a project.
Relationships can be single client to single supplier; client management of multiple suppliers, or the appointment of an integrator who will be a supplier to manage other suppliers (sometimes referred to as sub-contractors). Suppliers may subcontract specialised work or they can be appointed as the prime contractor who will take overall responsibility for the delivery of the project. The ownership of the relationship from the client to supplier is essential, as is the governance. If not correct could lead to complex politics, slow decision-making and, in some instances, blame. For example, a supplier could be delivering to a business department, but the paymaster and owner of the relationship may be the IT department, who the supplier, unless there is an agreement with the business department will need to report. If there are internal client politics between the business and IT then this will likely impact the ability of the supplier to deliver, as there will be additional levels of approval.
Supplier Process
“Procurement planning is the process of identifying which project needs can be best met by procuring products or services outside the project organisation” (PMI, 1994). A supplier's profitability depends on selling staffing services referred commonly to as “billing out” or specific products usually hardware and software. Responding to a bid can be a costly process for a supplier, as there is no revenue generation and no guaranteed income through the sales cycle, which can take months, and probably involve an account manager, industry specialists, sales, technical consultants, solution specialists and a delivery manager.
Exhibit 2 illustrates the procurement process, how it aligns with a generic sales process, and the potential key points of weakness in the procurement process which can be the point for future issues in project delivery.
Exhibit 2 – Illustration of the Procurement Process and the Potential Weak Spots
There are multiple types of contracts that can be agreed with varying degrees of risk for the supplier and client. In essence, the contract type breaks down into two basic categories:
- Fixed price contract: This will usually have fixed price milestone deliverables, sometimes with penalties if the supplier fails to deliver. The risk lies primarily with the suppliers who bear the cost if the schedule slips. As a result these types of contract are usually more costly than Time & Materials (T&M), as the supplier will put a percentage into the contract to try and mitigate losses.
- Time and Materials (T&M): This is based on the time of the resources or actual cost of the materials supplied, and not related to milestone payments. A supplier will bill at the end of each month, whether or not the planned milestones and deliverables have been achieved.
Project issues during execution usually stem from problems created at the commencement of a project, which starts with the procurement process. Exhibit 3 illustrates some of the prospective weak spots.
Exhibit 3 – Weaknesses in the Procurement Process
Case Studies
Case Study A
A leading UK-based utilities company, had entered into a two year, £20m, fixed price contract with a European Continental supplier (a.k.a. supplier), for the design and implementation of a new highly automated logistical warehouse system. This included all of the hardware and software, as well as interfaces into existing systems.
After go-live, the supplier would take responsibility for the support of the system, including code fixes, hardware repairs, and maintenance much of which would be done remotely by the supplier. This implementation was regarded as a black box implementation, which effectively meant that all work was outsourced.
The client was responsible for the overall management of the delivery, the implementation of the processes and procedures, training of the warehouse staff, and daily management of the delivery of the goods to its customer.
During the procurement process discussions between the IS team and the business representatives of the client fell out over the selection of the supplier. The IS team believed the selected supplier was not the best fit for the operation. As a result the business representatives, who were unaccustomed to project delivery, took overall responsibility for the project. The IS staff only assisted with managing the changes required with integrating the new system with the legacy systems. The business staff, realizing that they had no knowledge of automated warehouse systems or project management, employed a specialized logistical consultant (a.k.a. integrator), who worked for a very small consultancy, and who introduced another level of complexity to the supplier/client relationship.
From the outset of the project the client went against the design recommendations of the supplier, increasing the need for customisations (40%) to the base software. The client also believed that the implementation of the processes and procedures could be left until after go-live, when they had a chance to “see how the system worked.” At go-live, the management team and entire workforce from the manually operated warehouse were transferred to the automated site with limited training.
Due to problems with late software modules being delivered and testing issues the system eventually went live seven months behind schedule, with a list of caveats and defects that required fixing. Despite the implementation problems the client believed that once the system went live the problems would be resolved, believing a “black box” implementation placed all risks with the supplier.
Daily production breakdowns, increasing acrimony between the client and supplier led senior management to a decision to appoint a project manager, to stabilise and turnaround the flailing operation for the business to meet the peak winter contractual requirements, now only 12 weeks away.
Projects, by their very nature, are pressured, but on troubled projects, such as in this case, the pressure is heightened as the situation becomes more desperate. Under stress people often become “angry, judgemental, self righteous or revengeful” (Understanding the Blame Cycle, 2009), which in turn creates the platform for a blame cycle to develop.
Blame is something all too frequently associated with projects particularly by the time a project is in trouble. Psychologists (The Blame Cycle, 2009) have identified that the “blame cycle,” comes in two related parts:
(i) “The first is called the fundamental attribution error. This is the belief that errors have a voluntary component, by the people who caused them. These blameworthy actions are treated by warnings to “be more careful.”
(ii) Unfortunately as errors are by and large unintentional when they happen again, they are then seen as even more blameworthy, since they seem wilfully to ignore the warnings. “And so the futile cycle goes on.”
In client supplier situations blame transpires when the “customer gives a different set of reasons all pointing towards the vendor to prove that it is the vendor who is responsible. Vendor on the other hand tries to justify that there were a number of shortcomings at customer end that caused it” (Jaideep, 2009, p. 1).
In this case the client held the supplier responsible for all production issues, and cited the following reasons as the cause:
• Erratic releases of code into the production environment, without any communication
• Outstanding defects, burgeoning issues, and a slow and poor response time to fixing these problems as well as the modifications perceived as critical
• Doubted the advice and information given to them, and would look to their specialised logistical consultant for guidance, who would often contradict the supplier.
The supplier perspective was as follows:
• Client failed to address processes and lack of consistent procedures with their staff, which the supplier believed would reduce the number of modifications required, and whose priority persistently changed
• Failure to maintain the system as they had recommended at the times they had recommended
• Ignorant and negative warehouse management team, who preferred the manual warehouse
• Listening to their logistical consultant, who did not have knowledge of their system, instead of themselves
• There was no need to advise the client of code changes as they were being paid to manage the “black box.”
Recovering the Operation
The success of turning around a troubled project will be influenced by the recovery steps taken. In most recovery situations is time is of the essence and in this crucial. The recovery differed from turning around projects prior to a go-live, in that it had already gone live, the project team and former project manager had been released, and that there were operational and project issues to address.
The traditional generic steps to recovery are summarised in Exhibit 4.
Exhibit 4 – Traditional Approach
In this instance due to the extreme timeframe a Rapid Project Development (RPD) approach to delivery was taken, as illustrated in Exhibit 5.
Exhibit 5 – Steps Taken to Recovery
Execution Challenges
Putting a recovery plan in place with strained client supplier relations is only the beginning, and legacy issues within the client organisation caused a number of challenges:
• Weak supplier contracts: Both the contracts that had been signed were extremely weak and produced by the suppliers not the client. The suppliers fixed price contract had no provision for the turn around of defects, the prioritisation of defects, response times for modification requests, and penalties for failure for delivery or poor quality delivery. The integrator contract had a clause that absolved any comeback unless the client raised an issue within 10 days of that activity or failure to deliver.
• Lack of knowledge as to how the system worked: The client management did not know how the system operated. Therefore there was a large dependency on the integrator who held this knowledge over the client and who was frequently at odds with the supplier, making it difficult to know who was giving the right information. When the integrator took leave the warehouse management team had no option but to listen to the supplier, who they began realised had the knowledge and was not always wrong. This began to change the dynamics of the relationships.
• Releases, configuration management and specifications: Lack of mature procedures by the client or supplier, the complete absence of service level agreements (SLAs), all contributed to poor quality delivery and communication. Reluctance by the supplier meant that all attempts to introduce SLAs were ignored.
• Lack of delivery of the supplier road map: At the core of the recovery plan, was the dependency on the supplier to produce a road map for the delivery of the defects and modifications. The supplier project manager made repeated promises for five weeks the delivery of this road map, which they failed to meet. This situation reinforced the client's attitude that the supplier was at fault, but with a limited time frame remained to stabilise the production system, options as to what action to take were assessed.
Options for a Client When a Supplier Does Not Deliver
The option a client will take will depend on (1) the stage in the project life cycle, (2) the type of relationship the client will wish to continue with the supplier, (3) the strength of the contract and the audit trail. The client reviewed its options, which are summarised in Exhibit 6.
Exhibit 6 – Supplier Options
Summary Outcome Case Study A
The decision was made to build the partnership with the supplier, through a combination of strategic and tactical moves, achieved by the following:
• A deliberate effort from senior management to the technical team members, to partner with their opposite member within the supplier organization. Regular face-to-face meetings at all levels not just on the client site brought an improved understanding of culture and modes of operation.
• Listening to the supplier and implementing processes and procedures, which began to increase the skills of the client staff, reducing errors, and the need for many of the modifications.
• Removal of the specialised logistical supplier, which reduced the “three way debates” and complexity, and encouraged accountability and trust between the supplier and client.
• Agreeing an early financial payment of the outstanding money if they delivered a percentage of the modifications, and other agreed actions.
Case Study B
The use of offshore suppliers over the past five years has grown substantially, and may be an integral part of project delivery according to Investor Words (2009). An offshore company can be defined as a “company incorporated in a country where there is little government control and /or low tax rates.” They are different from working with a supplier located in another country in that they are established centres of excellence. While 44% (RTTS, 2009) of offshore companies are based in India, an offshore company can be based on any continent.
To a client or supplier an offshore organisation brings expertise, and cost efficiencies. However, a Forrester IT services survey of European IT decision-makers found that 46% of respondents believed offshore outsourcers were worse at project delivery, compared with only 23% who said they felt inshore providers were better (Computer Weekly, 2007).
An international drug manufacturer was automating its global assembly and dispatch of drugs to the customer. Two off shore companies, based in India were contracted: (1) one to design and build the software, (2) and one to test the software, before user acceptance testing which would be conducted by the client. The client was directly managing the testing, but had a supplier to manage the offshore company for the design and build.
The project time frame was a year, with an immovable go-live date. The IT department, who had a reputation for poor delivery, was managing the project. The strategy was for the offshore (with onshore leads) supplier to generate a prototype, alongside the business then commence the build offshore, prior to the supporting documentation being produced. However, after the project commenced the client quality control group decided that the build could only commence once the documentation was signed off by the business, but the client still expected the supplier to deliver in the same time frame.
The documentation was being produced offshore (India), and was of poor quality. This led to numerous re-writes, which not only began to extensively delay the project, but also enabled the business to introduce a plethora of scope changes, ever-increasing the gap between the documentation and the prototype, with a resultant requirement for a larger build and more test time.
As tensions grew between the suppliers and the client, the project weaknesses and classic project reactions came to the fore:
• Off shore virtual environment: Not only was the documentation not fit for purpose but working in a virtual environment, the client team often had difficulty in understanding the off shore team over the phone and interpret their documentation. The issue of working hours and which time zone the team was to work also arose.
• Governance: No overall program manager—a program board ran the project that met daily resulting in turbulent and stormy meetings.
• PMO: Had control of the enterprise plan(s), not the IT project manager. This led to the PMO having more control and authority than the project manager. Further there was no overall integrated plan, only a high level plan or individual stream plans, which pitted streams against each other and caused confusion.
• Crashed activities: plans were reviewed, constantly changed and activities drastically crashed. A seven-day working week was introduced for the offshore teams.
• Off shore on-shore debate: Time was lost as the management team diverted resources to examine the benefits of bringing the Indian test team onshore, while trying to stay cost neutral.
• Resources: Matrix management situation, so resources would leave the project based on time not what had been delivered.
As the project continued and the schedule slid the management style became increasingly harrying. Resources left, became sick, or fired as scapegoats, crashed activities, became chaotic and the offshore suppliers were blamed for the woes of the project. The promised go-live date was delayed by months.
Comparison between an Offshore “Western” (local) and an Offshore Supplier
Culture is often identified as the greatest offshore challenge, and cited for misunderstandings and problems. Exhibit 7 provides some areas for consideration when working with off-shore suppliers as opposed to a supplier who may be nearby in a different country.
Exhibit 7 – Comparison of Offshore and Local Suppliers
Summary and Guidance on Avoiding the Pitfalls
As both case studies have illustrated project failure is rarely down to just the supplier, as the client has the ownership to make sure that the supplier is managed. The following hints and tips can be applied to help mitigate some of the issues between clients and suppliers during project execution.
Procurement:
- Bid documentation:
- Must be developed by the client and involve all relevant stakeholders: business, legal, technical, financial, and project managers.
- Have clearly articulated scope, and not only cover the technical, legal, and financial expectations, but also all the project areas.
- Client team:
- Needs to be “as one” and the project manager must be included in the procurement process.
- Due diligence:
- The client has as much responsibility to ensure that they conduct a thorough due diligence on the suppliers, as the suppliers on their chosen clients. This includes references, site visits, understanding the nature of the supplier organisation.
- Level of priority: Understanding the level of senior management sponsorship and commitment on the project, as this will affect the level and quality of resources given by the supplier.
- Contracts:
- Do not create one contract for multiple suppliers.
- Review the subcontractor relationships.
- Planning:
- One integrated plan with client activities included if the contracts are to be realistic.
- Communications: Site visits to suppliers are recommended at strategic points in the plan, to ensure relationships are built and that there are clear communication channels.
- Time zones and methods of communication must be agreed.
- Locations for working must be agreed.
Execution:
• One integrated plan, one team approach, with regular meetings to include all relevant parties, and one reporting system to executive management.
• Governance (both client and supplier[s]): Appropriate governance.
• Contract management by the client and clear accountability for all parties.
• Ensure tight scope change process is in place.
