Sixty six per cent of software projects worldwide are considered failures, more than 50% exceed budget and 84% suffer from overruns, according to research firm The Standish Group. For many corporations, offshoring has been seen as a way of addressing these issues.
Regrettably, few offshore software development projects have fared much better than their UK-based counterparts. One of the chief sources of the problem is the humble Word document's role as the vehicle to communicate the project's goals across the application development team.
Word documents have never been the ideal vehicle for such a task. It is hard to relate relevant information to all stakeholders covering the entire spectrum of roles collaborating on any given project. It is also virtually impossible to use a Word document to represent the business process the software is reflecting. These documents should only be one of the outputs of the process but regularly end up as the "receptacle" for the process as well.
The offshoring of software projects has exposed the shortcomings of a document-centric approach as an ineffective requirements management tool. This is in the main due to the introduction of further variables such as company-specific terminology, ambiguous requirements, interpretation of understanding, time zone, geography and language differences.
This means the need for clarity at every step is paramount as there is no opportunity for face-to-face communications that can convey the complexities of a software development project.
It becomes hard to communicate the distinct requirements of each project and even harder to communicate and co-ordinate changes during the project to each individual developer as and when they happen. Although it is accepted that requirements change, most organisations remain inadequately equipped to deal with this fact.
The upshot is that projects rarely achieve their business and financial goals. Even well-written software is continually reworked as changes are requested. Any cost benefits ascribed to the offshoring model are lost as incremental costs mount up.
Requirements management tools enable changes to be communicated automatically to all affected parties of the development team when a change is required. It can also communicate proposed changes to those who have registered interest in that particular requirement.
The starting point is to accept that change is inevitable and that cost of change will only be surmounted if the processes are in place to assess the consequences of change and the requirements for change can be communicated to everyone affected in real time.
Proper impact analysis can expose the scope such a change might have on the process and its associated deliverables in terms of time and cost. Without automated tool support for establishing traceability across the entire process, performing good impact analysis becomes burdensome to manage, to the extent that it is rarely used. Stakeholders involved in a proposed change can be clearly identified and can discuss its implications.
Project management can also become much tighter through improved requirements management practices. At the outset of a project, a "baseline" of requirements can be established to document what constitutes a successful set of functionalities. This is approved by the end-user (the customer who will use the software), the budget holder and the project team at the outset and also signed off when any major change is agreed.
When changes occur, the team can look at the previous baseline and the proposed new one to see if the new specification still meets all the original objectives. In this way, any deviation from the overall business goal can be spotted and avoided if it threatens to derail the project.
Visibility and control can be greatly increased, even if stakeholders are in different locations around the globe. This process also ensures that the testing process is kept in sync with the functional changes.
For organisations with multiple software development projects running simultaneously, these processes and technologies can enable efficiency and effectiveness to be tracked and best practice shared via a performance dashboard.
With the combination of effective requirements management practices and automated tool support, offshoring of software development has the potential to deliver on its promise.
Corne Human is requirements and software configuration management product line manager EMEA at Borland