Thompson Racal Defence gets feel for customer requirements

The key to giving your customers what they want is making sure you have a comprehensive picture of what that is from the outset....

The key to giving your customers what they want is making sure you have a comprehensive picture of what that is from the outset. Thompson Racal Defence does it with Doors, as Liz Warren finds out

Getting it right first time is the secret to pleasing customers at minimal cost. But how do you follow that simple rule if you have to deal with hundreds or thousands of requirements at once, and if some of those requirements are ambiguous, missing or even conflicting? That's the challenge that faces the design teams at Thompson Racal Defence every time they embark on a new project, but one they were finding increasingly hard to meet as projects became more complex and customers more demanding.

The solution was to beef up the company's requirements management strategy. Improved processes and tools are allowing the company to capture requirements from the customer more accurately and make links between related requirements, before tracing them on to the design of the equipment. All the while, project managers can identify, analyse and manage any issues that arise along the way.

The need for action emerged in 1997 when Dick Allen-Shalless, head of systems engineering at Thompson Racal Defence's sensors division in Crawley, West Sussex, conducted a capability evaluation of the company and discovered a number of problems in requirements management. The major fault was that there was no overall strategy or clearly defined process: to some extent, it was up to individual engineering managers to determine how best to handle requirements capture and management within each project. That meant the success of projects depended heavily on the capabilities of those particular managers.

The company did have a requirements management toolset, created in-house using Microsoft Access, but requirements for smaller projects tended to be captured in simple documents and spreadsheets, often on an ad hoc basis. A key component in any new strategy would be to source a more comprehensive requirements management solution that could be used to underpin and enforce best practice processes in all projects.

"The real benefit of having a tool that allows us to do accurate requirements management is that we can identify any areas of risk or non-compliance during the first 25% of the project life-cycle rather than the last 25%," Allen-Shalless explains. "That's essential given there is a savings factor of 10:1 between the front end and the back end of the project.

"On top of that, identifying any conflict earlier in the process allows us to manage the discrepancy, whereas if it occurs in the back end, all we can do is cope with it. A good tool allows us to bring decision-making to bear on problems early in the programme."

To select a requirements management tool, the company carried out an exhaustive study on those available and determined that QSS's Doors offered the best match to the company's needs. Martin Williams, chief engineer at Thompson Racal Defence, Crawley, was involved in the selection process. "We looked at ease of use, ability to interface with other applications, cost and other factors - and our review was backed up by an earlier assessment carried out by Racal Research. It was obvious that QSS's solution provided advantages in many of the key areas."

However, as Allen-Shalless points out, Doors is only a tool. "You still need a process in which to operate it," he says. A critical step in the introduction of Doors to Thompson Racal Defence was to ensure the surrounding processes were appropriate and effective.

Doors had already been adopted by another member of the Racal group to develop an advanced mission-planning tool for the UK Royal Navy's Merlin Helicopters. Allen-Shalless and his team reviewed the work done on the Merlin project and identified where Doors was used for activities that were trivial or did not add value to the project. This helped Thompson Racal Defence establish the value of each function within the system and determine what it wanted to achieve with Doors and how the software would be used.

Doors was then introduced within Thompson Racal Defence on the Type 45 Destroyer programme, a project where the company felt requirements management would be a particular headache. Shortly afterwards the system was adopted by two other pilot projects and it has since been identified as the preferred tool for requirements management within the company. This means that all new programmes and projects are likely to make use of Doors, while existing project data will be transferred to Doors where this makes economic sense. In the case of some projects where Access databases were used to hold requirements information, migration has typically taken just a few hours.

Now, the first step in any new programme is to use Doors to capture the dozens of documents that make up the contract with the customer. Doors can then extract the thousands of prime requirements these documents contain and identify duplication, ambiguity and voids. This allows Thompson Racal Defence to produce a single, clear set of requirements against which the system can be developed, but which can also be traced back to the original contract documentation in the event of disputes with the customer.

With such complex data sets another vital step is to determine at the outset how this information should be structured in order to meet the requirements of the project most effectively. For example, who will possess responsibility for the various aspects of the project, such as monitoring the overall availability and reliability of the equipment under development? And how will requirements flow to the teams of designers during the design stage?

Taking into account these facts allows the data set to be structured so that it becomes easy for the various project sub-groups to pull together all the information they need in the format they need.

During these initial stages, Thompson Racal Defence is careful to guard against one of the potential drawbacks of Doors, which is that it can become a micro-manager's dream. "You have to be careful how you use it," Allen-Shalless points out. "You can easily over-complicate the situation and get a requirements explosion by producing too many derived requirements. We're careful to derive requirements to an adequate level, and that level varies from project to project."

In fact, although Thompson Racal Defence initially thought the introduction of Doors would speed up the requirements capture process, it now takes longer to process each requirement. However, the work is being carried out to a much higher standard: it is easier to trace requirements from initial contract documentation through to final product testing, while the system ensures that consistency is achieved where different documents contain varying or ambiguous versions of the same requirement.

Once the project team starts generating designs, Doors then helps Thompson Racal Defence to work with customers to verify designs as early as possible in the project. "With Doors, we can now get much earlier feedback as to the systems designer's interpretation of a customer's original requirements; in the past that would have been dealt with as tomorrow's problem," Williams points out. In general, for an 18-month project delivery programme, Thompson Racal Defence has been able to move requirements' review from about five months into the project to less than two months in.

Williams continues: "Because of reduced time-scales, Thompson Racal Defence also often undertakes concurrent engineering by proceeding with systems design while continuing requirements analysis. This requires good knowledge and understanding of the current level of risk, in particular the risk of the conceptual or real system design not meeting the total requirements. By using Doors, we can trace our analysis and see any possibilities of this occurring much earlier in the programme, thereby significantly reducing the probability of 'shocks' later on."

Finally, once the design of the equipment has been completed, Doors helps Thompson Racal Defence to verify and validate the end product against the initial requirements in the contract. It does this by tracking how the requirements have been implemented into the design. This allows Thompson Racal Defence to respond to customers who, these days, are much "smarter" purchasers than, say, 10 years ago, and who now demand that systems rigorously meet every requirement laid down in the contract. "We can't do that without a tool like Doors," says Allen-Shalless. "Doors is our policeman: it makes sure what we produce is what the customer ordered and it allows us at all times to keep an eye on what it is we've got to do."

It has an added advantage that if the requirements change, for whatever reason, it is possible to see exactly which sub-systems are affected. This brings huge benefits if the customer is unhappy with the design, since Doors can quickly identify whether a change the customer is pressing for is already covered somewhere in the documentation. "It helps us clarify with the customer exactly what the requirement is," Allen-Shalless explains.

It also saves a great deal of time when the company is asked to produce slight variations on an existing design. Most of Racal's contracts are for a very small number - perhaps 10 - of an immensely complex item. Good requirements management helps enormously when the same customer or a new customer wants a modified version of the product. "If we can capture all the requirements for that product and trace them into the design, we can enter information about the changes the client wants and identify immediately the impact of those changes on the various sub-system in the equipment," explains Allen-Shalless.

Clearly, the overall impact of Doors on the requirements management process has been significant, but Allen-Shalless warns that tools and processes are not enough on their own. "You still need highly competent staff who understand requirements management to make use of them," he points out. The company has therefore set up a requirements management centre of excellence, run by Williams, which can supply requirements management expertise rapidly to any project within the company.

Furthermore, every division or company within the Racal group which uses Doors has nominated a member of staff to act as that division's representative to a cross-Racal Doors user group. This group gives design teams within Racal rapid access to problem solving and best practice expertise regarding Doors. According to Allen-Shalless, if one team using Doors identifies either a new way to use the software or a problem and its associated fix, that information can be propagated across the group within just two days. The in-house user group also acts as a single point of contact when issues need to be escalated to QSS, while Racal is a participant with other firms in QSS's InDoors user group.

In the element of the company which was previously Racal Defence Electronics there are now about 50 concurrent licences for Doors, with 80 staff across the company trained to use it and, Allen-Shalless estimates, some 18 major programmes at the company now rely on Doors at any time. The next step is the roll-out of DoorsNet, a web-based viewer for the Doors system that provides less functionality than the full product but allows Doors information to be disseminated more widely at lower cost. This will allow project information to be published on Thompson Racal Defence's corporate intranet and will make it easier for staff across the company, from software developers to senior executives, to monitor the progress of projects.

Staying on top of projects in this way will ensure that the company can continue to satisfy customers and retain its place as a leading player in the marketplace. "There is no question that we are arriving at the acceptance stage for programmes with far fewer problems than we would have expected under the old approach," says Allen-Shalless. "The use of tools of this nature alongside other developments in the company has considerably improved our ability to deliver equipment to specification and in ever shorter time-scales."

At a glance

The organisation

Thompson Racal Defence is a global Euro 610m turnover business, arising from the merger of Racal and Thomson-CSF, providing communications, electronic warfare, command information systems and radar to the defence industry.

The challenge

More demanding customers, shorter timescales and ever more complex requirements were challenging Thompson Racal Defence's ability to deliver projects successfully.

The solution

Overhauling its requirements management processes and implementing a comprehensive requirements management tool have allowed Thompson Racal Defence to deliver programmes to specification, on time and at lower cost.

The Computer Weekly/Buy IT case studies offer an in-depth analysis of a successful IT project, with expert comment from a panel. BuyIT was launched in 1995 by the DTI and an alliance of top industry bodies. BuyIT has selected best practice examples on a range of projects. Each case study is scrutinised by the BuyIT team of experts who make their recommendations and comments. The BuyIT Computer Weekly Best Practice Series is endorsed by Fit for the Future, a CBI-led, government-backed campaign to get business learning from business.

Critical success factors

Peter Duschinsky of BuyIT says:

  • Insist on a clear definition of the business needs and expected benefits, even for the simplest procurement, in terms that can be measured and tested; if achievement of benefits is not planned it will not take place

  • The formal statement of the business requirements must show that they are aligned with the business and that there is a real business need for the process to be handled by the proposed system

  • Implement a clearly defined process and enforce it through tools, while allowing sufficient but controlled flexibility; ensure that the options considered go beyond incremental change and that opportunities for new ways of working have been considered

  • Evaluation and review of the project requirements are essential at an early stage and throughout the project to ensure that they continue to support the business objectives. The programme manager must have the authority to stop the project if this is no longer the case

  • Projects should be managed to an adequate level of detail - don't get bogged down in micro-management - which will need to be determined on a project-by-project basis

  • Create a centre of excellence within the firm to provide expertise and disseminate best practice

  • Remember that tools and processes are not enough on their own: you still need skilled, experienced people who can apply them intelligently.


    Do you have any comments on this case study or any examples of best practice of your own that you think should be considered for this series? Please send comments and input to [email protected]

    What the BuyIT experts say

    Ken Deeks, member of BuyIT Marketing and Communications Working Group and managing director, IT communications consultancy Kaizo

    In March, Andersen Consulting released research which revealed that a typical $1bn high tech company can gain as much as $130m in profits by improving its ability to manage customer relationships. Today, smart businesses are investing heavily in information management systems that capture complex information and transform it into valuable customer and project intelligence. As markets grow ever more sophisticated and customer expectations continue to rise, finding ways of introducing best practice right across an organisation in order to ensure that product or service delivery promises are met at every stage of the customer relationship lifecycle will be increasingly important.

    This case study provides an excellent example of a business that understands the complexities of brand value and reputation. By adopting a strategic approach to customer relationship management - one which looks to spot and solve potential problems at the earliest possible opportunity - the Doors solution will deliver maximum business value to customers and optimum profitability for the company. To succeed today, an "outside-in" view of your organisation is critical. By putting customers at the forefront of its project management strategy, this team is streamlining its business to exceed customer demands about speed, service and quality.

    Alistair Fulton, chairman, BuyIT Best Practice Group

    Requirements management may not sound particularly exciting but, as every IT manager knows, get the requirements right and you have at least a good chance of a successful project. Get them wrong and you have the certainty of lots of expensive corrective work later on, and the high possibility of a failed project.

    A planned and structured approach to identifying the business requirements is essential to achieve success, for apparently simple as well as complex information systems projects.

    Companies like Thompson Racal Defence are dealing with tens of thousands of different requirements on each of their defence contracts, and we thought this would be a useful example to highlight the issue.

    For these highly complex projects, a requirement management system will help to capture the wide range of system and end-user requirements and link, trace, analyse and manage them to control costs, improve processes, speed up verification and product delivery.

    Your projects might not be as complex as Thompson Racal Defence's, but you will need to ensure that requirement capture and management are carried out to a high standard. Peter Duschinsky has identified the key success factors and the BuyIT Guideline: Identifying The Business Requirements is available on

    Colin Thompson, director-general and chief executive officer, British Computer Society

    The process of capturing the user requirement and then taking it through the various stages of the project lifecycle to delivery of the system has been described as being akin to the party game of Chinese whispers played by people who speak different languages. Arguably, it is the main factor that distinguishes information systems from other branches of engineering where, however complex the design and build stages, the requirement is often relatively clear and stable.

    In the case of the IT-related project, the real business requirement will:

  • be difficult to define and even more difficult to express without ambiguity

  • have multiple interfaces to other parts of the overall system

  • change over time as the business need changes and the users understanding develops.

    Much of this complexity cannot be eliminated, but this case study demonstrates how it can be handled and controlled effectively using a standard application management tool.

    Achieving the necessary integration between processes, people and the chosen tool-set is more difficult than it might appear at first sight, but it is the key to achieving important gains in terms of cost, time-scale and supplier reputation.

  • Read more on IT project management