BIOS: Technology Means Business

According to research from respected research house The Standish Group, two thirds of software projects worldwide are considered failures, more than half exceed budget and 84 per cent suffer from over-runs. For many corporations, the offshoring option has been seen as a way of addressing these issues, especially the question of cost.

Regrettably, few offshore software development projects have fared much better than their homebound counterparts. In my view, one of the chief sources of the problem is, far too often, the humble word document's role as the chosen vehicle to communicate the project's goals across the application development team. Most application development teams have to wrestle with requirements specified in a one-dimensional, static document.

The word document has never been the ideal vehicle for such a task. It is hard to relate relevant information to all involved stakeholders covering the entire spectrum of roles collaborating on any given project. It is also virtually impossible to use this document to represent the business process the software is reflecting. These types of 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 that the need for total clarity at every step is even more paramount as there is no opportunity for the usual face-to-face communications that can handle the subtleties and complexities of a typical software development project. It becomes hard to communicate the distinct requirements of each project - 'the voice of the customer' - and even harder to communicate and co-ordinate changes during the project to each individual developer as and when they happen.

While it is an accepted law of nature that requirements will change, most organisations remain woefully inadequately equipped to deal with this fact. Too often notifications are forgotten entirely or come too late. Some companies use high-level business process models accompanied with change management tools to automate the flow of tasks and decisions that need to be made. However, these companies still remain in the minority.

The upshot of this situation is that projects rarely achieve their business and financial goals. Even well-written software code is continually reworked and reworked as changes are requested. Any original cost benefits ascribed to the offshoring/outsourcing model are then lost as incremental costs mount up.

Some pioneering companies are now addressing this issue of change through the application of a disciplined requirements management process that aligns the business needs more closely with the IT implementation. Here requirements are formally articulated, prioritised and signed-off by all involved - end-user, business and IT.

This means that the project can start with expectations set correctly - no-one can turn around half-way through and say 'I thought it would do this!' Even more importantly, having a disciplined process helps organisations to more easily manage the changes to requirements that invariably crop up once you get going on a project.

Requirements management tools enable changes to be communicated automatically and simultaneously to all affected parties of the application development team when a change is required. It can also communicate the proposed changes to those who have registered interest in that particular requirement.

For example, someone in marketing who may not be directly involved in the project, may have registered interest via the requirements management system in the billing functionality because they want to be sure that the customer experience includes automatic re-funding for certain billing errors. Importantly, it ensures that all changes have to be signed off with the appropriate level of authority and the work order signed off. As a consequence, new costs are only incurred if they are really needed.

The starting point for such a process is to accept that change is inevitable and that the cost of change will only be surmounted if the processes are in place to assess the consequences of change and the requirements for change to be communicated to everyone it affects in real-time.

Proper impact analysis can clearly 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 extremely burdensome to manage, to the extent that good impact analysis is very rarely seen and used today.

Stakeholders involved in a proposed change can be clearly identified and be patched into a teleconference or video conference to discuss the feasibility and implications of change and other options if those changes are prohibitive.

Project management can also become much tighter through improved requirements management practises. 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. No matter where in the world a developer is working, he or she can access all the information required for their role in a secure environment and thus be empowered to perform at their best, knowing that the 'voice of the customer' has reached them in a clear, consistent way from a central repository of such customer requests.

This process also ensures that the testing process is kept in sync with the functional changes. All too often, in a word document world, the project managers fail to communicate the need to change the test schedule when the functions change. This can be problematic at the best of times but can also be a legal liability, especially if the project is within the life sciences (medical), defence or other industry verticals with a strong regulatory compliance aspect.

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. For the first time, an organisation can document key learnings so that every new project team has the benefit of their predecessors and colleagues.

Effective project management through change is a challenge in all disciplines but no more so than in software application delivery where experts are trying to write the future using the lessons and learning of the ever-evolving, recent past. With the combination of effective requirements management practices and automated tool support, offshoring of software development has the potential to finally deliver on its promise.