Advice For Provider Sales Archives

What Venture Capitalists Can Teach Us about Driving Transformation | Sherpas in Blue Shirts

November 24, 2015

The current way we buy complex services through a purchasing department is to come up with elaborate detailed requirements, which often can only be implemented over several years. We put these out to bid, forcing the vendor community to respond with far more detail and waterfall project plans laying out in excruciating detail how they will architect and migrate this environment to the new desired state. We then conduct the services version of the limbo dance – how low can we go – where providers compete the price of the solutions. But there is a huge fallacy in this procurement methodology.

We have a long history of unhappy results from this methodology, a body of work spanning 10 to 15 years demonstrating that these procurement efforts mostly result in unmet expectations, cost overruns, and evolving service levels. This is insane. Insanity is doing the same thing again and again and expecting a different result.

The fallacy of the procurement methodology

By using this methodology, we effectively try to articulate a transformational journey in an overly precise way even though we have only a limited understanding of both the existing and future environments. The result is exercises in creative writing with overly precise work plans and cost estimates. The only thing we can be sure of is that the plans are wrong because of the lack of information (no matter how much time we spend on the plans), and the fact that the world changes during this timeframe. So we’re guaranteed to be wrong.

Therefore, our preferred way to purchase services is flawed. It pretends that we know with precision things we don’t know and it does not adequately accommodate for the nature of change in technology, business process and business conditions.

What can venture capitalists teach us?

For years VCs have faced a similar problem. How do they develop breakthrough, compelling new technology products, fund them, manage them cost-effectively and, most importantly, how do they get to great offerings?

They achieve these objectives by accepting that, although the vision for the journey can be had, the length of the journey is unknown, the amount of money required to accomplish is unknown, and the exact nature of the end product is also unknown.

This is very similar to the problem we find in most service transformations. We know the direction we want to head, but we can’t describe accurately and precisely where we’ll end up, can’t quantify how much it will cost, don’t know how many resources it will take to get there or how long it will take to get there. All of these factors vary. Yet, using the procurement methodology, we pretend we know these details and set up artificial constructs.

Applying the VC principles to transformation services

Why don’t we do what the venture capitalists do? First of all, they break the project down into a series of gates. The only detailed road map is the one between where you currently are and the next gate. That requires a detailed plan. One of the parts of the plan is to develop a plan for the next gate.

Using VC principles, the vision and the dimensions of what you want to accomplish are clearly stated. For example, “I want to bring the cost of IT down by 40 percent” or “I’m going to standardize my components and move them into an elastic or consumption-based model, and I’m going to develop agile vehicles to integrate the components.” But how you will do that and how it will involve your current environment is unknowable.

All that is knowable is how you develop a proof of concept and how you move from POC to rapid implementation. You can fund each step much like VCs do (Series A, Series B, and Series C funding) and break it down to create funding associated with milestones that get you to the next gate.

This is a broad application of the VC philosophy, and there’s much more to it. But I believe by applying these principles, we can change how we drive transformation. We can dramatically lower the interaction costs of the purchasing process, and we can spend that money and time instead on the actual transformation. And we can deal with our providers or ecosystem partners in a much more transparent and direct way.

It’s best to apply this VC-based methodology where the benefits of design and architecture drive the value, instead of price reduction as the driver. You can still get lower unit prices, but the old procurement process is dead. That process is useful if you’re trying to take a stable environment and reduce its unit price. But it is not useful where you are driving a transformational agenda, which cannot be precisely defined. Using the old methodology for a transformational agenda tends to waste time, frustrate ecosystem partners and create false promises.

Transformation Services Procurement: What’s Wrong with this Picture? | Sherpas in Blue Shirts

November 10, 2015

For large transformation projects, the services world has locked itself into a world permeated with high dead deal costs, wasted solutioning, and long transitions of nine to 18 months where the client sees low value and tries to get the provider to absorb the cost as well as expensive consultants and legal fees for the client on top of distracting management. And in the end, we have a lot of unhappy clients. This needs to change.

Remember John Lennon’s song: “Imagine?” Imagine a world in which we compress these cycles and we don’t have high transition costs. As Lennon wrote, you may say that I’m a dreamer, but I’m not the only one. Over the years there have been a lot of experiments in how to shorten the sales cycle. But largely they were frustrating. Even when you rush through the process, it still tends to straighten back out to the nine-plus months’ duration because it takes time for the enterprise to understand and absorb the journey and get to decisions. Others have experimented with sole sourcing, but it doesn’t really shorten the sales cycle and has a lot of limitations from the client side in terms of leaving them wondering whether they got a market deal, despite benchmarks and pricing assurance.

From studying this over the years, I’ve come to believe that as long as providers and clients define the goal in terms of procurement, they’re likely to be disappointed. The process and price become too influential and the provider loses sight of the client’s real goal. So they end up with incremental gains but not breakthrough, transformation gains.

Let’s think about these deals as transformation journeys instead of procurements. Just imagine ….

After all, the client doesn’t want the outcome to be a contract; the outcome needs to be a transformed state of the client’s process or capability. So we need to reconceive the origination of these transformation deals along this line.

We need to first focus on the benefits, defining the game-changing benefits the enterprise wants to build. Typically those benefits in today’s world have something to do with efficiency gains, cost savings, better aligning the process to the requirements of the business users, and improving the speed and agility to be responsive to the business needs.

If service providers stop thinking about the procurement process and think from the consumer’s point of view, it works great. The client gets what it wants and needs, friction is reduced, it’s clear what the client needs to reach its goal, and the provider gets to pull the client on the journey rather than pushing and selling to the client.

After defining the business outcome goal from the client’s perspective, the next step in developing a solution would be to develop breakthrough metrics to drive the change through the client’s organization. I’ll discuss this in my next blog post.

The parties build the journey together, and the client sees the solutioning as value rather than a sales exercise to be viewed with skepticism. In effect, this method turns the procurement process on its head and eliminates the sales cycle. The provider get paid to assist the client in solutioning rather than for building a complete construct to be compared to competitors’ solutions and examined at every level.

The result is a better outcome, focused not on contractual terms but on results for the client. And this process goes a long way to eliminate the nettlesome issues around the procurement transition phase because transition is accomplished as the transformation journey progresses. Just imagine.

In John Lennon’s words, I hope someday you’ll join us, and the world will be as one.

Tales of Outsourcing Horror | The True Story Edition | Sherpas in Blue Shirts

October 30, 2015

Despite all the successes in the marketplace, we all know there have been outsourcing arrangements that have gone terribly awry. So, in the spirit of Hallowe’en, I wanted to share some true outsourcing horror stories. But, be forewarned, and read on at your own risk…these true stories will send chills up and down your spine.

Sales process | the secret in the lab

A service provider’s salesperson and solution architect promised to a large enterprise client a transformational technological solution that would save considerable amounts of money, enable realization of all its objectives, etc. The client was very happy with the promise of the solution, as it knew similar approaches provided by other service providers had been successful for the buyer organizations.

But when the engagement moved from transition to presumable steady state, and the results were supposed to start coming to fruition, the provider’s on the ground team had no idea what the client was talking about. The salesperson and solution architect knowingly and willingly sold a solution that their company did not have and had no intention of creating.

Sadly, the secret in the lab for the client was that there was no solution. And not at all surprisingly, the deal faltered and the provider was terminated.

Transition | the monster under the bed

A client that had never outsourced before believed that transition management was the provider’s job, and thus chose to have no involvement in the process. Of course, without active participation from the client, things started to slide. The client began sensing things were going awry, but the provider consistently assured the client that all was fine. The client asked all the right questions, but because they weren’t actively involved, had no insight into what was lurking below.

When they got to the go live date, the provider listed a litany of things that weren’t yet ready, and in a real attempt to make the transition work, suggested alternatives. The client rightly questioned what impact the alternatives would have, but – looking at the situation from its own risk perspective, and truly wanting to fix the issues – the provider again assured the client there wouldn’t be any problems

Of course, there were massive problems. Missed deadlines, impossible turnaround times, finger pointing. The engagement became such a train wreck that no amount of corrective actions could recover the client’s original objectives.

Moral of the story? If you think there’s a monster hiding under your bed, don’t expect someone else to check for you. Actually, the real moral of the story is that it takes two parties to do the transition tango, and buyers must take management responsibility and accountability for their portions of the transition.

Governance | drinking the witches’ brew

For a number of years, a client was very happy with its ITO provider. It was productive, innovative, and collaborative. But, over time, the provider languished and lacked energy, and the initial objectives that everyone had been focused on seemed to die. Hard feelings grew, and eventually one person on the provider’s governance team developed an axe to grind with his client-side counterpart. Before anyone realized what was occurring, this influential person fed his witches’ brew to all his team members. The poison then spread to all the client’s governance team members. The bitter taste in everyone’s mouths grew until every meeting was a new, adversarial battle between the two separate factions. They could no longer work together toward a positive end result.

Ultimately, the only way the deal could be salvaged was by replacing enough people on both governance teams with new people who hadn’t sipped the poison.

On this day before All Hallows’ Eve, be aware that ghosts, ghouls, and goblins may be lurking in your deal. But also be aware that accountability, governance, and knowledge can help you spot and fight the bogeyman.

Photo credit: Flickr

Technology Is Advancing Quickly; So Why Are Organizations Changing So Slowly? | Sherpas in Blue Shirts

October 22, 2015

The pace of new technology is advancing exponentially. But organizations change so slowly. This is particularly frustrating if you’re a senior executive who sees the opportunity to drive efficiencies or value and by making big changes in your organization, yet you find it’s painful and difficult to drive change and you can only make incremental progress. It’s also frustrating if you’re a service provider trying to sell a new vision to a slow-changing organization. What causes the slowdown?

Incentive

People do what they are incented to do and what is in their best interest. Just because technology makes something possible doesn’t mean that people are prepared to change. And driving change is dependent on relationships with other people; highly dependent technologies also impact change. It’s not that individuals want to thwart change; it’s just that change will be thwarted because people always do what is in their best interests, as they perceive it.

Making a change in technology forces change in policies, processes and relationships; and that requires realignment. Alignment is complicated. It’s a combination of organizational incentives, personal incentives, metrics and what we measure, proximity to people, how we relate to one another and technology.

The tragic mistake that clients and providers so often make is believing that changing one aspect – the technology or perhaps a few people – will drive others to change. But it won’t. Driving change requires realigning the organization and ecosystem.

Complexity

Borrowing from the old adage, human behavior is like water – it flows to the lowest point or takes the easiest path. This is a defining principle about why Apple has been so successful: it makes it easy to operate an iPhone or iPad. When we fail to make those same accommodations and think through technology change thoroughly, we can’t drive the organizational and behavioral change we’re looking for.

Change and adopting new technologies is so simple for the architects and designers. But they fail to view it from the perspective of the people who will be affected by the technology. New technology requires creating new steps or more complexity; therefore, new technology is more difficult to utilize than the old technology people are accustomed to and trained on.

Often the new visions based on a breakthrough or change in technology rarely live up to their potential because the service provider only changes the technology or provide new technology to the aspects of the service for which the provider is responsible. So the remaining organization can’t or won’t change; it’s left with the original interests and metrics, and it won’t readily change to accommodate the new structure.

Bottom line

Unfortunately, service providers’ salespersons attempt to beat competitors’ offers by oversimplifying the nature of the change the client will need to undergo.

To ensure client satisfaction and to ensure the technology lives up to its potential, providers selling a new vision and making promises must be far more realistic around the cost and time it takes to accomplish the change from implementing new technology.

Tales of Horror: SOW Edition | Sherpas in Blue Shirts

October 19, 2015

Everyone involved in the deal-inking end of an outsourcing engagement has a love/hate relationship with SOWs. They’re necessary, of course. But, do their creation and iteration need to be painful? They don’t, but buyers and service providers tend to make them more difficult than they need to be.

Here are some of my SOW development tips to make everyone’s life a little easier.

No one knows what Risk Management is

Not even George Costanza from the Seinfeld television show. (If you’re a Seinfeld fan, you’ll catch the joke.) This is why it’s imperative to write clear definitions in any SOW you create.

E.K.W.A.Y.R.T (Not Everyone Knows What Acronym You’re Referring Too) – Every company loves their acronyms, but no matter how obvious you think they are, spell them out. You’d be surprised how many people you’re confusing
Where’s Waldo – In the definition of terms, simply writing, “as defined in the document” tells people nothing. Tell them where (e.g. “As defined in section 4.1”) and you’ll save readers a lot of searching
Change Management – Ask five people how they define Change Management and you’ll get some very different answers. Even if you think a term is industry standard, define it. You’ll save yourself a lot of arguments in the future on what was in-scope versus out-of-scope.

Redlines Redlining is Aan artArtartArt

I have an image of service providers sitting around a table, drinking Cognac, and laughing about how many redlines they will put into a document. If this is a real thing, please stop. It makes everyone but you sad.

Very Sneaky Service Providers– If you redline a document, and then ”accidentally” turn track changes off when changing part of the wording in your favor, people will catch it, and it won’t look good for you. Don’t do it
Jigsaw Puzzles – I love jigsaw puzzles, but having a service provider rearrange an entire document just for fun makes me cringe. Yes, we know you’re a provider, which means you think you walk on water, but organization can be done later. Focus on the content
Vulcan Logic – Always have an independent source re-read an entire document before submitting it to a buyer/service provider. Dividing a document among four different people then duct taping it back together doesn’t work. There are always contradictions, and it makes documents unclear and illogical. Star Trek’s Spock would not be impressed

Nay one und’rstands what ye are writing

We get it. You were an English major and studied Shakespeare, but the people who are going to live and breathe the contract likely weren’t and didn’t.

Shift+F7 – Using a thesaurus was great when submitting English papers in high school, but in a SOW, the simplest words often work best
Lawyers get paid by the word – Stay away from terms in a SOW that imply something is to be done. Use firm language like “will” and “must.” Don’t worry about what the lawyers will do after. Focus on making sure responsibilities are clear so the attorneys understand the concept, and then let them make their millions
Copy-Paste – Let’s be honest…we all re-use content. Copying and pasting great IP is great, if it flows. But it often doesn’t. It’s worth taking the time to rewrite a section, or very carefully reviewing your paste job, to make sure your document flows correctly.

Having anxiety attacks just thinking about working on your next SOW? These tips may be just the natural remedy you’ve been searching for.

Photo credit: Flickr

Automated Services Need a New Licensing Structure | Sherpas in Blue Shirts

October 6, 2015

Service Delivery Automation (SDA) encompasses cognitive computing as well as RPA (robotic process automation). Software providers that provide SDA come to market with an enterprise licensing structure that basically requires the customer to license a number of agents for a specific length of time. But in using this licensing model, service providers unintentionally constrain adoption and open the door for competitors’ differentiation.

The problem is that many of the uses for SDA are cases where companies need variable amounts of agents and computers. For example, the client may have a million transactions to process. So it could buy a license for one agent to run through those transactions in a week; but to reduce cycle time requires buying the license for 10,000 virtual agents for one hour. At Everest Group, we clearly see clients becoming frustrated with this lack of licensing flexibility.

This situation calls for a consumption-based approach to SDA in which the customer pays the software provider handsomely, but the provider doesn’t constrain or force unnatural motions on its customers and doesn’t create unnecessary cycle-time issues.

This blog is a call to service providers to come up with a consumption-based pricing model for SDA services. I’m not advocating that providers give away their software or take less money for it. I am saying that the current pricing structure inhibits adoption and is a constraint on the growth of the industry. Employing a consumption-based pricing model doesn’t mean that the client won’t pay a fair compensation or that the provider won’t be profitable. To achieve this, providers need to create some kind of metering vehicle in which time or activities are metered and they need to link their pricing to this meter.

Photo credit: Flickr

DevOps: Disruptive and Changing the Purchase of IT Services | Sherpas in Blue Shirts

October 1, 2015

Businesses now demand that IT departments dramatically change the velocity of the cycle time it takes to take ideas from concept to production – often from as long as 12-18 months to only four to six weeks. Organizations can’t achieve a change of this magnitude with just a change in methodology. To do this, they must move to DevOps – a disruptive phenomenon with immense implications for the enterprise IT ecosystem and the service providers that support it.

Put another way, many IT firms batch or create software releases once or twice a year in which they bring out updates to their enterprise platforms. Businesses now demand a cycle time of one to two times a month for updates. What they want and need is a continuous-release construct.

Methodology alone cannot create the conditions in which organizations can form ideas, build requirements, develop code, change a system and do integration testing in the new timeframes. Hence the DevOps revolution.

DevOps is the completion of the Agile methodology. It builds the enabling development tools, integrates test conditions, and integrates the IT stack so that when developers make code changes, they also configure the hardware environment and network environment at the same time.

To do this, an organization must have software-defined data centers and software-defined networks, and all of this must be available to be tested with automated test capabilities. By defining coding changes with network and system changes all at the same time and then testing them in one integrated environment, organizations can understand the implications and allocate work as desired. The net result is the ability to make the kind of cycle time shifts that businesses now demand.

DevOps implications

DevOps enables IT departments to meet the cycle time requirements. But the implications for how organizations buy services and how providers sell services are profound. Basically the old ways don’t work as well because of the new mandate for velocity and time. This causes organizations to rethink the technology, test beds, and service providers; and then manage the environment on a more vertical basis that cuts across development, maintenance, and testing, and allows the full benefit of a software-defined environment.

Let’s examine pricing, for example. Historically, coding and testing are provided on a time-and-materials basis. The productivity unleashed in a DevOps environment enables achieving approximately a 50 percent improvement in efficiency or productivity. Therefore, it is as cannibalistic or as disruptive to the development and maintenance space as cloud is to the infrastructure environment.

Furthermore, organizations can only operate a DevOps environment if they have a software-defined hardware environment – aka a private or cloud environment. This forces production into ensuring they perform all future development in elastic cloud frames.

Enterprises today are reevaluating where they locate their talent. Having technical talent in a remote location with difficult time zone challenges complicates and slows down the process, working against the need for speed.

So DevOps is a truly disruptive phenomenon that will disrupt both the existing vendor ecosystem and also the software coding and tool frames. Testing, for example, has been a growth area for the services industry, but DevOps environment largely automate testing services.

Another disruption is that DevOps takes a vertical view of the IT life cycle. It starts to integrate the different functional layers, creating further disruption in how organizations purchase IT services.

DevOps offerings are a new development among service providers, but the services industry to date has been slow to adopt the movement. DevOps is an internal threat to their existing business and requires providers to rethink how they go to market.

A Light Bulb Has to Want to Change | Sherpas in Blue Shirts

September 22, 2015

There’s an old joke that asks how many psychologists it takes to change a light bulb. The answer is it doesn’t matter; the light bulb has to want to change. I think this has a deep truth when applied to the services market.

Almost every service provider looking for growth sees that capturing a share of the transformational marketplace is key to their success. In their effort to pursue this, they come up with arguments and proof points that they can do a business function better, faster and more cost-effectively than shared services or the target organization. They then conduct significant analysis, looking at which customers would be the best fit for their strategy.

Unfortunately for these providers, their efforts often are frustrating and come to very little reward. The reason can be seen in the light bulb joke. The key to significant transformational change has less to do with the potential impact and more to do with the motivations of the client and its willingness to change. Few people can be squeezed to undertake the risk of a significant large-scale change and transformation.

Key for service providers

Service providers seeking to capture transformational deals must first identify senior executives with a change agenda and then gain an understanding of how they wish to change. That is where the transformation journey must start. Although this sounds obvious, my experience has been that providers rarely approach the problem from this perspective.

When you couple this starting point with the changing objectives of customers focusing on business value and cycle time instead of costs that I’ve blogged about before, it’s easy to understand why so many providers’ strategies fail. Looking for transformation opportunities through the lens of cost savings is a mistake, and increasingly the provider’s efforts will go unrewarded.

Just like the light bulb joke, transformation opportunities won’t happen unless the customer wants to change and the provider understands what the customer wants to accomplish through the change.

Photo credit: Flickr

Incumbents Beware – There’s No Place for Complacency | Sherpas in Blue Shirts

September 16, 2015

Used to be that if you delivered against the SLAs in your CCO engagements service providers could count on a pretty stable book of business. The formula was to deliver consistently solid service and continue to drive a compelling business case for clients. In fact, adherence to SLAs was often one of the top criteria against which the buyers we spoke to would evaluate the success of their CCO engagement. But times are changing. Everest Group’s research shows that delivering on SLAs is now table stakes. And despite the fact that CCO providers typically do a solid job delivering on SLAs, over the past 2-3 years the rate of contract terminations has edged up from 50% in 2012 to 60% in 2014. What’s driving this ongoing shift?

There’s more to the story than meets the eye. While terminations are up, so too is the number of net new contracts and the scope and size of existing active contracts. In fact, total spending on CCO services continues to grow at 5% CAGR. While this may seem slow compared to other services markets, you have to keep in mind that the CCO market is huge at US$75 billion in annual revenues, so the absolute spending growth is not insignificant.

A key point here is that existing contracts are now contributing the larger share of net new spending in the CCO market, with average contract sizes growing from US$32 million in 2009-2011, to US$51 million in 2014. This growth in spending tends to come from a notable expansion in process scope. Not only have we seen growth in the total number of processes clients are asking their CCO providers to assume on their behalf, a bulk of the incremental processes fall into the category of value-added services. Growing from an aggregated inclusion rate of 42% to 61%, this could involve processes such as channel management, customer retention, analytics, or performance management.

At the same time, major CCO buyers tell Everest Group they are increasingly looking for opportunities to develop deeper working relationships with fewer CCO service providers – essentially consolidating their portfolio of work with fewer strategic partners. The expectation of these relationships is that CCO providers will meet a larger set of client requirements through a broader range of capabilities, including process scope, geographic coverage, and industry specialization. We have already seen CCO providers responding to this shift in buyer expectations as evidenced by the number of acquisitions taking place in the market, targeting both growth in scale/scope, but also in terms of vertical industry and technology capabilities.

For service providers to hold onto their client relationships they must continue innovating their approach to client relationships, the offerings in their portfolios, and their willingness to broaden the definition of customer care services.

For more CCO insights, download a complimentary preview of our CCO Annual Report.

Photo credit: Flickr

Technology Specialists – The New Dinosaur in Making | Sherpas in Blue Shirts

September 3, 2015

Are you a brilliant Java coder? An expert in the R programming language? A phenomenal database administrator? A brilliant software seller? Sorry to say it, but you’re likely to soon be a member of the “extinct club.”

In corroboration of Scottish economist Adam Smith’s concept of the division of labor, organizations have historically preferred and hired specialists to develop their technologies, and other specialists to sell them. These masters of their craft had acclaimed expertise in their specific areas. And despite the evolution from mainframes to microcomputers to PCs to client server to ERP to the web, it was relatively easy for them to upskill or move to an adjacent skill, as the technologies adopted by companies rarely changed in their fundamental structure.

This gave rise to an “I am a developer, let me develop, I am in sales, let me sell” model within technology companies. It worked well, as enterprises persisted with outdated technologies they had intertwined their business models, and the cost of replacement was prohibitively high. This persistence created the specialists, who were assured of their place in the high echelons of technology as the landscape was not changing fast enough. This also gave rise to the outsourcing industry, which was leveraged to support these outdated systems and reduce the cost of management.

However, those times are gone. Due to digital transformation, organizations expect their professionals to understand not only the technology, but also business users’ perspectives, technology ease of use, consumption flexibility, and creation of top line impact. Development or sales specialists lacking a comprehensive business view are quickly losing their relevance and competitive edge.

Lack of relevance and competitive edge can, and will, also effect many technology providers. This is due, in large part, to the fact that as the cost of consumption of hardware and software decreases, organizations are increasingly willing to dismantle their existing systems and embrace newer models, e.g., migrating from one SaaS CRM to another. The idea of “fail fast, fail better” is gaining traction within enterprises, and technology companies need to align their business models accordingly to serve them.

The reality is that this sea change requires full-scale overhaul of technology providers’ entire business model – including their investment strategy, product roadmap, partnership ecosystem, and go-to-market approach. Yet executives in these businesses have made their careers and big money by developing and selling technology in a certain manner that promotes status quo. Think about a large software vendor and its partners who earn millions of dollars by just providing “certificate training” for their technologies. If the technologies become redundant, their bottom line will be severely impacted. Therefore, they will invest all their efforts in ensuring their clients stick to their technology platforms, irrespective of whether they are outdated and unable to cater to the business. Of course, there are buyers that do not want to rock the boat by changing something until it is really broken. This comfortable nexus has been going on for ages.

But the times are changing very fast. Technology providers that view their buyers as “cash cows,” rather than valuable partners to be helped to achieve business objectives, will fast lose relevance. The providers that succeed will: 1) embrace this new world of disruption, and create meaningful solutions that are more than beautified version of their outdated platforms wrapped in a pretense of user friendliness; and 2) make their prized specialists realize the new norm of the business wherein they need to at least understand, if not master, the art of viewing the world from a business and end-user perspective that incorporates a holistic paradigm beyond their usual tunnel vision.

If he were alive today, Adam Smith might well have changed his tune, instead suggesting malleable skills to enable technology companies’ success in these uncertain times of technology.

Photo credit: Flickr

Announcing our inaugural conference: Everest Group Engage, The Pragmatic Edge: Designing Your Future. Learn more.

Tag: advice for provider sales

What Venture Capitalists Can Teach Us about Driving Transformation | Sherpas in Blue Shirts

The fallacy of the procurement methodology

What can venture capitalists teach us?

Applying the VC principles to transformation services

Transformation Services Procurement: What’s Wrong with this Picture? | Sherpas in Blue Shirts

Tales of Outsourcing Horror | The True Story Edition | Sherpas in Blue Shirts

Sales process | the secret in the lab

Transition | the monster under the bed

Governance | drinking the witches’ brew

Technology Is Advancing Quickly; So Why Are Organizations Changing So Slowly? | Sherpas in Blue Shirts

Incentive

Complexity

Bottom line

Tales of Horror: SOW Edition | Sherpas in Blue Shirts

Automated Services Need a New Licensing Structure | Sherpas in Blue Shirts

DevOps: Disruptive and Changing the Purchase of IT Services | Sherpas in Blue Shirts

DevOps implications

A Light Bulb Has to Want to Change | Sherpas in Blue Shirts

Key for service providers

Incumbents Beware – There’s No Place for Complacency | Sherpas in Blue Shirts

Technology Specialists – The New Dinosaur in Making | Sherpas in Blue Shirts

How can we engage?

Contact Us