Predefined, is it?
It was supposed to be a quick win project that typically delivers what everyone refers to as low hanging fruits. The project brief was a working model on a spread sheet of the solution to be developed. So it was assumed that the solution should be easy to create and scale up. The timelines and costs were agreed to and the vendor team arrived on site to finalize the project scope and integration points. So what could be the reason for the conflict? If something is working, how can requirement change?

The CIO heard the point of view from each stakeholder, the user, IT project manager, and the vendor. For the user, she had clarified how the model worked and what was expected from the system that the spreadsheet was unable to deliver; the IT project manager stressed upon the integration to various masters and the scalability expected of the solution; and the vendor project manager completed with a complaint that some of this was not in the original scope that was outlined prior to commencement.

So what was the issue asked the CIO? Wasn’t the current discussion to clearly define the functionality expected from the system? Where is the conflict in the integration definitions? Does expansion of the concept and explaining in detail qualify as scope enhancement? They had an advantage over a standard software development model that a working prototype was available. There was a discomforting silence for a while until they all decided to go back and close the discussion amicably.

So when I bumped into the CIO many months later, I enquired about his story from our last meeting. He mentioned that it had gone live but did face challenges in the initial days. This was discovered during deployment that the system needed elaboration. The functionality was evident common sense but missing from the system (I shall not get into the details here which my CIO friend explained to me to my surprise). He quizzed the team for the missing parts of the whole; the user said it was obvious, the PM agreed, the vendor did not.

State it explicitly
“It is not in the system since you did not ask for it.” Technically correct but does not solve the problem! So now that the system is accepted, deployed and support phase over, this is a Change Request and will have to be managed as such. The ineffectiveness of any argument was evident and the only recourse was to give in to the demand in the interest of the project and the business. That vendor has not been welcome to new initiatives since then; even the support has been moved to other partners.

My friend the CIO had no recourse! Do we? With the outsourcing trends taking the direction that they have, everything has to be now explicitly stated and included as a part of the Requirement Document. If you do not have an internal team of business savvy IT team members actively involved through the cycle such outcomes are quite likely. Invest in your team, keep them actively involved in the project and not just to manage at a high level. Keep a watchful eye open. Assumptions hurt; try “ass u me”.

Different vendors set different expectations on what they can deliver; the niche providers do not promise a breadth of services, they stay focused on their expertise. The big ones claim to have expertise across the legacy to contemporary and cutting edge; they have industry practices and business consultants who profess incremental to transformational change capabilities. You name it we can do it; even if you cannot put a name to it, we will find a way to do it!

Complexities in governance

The large one-stop-shop engagements typically begin with setting of scope and expectations on delivery, timelines, and quality of service, rewards, penalties, force majeure, arbitration, cost, escalations and a lot more. The larger the scope, or the longer the time period of the contract, the governance becomes complex. We know that Total or Strategic outsourcing can cover everything; in recent times though the number of such deals has been dwindling.

So it was an interesting debate when a few CEOs on a panel berated the one-stop-shop companies giving it a new twist. Consider you wanting to reach a far-far away destination and the only option is to go by bus. Every bus gets you there, some are slower than others, some offer many comforts through the journey; the cheaper ones just get you there. Depending on what you can afford, there are many options to choose from. Caveat is once you have bought a ticket, a change is difficult and painful.

When someone advertises ‘one-stop-shop’, the conventional understanding is that I get from where I am to the final destination with no stops with the advertised and agreed comfort. Reality as we know is not always as advertised. A CEO remarked on his journey with one of the global biggies; he signed up for a long journey wanting to focus on his business. Very quickly he was on the discussion table with the bus driver, conductor and the entire fleet management company.

Why is my journey so excruciatingly slow? Why is the transformation promised not happening? When will I see any impact to my employees, stakeholders, customers, or for that matter any efficiency to business operations? Whatever happened to the pre-sales promises made by the various function heads of your company on various domains and technologies? Pat came the answer, “we are a one-stop-shop company; we go one stop at a time. This is what we promised; we did have a driver change and a breakdown; that is part of the contract. We meet defined service levels.”

Devil lies in the detail

Both are right in their frame of reference; so where is the problem? I believe that any such engagement should have common definition of reference points with clear understanding of step-by-step process, impact and governance. Otherwise the semantics of the one-stop-shop can be painful for everyone involved, the deliverer and the recipient. The bus is still moving but not in the way that makes the journey a pleasure. CIOs will be at the receiving end if there are such gaps.

He has always been a proponent of outsourcing over his illustrious career spanning more than two decades, more like a trendsetter than a follower. In that he had worked with outsourcing companies large and small, local and global, structuring large deals that were acknowledged and appreciated by the companies he worked for as well as the vendors. When someone needed advice on managing tricky situations or contracts, he was the person they approached.

Building on an existing contract that did well, he had extended the scope of services and support for a longer tenure. Considering that the outsourcing vendor had been working with him for a long time it was seen as a natural and logical extension. There was merit and value in the deal for both sides. It was like a no-brainer deal. Going into execution he did not foresee any challenges barring the initial teething troubles when any new service is commissioned.

A disruptive extension?

The slip between the lip and the proverbial cup or intent to execution started going awry very quickly. Process review and tool deployment planned, the timelines slid with consistency that was expected of improvements. Existing services that had been working well for many years also started deteriorating. Monthly review meetings attended by increasing levels of management made the right noises but delivery failed to align to commitments. Whatever happened to ITIL led SLA and global best practice?

I was surprised to hear of his misery considering that the relationship with the vendor preceded his arrival into the company and that successful outsourcing was child play for my CIO friend. Large deals have a way of coming to life on their own; they do not always follow a predictable pattern, instead they find their own lowest common denominator in which they settle down before improvements begin. He acknowledged this hypothesis and queried how should he respond to adverse business impact or disruptions to critical business processes?

This was discussed in the review meetings and the team said they were committed to making amends. Reality being different, he was exasperated with selective and partial information sharing. It is not the way relationships are built and sustained. What causes this gap? I do not believe for a moment that there is mal intent present; but how to bring the train back on track? Was it about transition from courtship to marriage predicament where partners take the relationship for granted? The nuptial agreement spelt out everything, but … Not wanting to proffer advice to the wise, I sought his game plan.

Forget the SLA, the contract, that can come back later; it is people who make things happen. For the situation to change, the people have to be brought back to the table with a rigour to the review that sticks accountability to senior leaders and individuals. Review and monitor everyone by the day on the plan and change people if they are unable to run with the required speed. Keep the pressure up until they deliver or want out of the relationship. It is critical and important to keep the end objective in mind, and that is linked to business expectations and improvements.

I wished him luck and promised to connect back in a few weeks again.

Over a year of courting, discussions, negotiations and going over a long legal contract, it was a sigh of relief for the vendor and the enterprise when they did sign off the deal. As all strategic sourcing deals go, there was an expectation of maintaining business as usual with improved efficiency and lower cost; then move on to transformation driven by tools and technology which was the investment promised by the vendor. Over the decade of relationship, it was expected that there would be efficiency of scale, savings on the table, and investments in innovation with global benchmarking.

The big team arrived soon enough to transition services and fit or change existing processes into their framework, which they managed with some difficulty. Within a few months, unable to scale up to diverse needs across locations, changes in the management team were enforced and that brought welcome improvements though not commensurate to expectations. The first big review meeting was a shocker for everyone. Some milestones achieved, lot of work in progress way past due dates, a few endpoints seemed a long way off; the CIO who was well known for his patient handling of crisis lost his cool.

Opacity in contracts
To begin with, the interpretations of clauses done by the execution team were in conflict to understanding while drafting them into the contract. Stretched timelines became super-stretched timelines; senior consultants attempted to provide solace with no Plan B in case success eluded the team. The ‘high tension’ meeting resulted in change of pace and ‘compromise’ in favor of the customer. With new timelines cast, the pressure was on everyone; avoidable pressure as agreed by everyone present.

Why does delivery rarely match presales promises or timelines? Are sales teams preconditioned to sell unreasonable timelines or commitments to bag orders from unsuspecting and gullible customers? No, I am not calling the CIO names, but admiring the ability of the sales teams to sometimes get away with untenable contracts. I am also bewildered at the ability of delivery teams to squarely make a hash of even normal service delivery expectations. What causes history to repeat itself in almost every engagement?

A communication issue?
In this case, the CIO summed the case up with one phrase: “lack of consistent communication across the ecosystem”. The presales team did not spend adequate time taking the transition team through each and every clause and expectation. The delivery team found significant differences on the ground to their assumptions which required change. The project lead busy fighting fire every day forgot that consistent communication is essential to setting expectation, managing perception and finally success.

I believe that it does not always matter what you do; what matters is how you communicate what you have done or planning to do. No news is not good news when everyone is expecting some change. Otherwise strategic sourcing will become a big tactical pain where real life experience defines success.

Essentially, outsourcing of the basic break-fix and first level support (typically personified as the IT Helpdesk), broadly constitutes a centralized number, email or web based form for users to log their calls. The person at the other end is expected to acknowledge the call, and attempt troubleshooting via phone or remote control of the computing device. If this is not feasible, he’s then supposed to provide desk side support through an Engineer. Track progress of the call until completed, repeat ad infinitum. Sounds simple enough!

Add a dash of best practices, frameworks like ITIL, service level agreements, and periodic reviews—everything should be hunky dory?

As computers get ubiquitous, cheaper, sturdier, and easier to use, the expectation levels have also risen. Today the expectations veer towards near instant resolution, which reflects the high level dependence as well as time pressures that are typical of today’s workplace. Mobility adds to the complexity, while security concerns mount—new and old threats challenge existing solutions, and compliance add to the challenge. To add to this, budgets are shrinking, and attrition is on the rise. So is it fair to expect service levels to sustain and improve, quarter on quarter?

CIOs with reason are right in their expectations from facility management, as this is what the enterprise demands in a hyper competitive environment. On the other hand, service providers have been struggling to rise up to these challenges and seize the opportunity. A few CIOs mentioned that they were reviewing alternatives, even though the contract period was far from over. In these circumstances, root cause analysis points towards many reasons that contribute either singularly or collectively. 

Key amongst these factors remain people (See Challenges of an upturn), where service providers did not plan for attrition, with growth coming back; thus the pipeline dried up, and customers saw an adverse impact. If the person exiting is a Project Manager, it can take up to six months to recover. And we are not yet talking about quality of resources on the ground, which is deteriorating slowly and surely. Most new hires were fresh out of institutes, with very limited or no soft skills orientation. Customer service is not just about fixing the problem, but also with respect to addressing the person behind the computer and his downtime.

The second big issue is process compliance, with or without ITIL. Every outsourcing engagement has a plethora of checklists and processes which need to be rigorously followed to ensure success. However, for the person on the ground, this is a distraction, and sometimes seen as policing. Inconsistent data and incomplete checklists lead to increasing grievances with the users.

Weekly, fortnightly or monthly review meetings are at best a post mortem of the issue; instead, daily exception management between the vendor and customer Project Managers is required to ensure that these do not get discussed at the Management table. CIOs need to conduct periodic assessments to remain connected to the process, a practice which also keeps the teams’ focus on deliverables.