Ninety percent of CIO's will be "maintaining or increasing offshore outsourcing projects in 2010 and 2011," according to the 2010 Global CIO Survey, recently published by the UK-based firm, Harvey Nash. Interestingly, the majority of the projects (62%) outsourced by the surveyed executives fell into the category of "software development," demonstrating just how common the distributed development model has become.
When eWeek reported on this survey, their article ended with the following:
Despite the cost savings, offshore outsourcing and hybrid models that mix onshore and offshore services come with their own set of issues. As the study points out, business culture and project expectations are not always on the same page. From the Harvey Nash report:
"For both CIOs and their outsourcing providers, the key statistic that continues to cause concern is a growing level of dissatisfaction with project management standards, despite the overall popularity of the offshore outsourcing model."
Problems involving "project management standards" or "business culture and project expectations" inevitably stem from problems inherent in the relationship between a client and an outsourcing partner. Which means that the solution to these problems requires more than simply implementing a more well-defined project management process.
Instead, you have to move beyond the concept of outsourcing altogether and focus on building relationships with your partners (onshore, offshore, or even in-house) that will determine the success or failure of any particular process, project management or otherwise, you hope to implement.
So what goes into building relationships that will allow you to establish and maintain properly aligned expectations? Consider these three:
You can't set realistic expectations for a project's outcome, let alone assess a project's current status, without openly discussing these expectations up-front and planning for regular formal check-ups along the way. However, even more important than kick-off meetings and scheduled reviews are ongoing, as-needed, just-in-time communications between the teams themselves (both in-house and off-shore) and between the teams and the business owners of the project.
Facilitating this kind of communication requires picking the right tools, establishing a work culture that encourages ongoing conversations throughout the process, and staffing teams with people who are comfortable working in highly communicative environments.
In addition to a proper level of consistent, open communication between partners and teams, you also need to maintain fairly advanced level of collaboration (which communication certainly facilitates). To ensure that expectations are being met on both sides, it's critical that people not only work together to accomplish goals, but that these goals themselves are mutually determined and defined.
To foster such collaboration, its critical that you choose a partner that you can work with from a project's very inception. Inviting this partner's input on project definition and strategy is very different, and will have different results, than simply selecting a partner who you believe can execute on your vision.
Collaborative goal-setting not only promotes clarity, it also fosters commitment. If you want to see expectations met, then build a partnership in which the goals (even risks and rewards?) are shared by all the constituents. People will work hard to meet and exceed expectations not only when it is in their interest to do so but also, and more fervently, when they are invested in doing so.
Sometimes, the easiest way to reinforce this requisite commitment is to create a more unified sense that "we're all on the same team." Open communication and end-to-end collaboration go a long way towards erasing strict lines between client and vendor (or "partner and partner," if you like), but they too can be supplemented with "cultural" elements, such as badging and signage, to provide a lived sense of esprit de corps, especially on the off-premise side of the partnership.
Of course, on this last point the key is leaving "outsourcing," and it's implication of "just throwing stuff over the wall," behind. The question is, are many CIOs ready to do that?
Here are five links from the past week that we found intriguing. Hope you do too!
- Do You Need a Cloud Strategy? - Sand Hill's Kamesh Pemmaraju starts a series on the importance of developing a cloud strategy for the enterprise. Before you can do so, he insists, "It's critical that you develop a system for understanding and classifying applications and data corresponding to ... business needs." His framework for analyzing this "application landscape" struck me as thorough, practical and forward-looking.
- Top 100 Agile Books - Jurgen Appelo created this list while attending the Agile2010 conference (where we've been discussing Agile effectiveness for the past few days). The list represents a very current and fairly exhaustive virtual bookshelf for Agile practitioners.
- Investors Shy Away from Software Tools - Brief story from Alex Handy at SDTimes.com on the increasingly tough market for software development tools. The problem? "[D]evelopers don't like paying for things.”
- The Secret Relationship between Enterprise Architecture and Outsourcing - In which one James McGovern encourages organizations to embrace the full range of communication channels (including the emergent social media) in order to increase the efficacy of outsourcing engagements. Or, as he puts it, "For every organization that has attempted to outsource and has failed, I bet I can show you a culture that uses facetime as a crutch." Provocative stuff.
- Closing the Gap between Business and IT - Ivar Jacobsen posted the deck from his presentation at IBM's Innovate2010 conference in June. It's rife with implications for the proper relationship between businesses and their development partners. For example, he reminds everyone that, "Business is not IT's customer." As he explains it, they both share the same customer and should therefore work collaboratively to meet the customer's needs. Doesn't the same hold true for global development centers and their clients?
What did you find intriguing this week?
Editor's Note: If you'd like to go right ahead and take the virtual tour of our Software Product Labs, be our guest. If you'd like first to be swayed by our thoughts on trust, partnership, and the collaborative experience in global software development, please proceed.
When you entrust your development work to an external team, regardless of where they sit, the experience of working together is almost more important than how well they write code.
Don't get me wrong, technical performance matters. The end product needs to reflect the qualities people associate with your brand, just as it must meet the internal standards you have set for the work you do. That's a given.
However, when you are choosing a partner, especially one with whom you will need to work closely over a period of years, your selection will be guided by more than whether or not "they can do it."
As odd as it may sound in a business context your selection of a global development partner - and you have many from which to choose - will be guided by feelings. How does it feel to work with this organization? Is the experience imbued with a true spirit of collaboration? Is it marked by ease of communication and mutual understanding? Is there a shared sense of commitment? And most importantly, all along the way, do you feel that you are both invested in the success of the partnership itself?
Unfortunately, trying to describe "The Experience,” even in words that are aspirational and inspiring, inevitably falls flat. No matter how eloquent, our phrases will certainly echo and be echoed by those of our competitors. We all promise a positive, collaborative, and rewarding experience, but how can you know what it's like until you've actually experienced it?
One way of course is to ask current clients - people who are having or have had "the experience" - but generally that step is reserved for much further down the sales process. So, if you are curious, but not quite ready for that step, Ness Software Product Labs team created a virtual tour
of the lab environment so that you could, at least virtually, get the basic feeling of what we're about.
The quick tour takes you through some of the elements of what it’s like working with Ness, introduces you to some of our people, includes a few client stories, and gives you a chance to "meet" our COO, Raja Nagarajan. Take a look, let us know what you think.
Of course, if you'd just like to speak with us or our current clients, we'd be happy to arrange that as well!
In the world of software development, the days of outsourcing are coming to an end. In it’s place, we see the rise of long-term, globalized partnerships that nurture collaboration and focus on business outcome rather than project output.
This was the message delivered by Raja Nagarajan, SVP of Ness Technology Managed Labs, at the European ISV Convention in February and his vision suggests a radical rethinking of the way that ISV’s view the global development resources on which they increasingly rely.
Specifically, ISVs need to think of these resources in the framework of a sustainable business partnership, one that can serve as a platform supporting the entire product lifecycle, rather than isolated or even inter-changeable point solutions.
For example, when ISVs first began outsourcing, they often had a very narrow focus, “Let’s do everything in India. Let’s do everything in the Ukraine. Let’s do everything in China. Etc.” The geographic location of resources, and the assumed costs associated with these locations, drove the thinking.
Are there talented technologists to be found in these and other places? Of course. But the decision to work in this or that country should be guided by the desired business outcome and whether or not the technical expertise available in a particular locale matches this business need.
In order to determine what is going to work best where, the ISV will need a partner that not only has truly global capabilities (that is centers of excellence in multiple geographies) but even more importantly, possesses an approach that fosters collaboration, enables innovation, and promotes ongoing success.
Those may sound like bold claims, but if the partnership is going to function as an R&D platform, in other words, a critical and reliable part of your business (not just your operations), it needs to demonstrate these capabilities.
1. Foster Collaboration
Whether the resources are off-shore, near-shore, or on-premise, they need to work together. To make that happen, you need processes in place (ideally, Agile processes) that enable communication between the various teams, dependencies that create a shared investment in success, and a work-culture that instills a sense of unified purpose.
2. Enable Innovation
When your talented people collaborate, they discover what works, what doesn’t, and why. When you harvest and share this knowledge freely, and when you place a continuous emphasis on growing and leveraging this unique, experience-driven knowledge base, you enable innovation not just here or there, but across the partnership.
3. Ongoing Success
Success in one particular project is not true success. You need to be successful from Point A to Point B and from Release 1 to Release 2. You also need to successfully sustain past releases to keep the revenue stream active as you build for the future. A partnership becomes a platform when it can deliver success across all points of the lifecycle from R&D to testing to sustenance and beyond.
If you are an ISV, you should ask yourself: Do my global partners offer me an actual product lifecycle platform? Do I even think of them as true “partners”?
If you answer “no” to those questions, what are you going to do to build or find the kind of partnership your business needs?
Image Credit: http://www.flickr.com/photos/skutchb/ / CC BY 2.0
"I already have the tools," Amit Gupta told me when I called him in Bangalore to talk about collaboration and distributed software development.
The reason for my call was a recent Forrester study on the state of collaboration software adoption. In this report, the author argues that collaboration software vendors need to move beyond the "reduces travel costs" argument and begin to shape the way that business leaders think about the benefits of collaboration more broadly.
I contacted Amit, who is Program Manager for Ness's SMART Collaboration Platform, to get his take on just how one might go about quantifying the operational benefits of effective collaboration as recommended.
In the course of our conversation, though, I began to realize something that these software vendors might not want to hear: no matter how versatile the technology, it is by no means the key to collaborative success.
"There are numerous collaboration tools, of course, and we rely on them quite extensively," Amit told me. "We're using Confluence, which is like an enhanced Wiki for community collaboration, and we've integrated that with Jira, our issue tracking application, as well as GreenHopper, the requirements tracking tool we use as part of our Agile implementation.
"And all this on top of our development tools: PMD, JUnit, Clover, Bamboo, and so on."
"But you see," Amit said, "these tools are just tools. They enable collaboration, yes, but collaboration does not depend on them. It depends on at least two other things: solid engineering practices, on the one hand, and a commitment to continuous improvement on the other.
"This last part is very important. In addition to allowing you to automate and support your common practices, any collaborative platform you choose should provide the capability to monitor and report on progress towards project goals," Amit said.
"When it's all there in black and white, when you have visibility into what's working and what isn't, it allows you to make decisions about where performance can be improved and what should happen next."
This insight-driven feedback loop has far-reaching consequences, Amit also pointed out, because the insight that allows you to solve a problem or refine a process on a given engagement becomes part of a growing pool of knowledge drawn from, and eventually re-applied to, every engagement.
"In our Software Product Labs," Amit explained, "we always develop unique engineering practices with our clients based on their objectives and their specific needs. At the same time, we're continually gathering best practices in the areas of testing, sustenance, support, HR, etc. that can be and are emulated elsewhere."
I would say that this adds a third dimension to collaborative success: your choice of partner. If this partner can bring a wide range of collaborative experience to bear, your own collaboration efforts will be that much more fruitful.
Yet, even with all the pieces in place - solid engineering practices, insights for continual improvement, an experienced partner - you've still got the question: How can we measure the impact successful collaboration?
When I posed this to Amit he conceded, "It is not easy."
Nevertheless, he offered the following suggestion on how it might be done.
"What if you have product releases that are always getting rolled back due to quality issues?" he asks.
"If you focus on your engineering practices, utilize the best tools, and - and this is of the utmost importance - use the insights provided by the technology to continually improve and accelerate your processes, that should produce results you can document and measure."
"Think of it this way," he adds, "as quality improves, rollbacks should decrease, and you should get better product to market more quickly. You can measure defects. You can measure time to market. You can know whether you meet deadlines or not. But then again, measuring this sort of impact itself takes time. It's not something that can be measured from one day to the next."
This led me to wonder, "Are there more snapshot-like measurements of collaborative efforts that could be used to demonstrate value more quickly?"
Well, are there?
Image Source: http://www.flickr.com/photos/s2art/ / CC BY-SA 2.0
“It’s 2010. Why are you still outsourcing?” was the question posed by Ness’ Holly Ripley-Boyd in a recent conversation with Maryann Jones Thompson of SandHill.com
It might seem like an odd thing for someone who works for a “specialist offshore software development firm” like Ness to ask, particularly when Ness’ Software Product Labs are described as “a leading provider of outsourced software product engineering services.”
However, when Ripley-Boyd describes the approach taken by the Labs, and the reasoning behind it, the aptness of the question becomes readily apparent.1. Software end users care less and less about how the product is built.
Indeed, if end users ever cared where a software product was developed, they certainly don’t today. (Frankly, they probably assume that it has been developed “somewhere else.”) Moreover, they certainly don’t care where the code resides or where the software is hosted, preferring more and more the “as-a-service” model and paying as they go.2. The software development process is not simply a question of supply chain management.
Ripley-Boyd calls the second era of software development “The Rush Offshore,” pointing out that this stage was driven by the desire to take advantage of cost arbitrage and involved effectively reducing isolated elements of the software development process to nodes in a supply chain. Unfortunately, this inherently anti-collaborative approach meant that money was saved at the expensive of the one thing users actually care about: Quality.3. Long-term partnerships, continuous collaboration, and a “one-team” mentality are the way forward.
What is the true alternative to outsourcing? Building a dedicated partnership with an organization that will focus on the product (as opposed to this or that project) while providing “innovative, domain aware, globally delivered software services.”
Are there cost savings to be realized by accessing a global talent pool? Certainly.
But these savings pale when compared to the value of working, across every stage of the product development lifecycle, in collaboration with a global network of software developers who share an unparalleled range of experience and depth of ever-increasing knowledge.
Doesn’t that sound better, even ideal?
So why are you still outsourcing?
“The major driver of Offshore or Near-shore ‘investments’ has been cost arbitrage,” IT Europa’s editorial director John Chapman told attendees at an executive event Ness sponsored last November. And, indeed, companies have found that they can reduce development costs by 24% on average by relying on offshore or near-shore development resources.The problem is, of course, that success in the field of software development depends entirely on how well you do it, not how cheaply you do it.
Cost is always an important consideration, but it's not the main thing. Indeed, research has fairly consistently demonstratedthat the actual barriers to success in global software development have little to do with cost and more to do with “... ‘language and cultural barriers’, ‘country instability’, ‘lack of project management’, ‘lack of protection for intellectual property rights’ and ‘lack of technical capability.’”
Of theses barriers, which are the most difficult to overcome?
Assuming that “lack of technical capability” and the wage differences that account for cost savings may be related, this is certainly an issue that can be addressed by improved recruiting, training, and retention methods.
As far as national stability or the status of intellectual property rights in this or that locale go, few corporations can directly influence what the political situation in-country, but they can choose partners located in relatively stable geographies with a healthy respect for the rule of law.
With those barriers out of the way, however, organizations looking to tap into the rich pool of talent and accumulating years of experience to be found beyond the borders of the United States and Western Europe are still faced with the more vexing issues of culture/language and remote or distributed project management. What is the best approach to overcoming these obstacles?One conclusion reached at the executive event mentioned above was that “shared vision and commitment to collaborative partnerships” results in better outcomes and thus that the path to success entails “cultivating a shared sense of ownership for the mission.” The beauty is that taking this path goes a long way towards solving both the cultural as well as the project management issues. So how does this work?
1. Think Product NOT Project
In order to get the most from your engagement with offshore or near-shore partners, you need to think in terms of the product you are developing and involve your partner or partners as early as possible in the concept, design, and architecture stage. Collaboration needs to begin at the beginning, otherwise you lapse into a “throw it over the wall”-mentality that naturally encourages your partner to throw it back over when they’re done, with little or no concern for the overall objective: a great software product.
2. Never Underestimate the Importance of Face-Time
To begin building bridges across any cultural divides that may exist, as well as to lay the groundwork for effective and ongoing project management, it’s critical that the various team members (in-house, near-shore, offshore) actually spend time together, particularly at project launch.
We’ve written elsewhere about the importance of these in-person meetings for implementing Agile software development methodologies in a distributed context. But more than that, these meetings, by demonstrating a commitment to true collaboration, go a long way towards developing the kind of esprit de corps that leads to personal engagement and investment at every level.
3. Choose the Right Partner
Of course, all this upfront engagement and strategic face-time will be meaningless if you are engaging and meeting with the wrong partner. If you are thinking in terms of relevant technical expertise and experience, it may be relatively easy to find the correct partner - just look at the products or projects they’ve worked on in the past.
What is difficult, however, is finding a partner whose team members not only possess the skills that complement those of your in-house group but who also possess the ability to effectively and consistently work together with these folks (after all, “collaborate” means “work together”).
Beyond this immediately personal level (“will these people all get along”), though, you also need to look at the partner organization and ask, “Are they as ready and willing as I am to sustain a long-term commitment to a meaningful, collaborative partnership?”
When you can ask that question of your partner and answer in the affirmative, then you’ve found the right one.
Image Courtesy of centralasian.
A friend of mine who is CIO at a $500 million global staffing firm said that as far as he could tell, no one had figured out how to integrate offshore teams into a company's existing Agile process. In fact, he said that when he'd asked around, the basic sentiment was that it couldn't be done.
Admittedly, there are real challenges that can get in the way of applying Agile principles to distributed software development teams (I say "distributed" here because we're not simply talking about off-shoring but instead about the increasingly common practice of working with multiple developers who could be in North America, Europe, the Middle East, and Asia) and chief among them is the fact that the methodology itself calls for continuous, face-to-face communications including the "daily scrum."
As Agile practitioners, not to mention an organization that specializes in globalized software development, we're not only aware of these challenges but we have a lot of experience helping our clients overcome them. Here are five key practices we recommend to do just that:
1. Begin and End Face-to-Face
You aren't going to be able to meet in person every day so it's imperative to start and end each project in the development cycle with face-to-face meetings. Getting everyone together, regardless of where they actually reside, means budgeting for travel up front, but the esprit de corps, cohesive communication, and increased efficiency these meetings engender make such costs a necessary investment.
2. Build a Project Management Superstructure
The distributed teams we're talking about actually consist of multiple individual teams. Synchronizing their efforts and forming them into an effective federation calls for the creation of a project superstructure bringing together architecture, integration, and project management teams. In addition to providing a unified leadership framework, this superstructure can also be leveraged as a context for recognizing the contributions of individual teams and team members.
3. Create a Scrum of Scrums
At times, the geographical distribution of your teams will make a comprehensive daily scrum out of the question. The solution is the creation of a "scrum of scrums," consisting of representatives of the individual scrums,
which can meet daily. You should also rotate representative members in order to maximize a diversity of perspectives and ideas in the scrum of scrums.
4. Leverage Collaborative Tools and Social Media
Since continuous, iterative communication is key to Agile success, you need to take advantage of any and all available conferencing and collaboration tools. In addition to video conferencing services and software like SharePoint and Live Meeting, you should not hesitate to rely on the power of blogs, wikis, YouTube channels, Twitter, and Facebook. These latter media especially can help strengthen the personal connections essential to meaningful and timely communication.
5. Distributed Seniority in Team Culture
For Agile to work, you have to build a team of global partners. It won't work if you have a leadership team "over here" and a junior, execution-oriented team "over there." Senior developers need to be distributed so that no team or scrum is relegated to junior status. Beyond this, however, you also need to strive to create dependencies between teams so that they come to view each other as true partners.
The power of Agile methodologies is by now proven and therefore the expectation that development partners, wherever they may be, will not only be familiar with them but will be able to implement them as part of a distributed development process is going to continue to grow.
Of course, we're all still learning how best to do this. What experience have you added applying Agile methods to globalized or distributed software development?