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