In his 2005 bestseller The World is Flat, New York Times columnist Thomas Friedman famously proclaimed that advances in global communications technology had essentially rendered the world flat. By this he meant that the massive investment in communications infrastructure that fueled the dot-com bust has, as a virtuous by-product, allowed a new generation of companies to leverage cheaper resources abroad.
And has it ever!
The ubiquity of persistent Internet access has enabled a new generation of companies to leverage resources – be they human or IT-based – wherever they might be physically located. Regardless of how you feel about the political implications of offshore outsourcing, it’s clearly no passing fad.
It wasn’t too long ago that developing software via offshore outsourcing belonged solely to the province of large enterprise organizations. This of course is no longer the case as even the smallest companies have come to rely on distant software development teams in Eastern Europe, former Soviet republics, and Asia. In fact, this ability to instantly tap cheaper development resources and expertise has directly contributed to a burst of innovation, as smaller companies are able to level the playing field with their larger enterprise counterparts.
Yet this opportunity also comes with some thorny strings attached – any short term savings realized can be quickly offset by poor requirements definition and gathering practices. As business analysts well know, clearly articulated software requirements represent the foundation of any successful software project. Indeed, the reason why so many software projects continue to fail is precisely because not enough attention is paid to this critical first step in the software development process.
Communicating and managing software requirements is of course challenging enough even when all your team happens to be situated in the same location. But when working with a distributed team, many of whom don’t even share a common first language, the potential for errors grows considerably. And thus, any savings realized by cheaper resources is suddenly squandered. Worse still, time is wasted, morale suffers, and the project team is forced to shift into “fix-it” mode.
On-Demand Apps Grow Up
When Salesforce.com was founded in 1999 by former Oracle executive Marc Benioff, the notion of applications hosted “off-premise” was still something of a radical idea. At that time, there were still a number of barriers to widespread adoption: application performance, security assurances, and bandwidth constraints, to name but a few.
Just 10 years later, practically every major software category now includes a healthy ecosystem of on-demand solutions. Not only has the supporting infrastructure matured with offerings like Amazon’s EC2 cloud platform – allowing software providers to more easily configure their application in the cloud — but the next generation of on-demand applications are pushing the envelope in terms of what can be delivered through a browser. More and more, these applications feel and act like traditional desktop software. But of course, they can do so much more because they are intrinsically connected. Now, every on-demand application has the potential to become a dynamic collaboration platform that succeeds in bringing all project constituents to the table. And, as more on-demand application developers create and publish their APIs, they can be integrated into other facets of the software development process.
But it’s this idea of connectedness that’s so powerful when it comes to keeping distributed teams marching to the same beat. Business analysts are not just responsible for defining requirements but also for ensuring that they’re properly communicated and correctly applied. While large enterprises might have the luxury of a robust requirements management tool at their disposal that incorporates collaboration (and surprisingly, only a small percentage of these enterprises have adopted these types of solutions), the average small to medium enterprise does not. Instead, most of these companies use some combination of Word, Excel, and email to define and communicate requirements to their development teams. Because these tools are disconnected from one another, the potential for miscommunication is an endless challenge. And when those development resources are located half a world a way, it’s not a question of if something will go wrong but rather when.
So what’s a budget-minded business analyst working with a distributed development team to do?
Requirements Outlook? Mostly Cloudy.
In many respects, business analysts can find inspiration in the latest hype cycle: social media. Social applications like Facebook and Twitter have reshaped our personal dialogue and communications framework. And aspects of these sites will likely transform the way we think about software requirements.
For better or worse, we are in constant communication with our own personal circle of contacts. Anyone who has been part of a software development team understands how important it is to be in regular contact with the rest of the team. From the beginning of a project (i.e., defining use cases) through the implementation phase (i.e., bug tracking), persistent communication is the new Critical Chain. Put another way, when you can’t all be present for the daily stand-up meeting, how do you ensure everyone is on track?
There are three key ways that migrating the requirements gathering process to the Cloud will help business analysts get better results from their distributed development teams:
Collaborate in Real Time, in Context. Email is a terrific communications tool. But it’s asynchronous and often detached from a larger context. This becomes especially problematic when multiple teams are working on different aspects of the same project. By unifying the requirements process in a hosted environment, distributed teams can collaborate in a meaningful way and identify potential problems before they get out of hand.
Visualize the Workflow to Mitigate Language Barriers. One of the most vexing challenges that business analysts face when it comes to working with offshore developers is communicating across multiple languages. There are the obvious spoken language barriers to overcome. But more often it’s the nuance and culture of language that presents the most significant obstacle. Because business and software requirements are technical in nature, employing a visual language to communicate requirements becomes a necessary complement. As traditional requirements gathering tools move to the Cloud, the ability to clearly represent business requirements in a visual manner (i.e., use case scenarios, parking lot diagrams, etc.) will help keep all project constituents on track.
Visibility for All, Across the Entire Requirements Spectrum. No software developer should be an island to themselves. Even though two developers might be working on two discrete and unrelated tasks, it’s still vital that they understand the underlying business requirements that are driving the project. By standardizing the requirements management process in the Cloud, the business analyst can provide all of their team members with the “situational awareness” they need to understand how their software will be used.
In Flat We Trust
The world is indeed becoming flatter by the day. Just as the path of water naturally finds the path of least resistance, free markets will invariably gravitate towards the most cost-efficient resources. However, even with all of Friedman’s optimism regarding the potential rewards of offshore outsourcing, he also goes on to warn us: “In this era of mounting complexity with more people, systems and products entwined in a bewildering web of global networks, explaining is an enormously valuable skill.” In a sense, that is exactly what software requirements are all about: explaining. And explaining becomes all the more important when teams are fragmented by geography, culture, and language.
Don’t forget to leave your comments below
Darren Levy is the founder of GatherSpace.com, a provider of on-demand requirements management solutions based in Los Angeles. Email him at [email protected].