By Jagdish Dalal

George Santayana once wrote: “Those that fail to learn from history, are doomed to repeat it.” I also like what Albert Einstein wrote, “Insanity is doing the same thing over and over again and expecting different results.”

So it is for many providers who do not have a structured process for learning from their past performance. Customers expect their providers to continuously improve their performance. In a competitive world of outsourcing, providers benefit by reducing service defects, thereby improving customer satisfaction and their bottom line. After all, failure to meet performance levels ends up costing them in their margin – directly or indirectly.

Working with providers, I have encouraged them to use a formal “lessons learned” process. I advocate that this be an ongoing, established program rather than a periodic event.

Lessons Learned Process

It is a formal process and a foundation for quality review. It provides a method for clinically dissecting performance, documents factors impacting the outcome and creates a framework for learning. It is not a “witch hunt” or “who shot John” game. The intent of a successful lessons learned process is to identify factors influencing results and delve deeper into the root cause for each of them. Therefore, the process is designed to evaluate both failure – missed performance –and success– expectations met. In quality process, this is often associated with creating a “fishbone” (or Ishikawa) diagram. Let’s look at how to design and successfully conduct a lessons learned process.

Creating Lessons Learned Framework

A structured framework for the lessons learned helps not only in identifying factors but also as a learning tool for future performance. A typical “fishbone” diagram describes the outcome and then creates a set of categories for factors that affected the outcome. In a structured lessons learned framework, it is important to have these categories standardized, so that over a period of time, we can establish patterns and trends. The following diagram shows one of these standards that I have recommended to providers with whom I work.

Conducting Lessons Learned Exercise

It is essential that a lessons learned exercise is formal, consistent and involves all people that are directly, and at times, indirectly, engaged in the activity. As mentioned earlier, these exercises should be for both successful and unsuccessful outcomes, so that learning can be analyzed from both perspectives. I recommend the following seven step process:

1. Assemble the team that will conduct the exercise. A discussion leader and a scribe need to be appointed so that the meeting rules and etiquettes are followed. Ideally, the conference room is organized so that there are seven category flip chart pages and a separate flip chart for documenting brainstorming items. I have found that a conference room without chairs (where everyone is standing) is more conducive to brainstorming than people sitting around a large table.

2. Agree on the “head” of the fishbone, describing the outcome as specifically as possible. For example: “project metrics were not met” or “project completed ahead of schedule and under budget.” Clarify categories for everyone involved, so that they do not become a matter of interpretation later during the exercise.

3. Conduct brainstorming session. Typical brainstorming process is:

a. Each person (on a round robin basis) lists the contributing factor. These factors should be as factual as possible and not just “here-says” or opinions regarding the cause. Causes will be determined later.

b. As each person contributes a factor, no discussion takes place (except for clarification purposes only).

c. Round robin process continues everyone has exhausted factors to contribute (people can “pass” during the round robin if they have no new factors to contribute).

d. Document all of the factors on a flip chart (as they were stated).

4. Once brainstorming is complete, each of the factors are discussed, categorized and placed on the appropriate flip chart. Discussion can lead to adding more factors or eliminating ones discussed.

5. Once all factors are categorized, each category is studied to see common causes and a more thorough “root” cause analysis done. Root cause analysis is conducted by asking the question “why” until there can be no further drilled down. Typically it will take at least five “whys” to get to the root cause. These root causes, by each category are documented separately and if necessary, prioritized by their perceived influence on the outcome.

6. Final steps in the lessons learned exercise is to document these root causes, and projects created, to either reinforce their impact (if they resulted in a positive result) or come up with a solution to avoid/mitigate them on future projects.

7. Final outcome, lessons learned categories and root causes are then stored in a single document so that others can study them later and learn from past mistakes or accomplishments. When I worked at Xerox, we called this our “book of knowledge” and each project manager was required to study the book prior to launching a new project. This is a process that allows one to learn from history.

Honest, open lessons learned exercises and in depth assessment of root causes, helps create an environment where past performance becomes a guide for future improvements. As George Washington wrote in a letter to Fielding Lewis (July 6, 1780): “To rectify past blunders is impossible, but we might profit by the experience of them.”

Jagdish(Jag) Dalal is Founder and President of JDalal Associates LLC (JDA) and Managing Director, Thought Leadership for IAOP and a world-renowned consultant in the field of outsourcing. Dalal is a Certified Outsourcing Professional (COP®). He can be reached at JDalal@JDalalAssociates.com

By Steve Mezak

Are you interested in exploring the agile methodology for developing software at your company, but you’re worried that it feels like writing a blank check to the developer? It’s a commonly held belief among companies looking for outsourced software development that agile could potentially cost more than traditional methodologies. However, the nature of how agile development works, combined with a well-defined structure for funding it, ensures that you can produce a great piece of software without breaking the bank.

Two approaches to funding Agile – Fixed Budgeting Approach

The first step to ensuring that your company’s agile development meets your budget requirements is deciding upon whether to go with a fixed budget or continuous funding. A fixed budget is exactly what it sounds like–your company sets the maximum amount that they’re willing to spend for the software, and the development team works on the project until they hit the budget ceiling. Fixed budgeting is a good funding approach for companies that are not entirely familiar with the agile development process, and they want to make sure that there is a distinct budget cap.

Because the agile development process insures that you have a finished piece of software at the end of every sprint, you’re saving time and money with either continuous funding or fixed budgeting.

A fixed budget doesn’t mean you end up with an unfinished project. Instead, agile development works hand-in-hand with fixed budgeting because stages of the project (or sprints) are each completed within a set amount of time; at the end of every sprint you have a complete piece of software as well as an update on how much of the budget is left.

The development team covers the most important and critical features in the first sprint, shows you the result, and you give the  green light for the second sprint to add more features, work out bugs, or even take the software in a different direction if that’s what market conditions require. Though it may not be as comprehensive and feature-rich as you might want in the future, it’s still a solid version 1.0 that you can beta-test since the most critical features are already developed.

Funding Agile – Continuous Funding Approach

Continuous funding is typically used by more experienced companies that know how agile works and are confident in the development team. The company outlines what they need, the team figures out how long it will take, and they create a detailed prioritization of the product backlog of features, separating those features into a smaller backlog for each sprint. If they reach the end of the sprint without fully completing all the features, they take it out and move on with what works instead of dragging out the deadline for who knows how long trying to figure out just one bug. The difference between continuous funding and a fixed budget is that continuous funding allows the development team to work on critical and non-critical features at the same time because the budget allows for more time to continue working on various features rather than focusing only on the mission-critical ones.

The Best Part About Agile? You Save Money Either Way

Because the agile development process insures that you have a finished piece of software at the end of every sprint, you’re saving time and money with either continuous funding or fixed budgeting. Instead of waiting for months or years to see the end result, you get a real, workable update within a specific period of time, giving your company the opportunity to evaluate and decide whether the project is moving in the right direction. Having these mini releases also allows you to gather more funding because you can release the software, get feedback from your users (or the market), then see if it’s worth getting additional funding for an improved version, or determine whether it’s time to go back to the drawing board. Either way, the agile development process helps you make sure that your company doesn’t sink too much money into software development. The agile methodology does quite the opposite, in fact.

Steve Mezak is founder and CEO of Accelerance, Inc., which helps customers engage the right development team to create high-quality software. Read more and watch videos about using the agile methodology for nearshore software development on the Accelerance blog.

Capgemini, one of the largest multinational IT companies in the world with presence in 40 countries and more than 50 years of experience, will open a subsidiary in Bogotá to offer its services to local clients and subsequently to clients based in other Latin American countries while using Colombia as its regional base of operations.

“Colombia is a key country in our regional expansion strategy; it’s a country experiencing strong growth that has a very capable workforce and a very competitive cost structure. For that reason we decided to open offices here,” said Peter Kroll, Senior Vice President of Capegemini North Latam.

Proexport Colombia facilitated Capgemini’s landing in Colombia; the company will generate 400 jobs in the next two years. “’We look for computer scientists that have graduated from Colombian universities and we train them to provide Capegemini services to national clients and to other clients in the region,” explained Kroll.

“More and more companies from all sectors are requiring IT services, it is a growth industry in Colombia. According to the figures of the Superintendencia de Sociedades y el Ministerio de Tecnologías de la Información y las Comunicaciones, the principle companies in the sector earned around $550 million USD in revenue during 2011,” declared Maria Claudia Lacouture, president of Proexport.

The announcement happened at the 2012 ANDI Outsource Services conference where Kroll emphasized the potential of Colombia as an export platform to the countries that it has free trade agreements with and the opportunity to enter new markets such as the United States.

Capegemini has 108,000 employees worldwide and already has subsidiaries in Brazil, Argentina, Mexico, Guatemala and Chile. They specialize in maintenance of infrastructure and process applications, the implementation of business intelligence systems and ERP among other services.

Proexport, the entity in charge of attracting foreign investment to Colombia, offers services to interested investors such as tailored information in the form of contacts in the public and private sectors, accompaniment and scheduling related to country visits, and continued support to foreign investors that choose Colombia.

By: Linda Tuck Chapman

Developing and implementing consistent, actionable performance metrics for your Application Development and Maintenance and Testing program is one of the best ways to ensure you get value for money. One of the most important aspects of developing effective metrics is to resist measuring everything that can be measured. Focus only on measuring what matters.

According to CORE (Centre for Outsourcing Research and Education) research conducted in 2011,  one of the largest weaknesses found was that almost half of the organizations struggled to identify a compact set of metrics that aligned with business priorities. Over-abundance of metrics often obscured the core set and made it challenging for clients to aggregate relevant information and derive intelligent insights. Others recognized the issue not as a problem of quantity but of quality; stating that metrics were being tracked, but did not link to the organization’s ultimate goals.

This is an area where there is a tendency to try to measure too many things, often resulting in lots of data, plenty of noise but not much actionable information

No matter how complex or far reaching your metrics are, most managers pay attention to only a few metrics. In addition to simplifying the metrics measurement process, this guide to “best practices” will help you develop metrics that marry the relationship and performance information you really need with the information vendors can readily provide.

There are three types of Metrics that you should consider creating to measure the success of your program and vendor relationships:

1) Relationship level – these Metrics focus on how the relationship between the two companies is working, and how satisfied you are with their responsiveness and your access to their thought leadership and innovation.

2) Customer level – these Metrics focus on how well the vendor is performing tactical, “table stakes” tasks, like invoice accuracy and incident management.

3) Statement of Work (SOW) level – these Metrics focus on how well the vendor is delivering quality outcomes, on time and on budget, against each Statement of Work.

Measuring Performance

Relationship and Customer level Metrics are performance management tools and controls that are not unique to ADM and Testing vendor relationships. A good way to simplify governance processes and reduce workload associated with managing multiple vendors is to develop and deploy a generic set of Relationship and Customer levels across the population.

The primary focus of this article is on the SOW level Metrics. This is an area where there is a tendency to try to measure too many things, often resulting in lots of data, plenty of noise but not much actionable information. The best way to simplify your thinking about what to measure is to establish an overarching framework that addresses expected and important outcomes. By this I mean deciding how to group everything you want to measure into a few overarching categories. Three or four categories are simple to remember, easy to manage and simplify the communication process.

Grouping Metrics

I’d recommend grouping SOW level Metrics into “Quality,” “Efficiency” and “Effectiveness” categories, then creating sub-level metrics that align with each category. When you’re deciding on the sub-level Metrics, which are labeled “Type” in this example, give careful consideration to which metrics are referenced in best practices research coupled with what the vendor already measures internally. If you’re not sure what your vendors measure, just ask. They’ll appreciate your efforts to align your performance reporting requirements with their existing processes.

This is an example of “Quality” Metrics for Application Development and Maintenance. The Type column identifies the type of quality metric being measured; the Description specifies what is being measured; Waterfall or Agile refers to the software development methodology; Reporting periods can be set according to the timing of SOW deliverables, against major milestones or for long term relationships by quarter.

The same approach is taken to develop “Efficiency” and “Effectiveness” Metrics and any other categories you wish to measure. (Click on the chart for an expanded view.)

And here is an example of “Quality” Metrics for Testing: (Click on the chart for an expanded view.)

Conclusion

This approach is extremely useful for managing outcomes for each SOW and every vendor. Over time, you will have a sufficient volume of actual results for each vendor and every SOW. The data can be analyzed for opportunities and issues. You can identify fact-based opportunities for Project Teams and vendors to achieve better quality, higher productivity levels and lower costs. Ultimately, this is the most predictable way to increase the value for money.

Linda Tuck Chapman is a seasoned Outsourcing and Vendor Governance expert. You can reach Linda at (416) 452-4635, lindatuckchapman@ONTALA.com  or visit ONTALA Performance Solutions

By Leonardo Mattiazzi

Agile has been largely regarded as an ideal fit for today’s business challenges (for a reference, check the Forrester Research Feb. 2012 report, “Determine The Business And IT Impact Of Agile Development”).

And, from our experience, the business benefit of using Agile is magnified when it is coupled with the application of Lean principles, such as establishing a continuous flow of constant throughput. This principle, known as heijunka in the Lean vernacular, when applied to software development means creating a continuous delivery model, with a fixed-size team that undertakes several different projects one after another (of course, using Agile methods in each one of them). By doing so, we are able to eliminate several different sources of waste, and significantly decrease the actual cost of these projects (in our estimates, by at least 25% in the long run), as well as the total project timeframe from “Hello” to the application go-live.

Moreover, the ability to adapt during the course of a project (as well as in real life) is a critical part of success. Lean/Agile methods not only accept, but also embrace change. On the other hand, in a fixed-price engagement, the only way to fix price is to also fix the scope, so change becomes an evil enemy. That’s why Agile and fixed-price are intrinsically incompatible.

Still, even when companies are trying to adopt Agile, often times we are faced with an established procurement process that requires a fixed-price, project-by-project model – a model that is directly counter to the flexibility of Agile development and the benefits of a high-performance team working in accord to Lean principles. The irony is that the fixed-price model was designed to generate cost savings (through competition) and predictability, when in reality it only destroys value by creating several sources of waste. If you have been through this situation (or may face it in the future), and feel you need some help on clarifying why your company should break with the status quo and abandon those practices, you may find the following compilation of sources of waste quite useful:

Ramp-ups and ramp-downs

There’s always a learning curve at the beginning of any project. The development team needs to learn about and setup the technical environment, learn the basics of the business and get acquainted with the client’s team. In our experience, the third sprint of a new project has approximately 20 percent higher productivity rate than that of the first sprint. By going through this process every time a new project starts (as opposed to keeping the same team for a flow of projects), the only guarantee is that everything that was learned is thrown in the garbage – making the project more expensive and lengthier.

In addition, during the final phases of a “traditional” or waterfall project, there is a ramp-down, as not all members of the team are needed until the end. And with that ramp-down, resources are assigned to other engagements, so accessibility to valuable knowledge becomes limited. Of course, the remaining team members will eventually figure it out, but only after valuable time and budget have been drained.

Fixed-price embedded risk

In a fixed-price engagement, any provider that wants to maintain a profitable business will embed risk into the project plan. Rather than share goals and risks, the client pushes the financial risk to the provider by requesting a fixed-price, and provider pushes risk back to the client by embedding it into the budget. In these types of engagements, we are already off to a bad start, and the relationship then focuses on risk management rather than driving towards business goals, resulting in mediocre results at a much higher cost.

Management overhead

Due to this risk management behavior, too much time and energy is spent on project management. A project’s price can only be fixed if the scope of work is also fixed. So it then becomes the job of the project manager on the provider’s side to make sure the scope doesn’t change, or if it does, to justify a price alteration by proving that the scope was not clear in the beginning. The client-side project manager is then tasked with making sure the scope is very clear, so the provider cannot later claim otherwise. Time and energy are wasted detailing the scope and formalizing agreements, turning the project into a bureaucratic nightmare. Dollars are, of course, added to the project cost without generating any value.

So with one project manager defending the cost, and the other defending the scope, often they are at odds with one another. If there is a change, no matter how legitimate the business need is, it will create a stressful situation, a negotiation that may distract them from the overall project goal and often times drain their energy to the point of burn-out.

Defensive attitudes

As client and provider project managers have opposite goals, naturally, they become defensive. Instead of moving aggressively toward shared goals, every decision is made from a cost perspective, ignoring value generation. Agility is lost when every decision must be analyzed and then approved. With this defensive attitude, it is virtually impossible to complete a fixed-price project on time and on budget.

Sales and account management overheads

When every project is negotiated on a case-by-case basis, more work is created for the account management team as well. Proposals are lengthened to appear well thought-out and sales reps and account managers are ingrained to look for every opportunity to up-sell. These may not be direct costs to the client or provider, but you can bet they are often returned to the client in the form of higher prices. The time required to start a project also increases dramatically, as a lot of formalization is required. By contrast, in the continuous flow mode, a quick intake is needed for project estimates, which are either approved or not approved by the client, and the project may start just a couple of weeks after the first intake meeting, as the team is already in place.

Legal paperwork

As if commercial paperwork was not enough, there’s also the legal paperwork. Due to the defensive attitude previously described, lawyers from both sides tend to have a more prevalent role than is truly necessary. If nothing else, the timing of the project will be impacted by the multiple rounds of legal changes and approvals required before the project can begin. One can only hope that this doesn’t happen in the middle of the project too!

Of course, no development project will be perfect, but by utilizing Agile methodologies and a Lean, continuous delivery model, we understand how to avoid the waste associated with fixed-price projects. As more clients learn to identify areas of waste that lead to higher prices and lengthier projects, we predict that the continuous delivery model will become the preferred method for contracting and running projects.

Red tape, scalability, labor analysis, financial incentives and investment risk are among the burning issues for a Nexus panel joining together Ann Harts, Kevin Parikh and Fabrizio Opertti

By Dan Berthiaume

If you are a BPO professional and have had a sneaking suspicion in the past five to 10 years that contracts are getting more complex, it’s more than a hunch. For reasons including the growing importance of IT to the BPO equation, increased sophistication of BPO buyers, and the evolution of BPO beyond a means of lowering transactional labor costs, BPO contracts are growing more and more complicated.

To find out more details about the situation regarding complexity of BPO contracts, Nearshore Americas recently spoke with two BPO contract experts: Marc Tanowitz, principal at outsourcing advisory firm Pace Harmon, and Stan Lepeak, director of global research, management consulting at KPMG. Tanowitz and Lepeak discussed exactly why and how BPO contracts have become more complex, the effect this increased contractual complexity is having on the BPO industry, and how vendors and buyers can collaborate to reduce contractual complexity while preserving the integrity of BPO projects.

BPO Grows Up

The most basic contributor to the complexity of BPO contracts is the simple fact that as BPO matures, users want to do more with it. “Five to seven years ago, BPO was focused on labor arbitrage,” says Tanowitz. “It was about finding resources in low-cost locations to do what they were told.” Tanowitz says this earlier iteration of BPO mostly dealt with broad transactional work such as accounts payable (AP) and general ledger.

However, according to Lepeak, more recently BPO has become a vehicle for delivering more sophisticated services. “There is now a more broad scope,” he says. “Multiple processes are pulled together and there is an offshore element.”

Technology Creeps In

Another major factor Tanowitz and Lepeak both cite was the growing importance of IT to outsourcing, even to BPO projects that don’t primarily focus on outsourcing technology systems. The increasing role of IT in BPO is also a reflection of outsourcing’s growing scope and sophistication.

“Now you often find IT bundled with business processes,” says Lepeak. “Companies also outsource the infrastructure supporting processes.”

Tanowitz’s commentary echoes that of Lepeak. “The BPO market shifted from labor deals to deals with a large IT component,” he says. “Providers deliver analytical support for discrete business processes, such as a collection tool.”

BPO Buyers Want More

Tanowitz and Lepeak both also refer to a maturing of BPO buyers along with a maturing of the BPO market. “BPO contracts were originally fairly simple, some were even written on vendors’ contract paper,” says Tanowitz. As a result, contracts were heavily skewed in favor of vendors, providing them with protections while not giving buyers the same level of protection or options for adding services or changing scale as their needs changed through the life of the contract.

However, Tanowitz said that eventually BPO buyers became more savvy and started demanding service level agreements (SLAs), price benchmarks, and other considerations which better protected them in the event of changes in project scope, currency value or vendor performance, but also greatly added to contract complexity.

Lepeak says buyers actually became “unrealistic” in their demands. “For example, BPO buyers wanted big cost savings, but no offshoring,” he explains. “Or they wanted to put in an ERP system but not change their processes.”

Lepeak vendors who did not have experience in delivering these types of sophisticated BPO services agreed to unrealistic contracts, “Which is why most of the big BPO deals of six to seven years ago were flops.”

Finding a Contractual Balance

Tanowitz and Lepeak both agree that the worst days of BPO projects being held up or resulting in vendor-buyer disputes due to contractual complexity are over, but the industry can still do much more to relieve complexity without damaging the quality of service delivery. Lepeak says buyers need to find a balance between pushing too hard and settling for too little, while having realistic expectations of BPO innovation.

“In reality, it is difficult to create a contractual arrangement that guarantees innovation,” he says. “Innovation comes from taking risks and doing things outside the box, which are hard to put in a contract.”

Instead, Lepeak says buyers should understand that lawyers and risk managers representing both parties in a BPO contract will likely nix anything that seems too risky, and accept the fact that well-written BPO contracts “offer less innovation but fewer failed deals.”

Tanowitz offers what at first sounds like a counterintuitive strategy of making contracts more complex upfront to provide more flexibility later in the life of the contract. “Do it right, do it once,” he says. “Deals change. Service levels may need to increase or be relaxed. Put in the mechanisms upfront to enable changes (without having to renegotiate the entire contract).”

By Steve Mezak

The emerging HTML5 standard will make it a lot easier to deliver more graphical and attractive Web pages to more and more devices (especially mobile devices). That makes it a big boon for Web developers, and also a great fit for Nearshore developers with an eye for good design and local tastes.

HTML5 Defined

HTML5, which most browsers already support, is the next step in the evolution of the hypertext markup language that controls how information is presented in Web browsers. It will make it easier for users to access audio and video by integrating audio and video support into the browser, rather than requiring the user to download and install plug-ins. The HTML page essentially becomes a container for other containers, which contains other containers, and so forth; JavaScript can easily access those containers, modifying, updating, and moving them around.

Another capability of HTML5 is that it gives developers greater control over presenting information from different sources on the same Web page. Conceivably, if you have multiple Web apps running on different servers or different sites, you have the capability to select bits of information and then reintegrate and display that information together using HTML5.

Use Cases

Why is that important? On the consumer side, for example, you would have the ability to present a news, entertainment, gaming, shopping or social site to mobile consumers that aggregates content in a new way from multiple sources. On the business side, you could create a Web site for, say, corporate real estate managers that gives them instant updates on demographic, zoning, traffic flow and other information to comparing potential retail sites.

You need graphic designers as well as programmers – two different kinds of skills – that need to work well together when creating a web application.

Such capabilities are especially valuable when they’re available on mobile devices, and this is another area where HTML5 shines. Rather than forcing developers to write a native application for every mobile platform (i.e., Apple vs. Android vs. Blackberry) HTML5 can automatically recognize variables such as screen size and automatically tailor the display to the device. With mobile devices rapidly becoming the “screen of choice” for business users and consumers, that’s a huge benefit.

You need graphic designers as well as programmers – two different kinds of skills – that need to work well together when creating a web application. Good user experience and graphics design requires a cultural component — that is, an awareness of the visual images and metaphors that will be instantly recognizable to the end-user of the web app.

The ability and willingness for a Nearshore developer to assemble a team that has both kinds of talent is critical. The good news is that, if they can create such a team, the Nearshore cultural affinity with the U.S. makes Nearshore developers well-suited to these demands, compared to other places around the world.

Steve Mezak is founder and CEO of Accelerance, Inc., which helps customers engage the right offshore/nearshore software development team to create high-quality software. Read more about HTML5 on the Accelerance blog.

By Luke Bujarski

Last week’s Bloomberg Latin America Investing conference in New York City was a sobering reminder of Brazil’s precarious economic balancing act hinging on foreign investment, consumption, government stimulus, and inflated commodity prices. Yet, despite mixed signals over the future macro outlook, Brazil’s IT services industry will continue to rage forward. Antonio Gil president of BRASSCOM shrugged off pragmatic panel concerns with confidence, reassuring the audience that IT will expand aggressively at ten percent annually, to reach $210 billion USD by 2020. We believe Antonio’s assertion is correct: Considering this country’s infrastructural challenges and consumption-driven expansion, the public and private sectors will turn to information technology to squeeze greater efficiency out of their operations.

This year’s Bloomberg Latin America Investing conference showcased the top brass of LatAm policy and investment experts, including our very own Alvaro Uribe who keynoted Nearshore Nexus 2012 the week prior. Two camps developed with pariah states Argentina and Venezuela in one corner, and tiger economies Mexico, Chile, and Colombia in the other. The “Nascent Giant” Brazil took center stage driving the conversation around macroeconomic stability and domestic market investment opportunities across the region.

Brazil’s Long-Term Macro Outlook Uncertain

An overvalued real was the major source of debate as investors wondered how long Brazil’s recent local bond rally can last. “The six interest rate cuts [Banco Central do Brasil] since July of 2011 proved to be a risk that paid off,” explained Chris Garman, Latin America Director at Eurasia Group, referring to a steadfast inflation rate. Despite the positive short-run returns on Brazil’s debt market, the country’s fundamentals were put into question. Brazil GDP grew only 2.7 percent in 2011 compared to 7.5 percent in 2010. Panelists and audience inquiries also challenged Brazil’s trade balance with the US, which swung from a $6.4 billion surplus in 2007 to an $8.2 billion deficit last year, as the real rallied and growth in Brazil spurred demand for imports. Moving beyond the impacts of monetary policy, attention swung to government spending and the deep-rooted infrastructural challenges facing Brazil.

“The long-run problem for Brazil is structural and nothing that short-term monetary policy can fix,” argued Joaquin Cottani, Chief Economist for Latin America at Citi Investment Research and Analysis. There is not enough investment in infrastructure, education, and health care.” Brazil is expensive relative to other emerging economies which puts a premium on the cost of labor, impacting the competitiveness of its manufacturing and professional services sector.

Will Argentina’s takeover of YPF kick off a new wave of government takeovers in Latin America and send foreign investors scurrying?

An overvalued real – arguably driven by US fiscal policy and quantitative easing – brings down the cost of imports sending Brazilian consumers into feeding frenzy. While China is an export economy, Brazil’s growth feeds on domestic consumption spurred on largely by a growing middle class and government programs targeting poverty reduction. Any fundamental change to fiscal policy is also unlikely, as long as economic growth is perceived as strong. “The Brazilian people have a positive and trustful relationship with government,” expressed Ernesto Araujo Minister Counselor of Economics at the Embassy of Brazil – which puts into question Dilma Rousseff’s ability to make hard choices when it comes to corporate taxation, public infrastructure spending, and direct subsidies for the country’s poor.

High Costs Will Drive IT Automation and Innovation

According to Antonio Gil of BRASSCOM, “pressure on enterprise to bring cheaper and better products to market will fuel IT demand for the foreseeable future.” Brazil’s expensive operating environment will propel IT as an enabler of enterprise agility. In a high cost and consumer-driven market like Brazil, companies look to cut costs across supply chain, back office, and procurement. Government will also look to IT to make health care delivery, education, and transportation more affordable to the masses. Brazil’s high labor costs also leave less room to ignore the value of IT-driven automation and operational efficiency. “Every week I have international IT investors coming to our offices inquiring about new acquisition targets and new market opportunities,” explained Gil.

Cate Ambrose Executive Director of the Latin America Venture Capital Association (LAVCA) also pointed to consumer-focused verticals for new market opportunities. “Anywhere where there is a direct connection to the consumer is where we see new companies and new applications for IT.” Ambrose pointed to retail, health care, and education as the hot sectors with the most startup and innovation activity.

Not Out of the Woods Just Yet

Brazil finally appears to be on the right track toward sustained economic expansion, even if GDP growth rates slumps below Wall Street investor expectations. By all accounts, the days of rampant hyper-inflation seem to flicker in the review mirror. This new epoch of stability should keep IT investment dollars flowing. Yet, Lawrence Goodman, Founder of the Center for Financial Stability warned to never underestimate the power of global economics and the impacts of external shocks. Will China’s slowdown prove to be a hard or soft landing and how will that impact Brazil’s commodities exports? Will Argentina’s takeover of YPF kick off a new wave of government takeovers in Latin America and send foreign investors scurrying? Will a growing European crisis derail global economic progress?

By Robert L. Scheier

Service level agreements (SLAs) are the heart and soul of many outsourcing contracts. They define what the provider must deliver and their penalties for failure, in anything from application uptime to the time required to solve a customer’s problem on a help line.

But at least as currently defined, SLAs often fall short of detecting (and, more importantly, correcting) problems quickly. That was the message at the recent SIG Spring Summit from Senior Corporate Counsel Richard English of Ingram Micro and Shaalu Mehra of Sheppard Mullin Richter & Hampton, who helps the electronic distributor negotiate outsourcing deals.

SLAs fall down, said Mehra, because they don’t change with the customer’s requirements, aren’t defined precisely enough, and often aren’t structured to do a root-cause analysis of the root problem behind multiple failures.

“I love SLAs,” Mehra said in a session on “Best Practices for Ensuring Quality of Service in Multinational Outsourcing Engagements.” However, he continued, they are limited because they are just one “data point” measuring a provider’s performance.

While SLAs are the subject of intense negotiations at the start of engagement, he says, they may not be based on the right metrics to measure the effectiveness of the outsourced service for the customer. In addition, he said, SLAs “can be undermined by even minor changes” to the processes or systems they measure, and are often not updated often enough.

Another factor that limits their usefulness is “single incident limitation, (which makes) root cause analysis subject to an agreement of the parties,” said Mehra. Understanding and correcting the reasons for past failures can also be hindered by what English called a “statute of limitations” requested by vendors on how long a customer can ask for a service credit after a failure.

Both strongly suggested using a common approach to SLAs and other terms with all outsourcing providers, regardless of their location. “While that company may be India-based, and might be doing work for us in Asia, or might be doing work for us in Latin America…we don’t care,” said English. “We’re going to build in one global SLA.”

Two areas where the pair said specialized SLAs might make sense were to measure English language fluency and attrition. While Mehra agreed that “fluency” is subjective, he said it could be measured through a sampling of calls or surveys of whichever end users were being served.

Mehra said such SLAs often measure attrition on a rolling 12-month basis, and is an area where definitions (such as whether promotions, reductions in force or departures for personal reasons count as attrition) are often the cause of hard bargaining. “However reasonable the vendor’s concerns may sound, at some point, we have to draw a line” about where and how the customer will be protected from excessive turnover, he said.

In addition to SLAs, Mehra recommended regular payments based on the achievement of milestones, as well as periodic payments with provisions for holdbacks as a penalty to the provider for failures in delivery.