Earlier this week at the annual EMC World conference in Las Vegas, EMC announced a deal to use Box.net -- the cloud-based collaboration and storage service -- to give access to EMC Documentum content management repositories from the cloud. In theory that means, you can whip out your smart phone or tablet, launch the Box.net app, and have access to all the enterprise files you have permission to view -- and you can use all of Box's collaboration tools while you're at it. It has the potential to be extremely convenient and it's a smart approach in my view for EMC to take. Why? Well because large software companies aren't really equipped to bolt on cloud functionality onto their big in-house software packages. By partnering with a fresh company built from the ground up to deal with cloud functionality, EMC is providing its customers with collaboration and file storage in the cloud without having to build it themselves. Box CEO Aaron Levie certainly understands this. In a statement announcing the deal, he talked about the way these two types of solutions work in tandem to help the customer. "These solutions are at the forefront of a major transition in enterprise IT, as vendors will increasingly need to work together to create powerful, open solutions that bring customers the benefits of cloud-enabled software without disrupting their existing systems and processes," Levie said. The last part was the most important nugget. It provides all the benefits of the cloud without asking customers to rip out their existing investments to do it. In other words, it's a win-win-win situation. EMC wins because they get Cloud without building it. Box wins because they get the enterprise customers they so value (because they pay) and customers win because they get the best of both worlds -- cloud and on-premise -- without disrupting the way they currently do business. The cloud certainly gives enterprises a number of advantages, many which we've discussed here before including not having to manage the software, predictable costs, rolling upgrades, access to information from anywhere on any device, and so forth -- but not every company is prepared to go whole hog into the Cloud. That's why partnerships like the EMC-Box one are so interesting. They provide a way to let enterprise customers dabble in the cloud while dealing with a large, established company like EMC with which they might feel more comfortable. Because of the way the cloud has been marketed and presented in the past, it has caused confusion for some enterprise users. By packaging a cloud application with the clout of the on-premise software company, EMC and Box are giving customers an attractive package of services.I'm sure we're going to see more of these types of deals because they make so much sense for everyone involved, and this type of arrangement might be enough to get some intractable customers to start taking advantage of the cloud in spite of themselves.
Photo by o5com on Flickr. Used under Creative Commons License.
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?
During the webinar we did last week with the Sand Hill Group, Kamesh Pemmaraju suggested that, based on their research, "Agility" was the "#1 Driver for the Move to the Cloud." Given the intense and ever-mounting competition in the software industry and among companies for whom software is key to their success (think of PayPal or Amazon, to name just two of countless examples), organizations are looking for ways to increase efficiency, on the one hand, and improve their ability to shift operational focus quickly, on the other. Everyone wants to be more agile.
It is easy to understand why organizations believe that cloud-based solutions will help them achieve this goal. If you can spin up a virtual machine on a cloud without the need to buy and install hardware, or easily store data remotely in order to support a more mobile, decentralized organization, or give members of said organization instant access to a critical SaaS application, then we're talking about a technology that will make your business undeniably lighter on its feet.
Nevertheless, technology alone cannot make a business agile. In fact, unless you have the right organizational structures in place and the right people in the right roles, you will be unable to take full advantage of any such enabling technology, cloud-based or otherwise.
My thoughts on this subject have been most recently influenced by Terri Griffith, Professor of Management at Santa Clara University, who points out that, "Our work is not done in silos – yet much of our technology infrastructure and work practice are built as if it were."
To counteract this siloed thinking, she advocates a "systems savvy" management approach which understands that in any enterprise technology, organizational structures, and the people working in the enterprise are inextricably connected and that you can't address issues in one area without affecting the others.
In terms of business agility and the cloud, this means that simply replacing on-prem systems with EC2 or licensed, shrinkwrapped software with Google Docs is not enough. You have to modify your organization so that, from a policy and communication standpoint, it is flexible enough to take advantage of these "as needed" tools when they are actually needed and that the people in the organization are autonomous enough to decide for themselves when to do so.
Faisal Hoque addressed this latter issue in an article from last April entitled "Achieving Business Agility through Convergence" in which he wrote that "firms must replace traditional command and control approaches with mechanisms that facilitate coordination within and across locales." He goes on to stress that such mechanisms should "provide individuals, groups and units with the autonomy to improvise and act on local knowledge, while orchestrating coherent behavior across the firm."
To maintain this kind of coordinated but distributed autonomy calls for a truly collaborative approach to organization-wide communication. It also calls for a systematic approach to business intelligence that not only captures real-time data on organizational performance but disseminates it efficiently across the enterprise. (This is a major challenge for many organizations in part because, while they collect critical data on an ongoing basis, they encounter numerous technical obstacles when it comes to accessing it, as Ness' Glenn Gruber discussed in this post.)
Finally, returning to Professor Griffith's schema, the agile organization needs people that are comfortable working in an environment that cultivates ubiquitous autonomy. Not only that, the leaders of the organization need to have the confidence that employees are competent enough to be relied on to take appropriate risks, on the one hand, while consistently attending to real business needs on the other.
Getting the "people part" right is inevitably a question of intelligent hiring practices, thoughtful and practical training, and carefully crafted systems of management and compensation. It becomes a bit trickier when, as many companies today do, you are heavily reliant on an ecosystem of partners to deliver your products and services to the people who matter most in the final instance, your customers.
To manage the uncertainty that goes along with these critical partnerships one must, as Ronald Reagan once said in a very different context, "Trust, but verify." That is, when your commercial fate is closely linked to that of others (whose fate in turn depends on others still), trusting and being trustworthy are essential attributes. However, such trust need not be blind. Vetting potential partners, paying particular attention to the way they approach partnerships, is absolutely necessary.
One organizational behavior to be on the lookout for: Does this future partner identify with my organization and make my goals their own? (And a question to pose to yourself: Is this how I treat my own partners and their goals?)
So, yes, the cloud offers powerful alternatives to "business as usual" and the efficiences it can afford will definitely contribute to business agility. But it can only do so if it is implemented with an eye to "systems thinking" and its implementation is thoughtfully interwoven with forward-looking organizational change and the empowerment of employees.
(A different approach to "5 for Friday," I know, but does it work? - The Editor)
"Third-Party Partnerships Hold the Future in Software R&D," according to a recent Global Services post. They came to this conclusion in light of a Zinnov report on R&D globalization which found that while ISVs and others are spending 15% of their budgets on R&D, only 5% of that amount is being spent on outsourced partnerships. With 95% of the total R&D spend left on the table, so the thinking goes, OPD companies are looking at a huge potential for future growth.
This growth potential is limited, in the view of Zinnov's Vamsee Tirukkala, by the fact that ISVs are looking for more than just a development partner. As Tirukkala sees it, the trend is for ISVs to seek out vendor partners who cannot only assist with product development but can also play a role in taking the product to market.
Oddly enough, one challenge driving ISVs to favor such vendor partnerships has to do with the failing ability of captive centers to attract and retain talent, says Tirukkala. "As a thumb rule, especially in emerging economies like India and China where career paths are more important than the prospect of just working for an MNC company, it is a significant phenomenon of captive centers not being able to contain attrition and attract the right talent."
I think what he's saying is that companies that need developers but are vendors in their own right offer a more solid career path than pure-play IT service providers. Is this really true? I can see how it might be the case for providers who are functioning at a commoditized level and basically going after low-hanging (and priced accordingly) outsourcing fruit. Due to churn among the clients of such providers career paths will be relatively short, effectively evaporating for entire teams as client engagements end.
But if you are looking for a research & development partner who is thereby going to play a significant role in the future of your company, are you really going to go with an organization like that? I think it's more likely that you would be looking for an organization which first of all has the requisite talent and second of all is determined to and capable of maintaining a multi-year relationship with your company.
Of course, an organization like that would by definition attract great talent (it couldn't be in business without them) and be able to offer these people enough continuity to satisfy their desire for a career (and not just a brief stint at an MNC). In fact, it seems to me that an organization built around delivering that level of service to its partners might even be distracted by the need to sell its own products, which rather argues against the "vendor partner" model.
So, do third party vendors make better offshore product development partners? Putting it another way, do these vendors actually have a better chance of attracting and retaining talent than OPD service providers across the board?
Image Source: Margonaut Creative Commons License
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