Agile Project Management Case Study


The Combat Identification Server (CIDS) Technology Demonstrator Project (TDP) has been delivered to time, quality and budget using the Dynamic Systems Development Methodology (DSDM). [Note: since the time this trial was performed, DSDM has undergone revisions and is now known as the AgilePM (Agile Project Management) framework.

This trial application of the AgilePM method by the Ministry of Defence (MoD) Defence Equipment and Support (DES) has:

  • Demonstrated the suitability of the application to a DES project.
  • Provided lessons for the future application of AgilePM.
  • Shown the effectiveness of the AgilePM method in achieving the delivery to time, quality and budget.

The CIDS TDP was funded by the MoD DES Tactical Datalinks Delivery Team (TDL DT) and delivered by an industry consortium led by General Dynamics United Kingdom Limited.


CIDS was a complex system/software project. The objective was to help clear ‘the fog of war’ by providing a picture in the cockpit of an aircraft of the position of nearby friendly forces on the ground.

The use of AgilePM was a bold move, but the project rapidly delivered successful outcomes for all involved. In the current economic environment, delivering solutions within budget is top priority. Could this approach be the future for project management in the defence sector?

CIDS TDP – applying AgilePM

Traditionally project management in the defence sector has focused on meeting technical requirements, sometimes at the expense of project duration and cost.


In a AgilePM project, the performance requirements are expressed as Must, Should, Could and Won’t (this time) or ‘MoSCoW’. In the AgilePM model trading out requirements provides the flexibility to ensure on-time and on-cost delivery of an acceptable and ‘fit for purpose’ solution rather than a perfect one.

Incremental delivery

In practice, the development of the CIDS capability was divided into increments. Dividing the CIDS project into increments provided checkpoints at which capability could be demonstrated.

Each of these increments was divided into timeboxes. If, in the delivery of any timebox, it was apparent that there was risk to the achievement of the Must requirements, effort was expected to be redeployed from the tradeable Should and Could requirements to assure the delivery of Must requirements.

Fail early

If it became apparent that the Must requirements were in jeopardy, then the timebox and potentially the whole project could have been stopped or re-planned (extension of a timebox is not permissible). This discipline is key in the ‘fail early’ principle of AgilePM.

Business and commercial

From a business perspective the use of AgilePM required a significant change in approach to the project.

Financial contingency

Traditionally a financial contingency is held, to be called upon if difficulties are encountered in delivering the required project outputs. AgilePM renders financial contingency redundant. Instead, the CIDS project requirements were categorised using the MoSCoW approach.

Trading requirements

Through a trading process during project execution, the MoSCoW technique enabled a few Should and Could requirements to be removed from the project solution to prevent potential cost and schedule overrun, without any customer penalties being incurred.

AgilePM is typically applied to software dominated internal change projects within the Information Technology sector. As such, the CIDS project was also seen as breaking new ground commercially through the application of AgilePM on a project involving a consortium of companies.


As a result of the unique method of delivering the CIDS project, negotiations had to overcome the impacts of using AgilePM. Thankfully, we were all learning together!


The TDL DT had an initial concern that the consortium would abandon Should and Could requirements at the first opportunity and an incentivisation mechanism was sought. However, this approach contradicted AgilePM principles where cost – and hence price – is fixed, with requirement trading offering the project contingency.

During contract negotiation this incentivisation position was relaxed as the TDL DT recognised that the consortium would aim to maximise the delivered capability.

Payment plan

One aspect that required ongoing negotiation through the project was the payment plan. Once the project started, it became apparent that the detailed project schedule that was developed during the initial stages of the project no longer fitted the payment plan that had been agreed prior to contract award.

By taking a pragmatic and flexible approach, and recognising that this is the nature of AgilePM, TDL DT and consortium were able to align the programme and payments.

Planning the strategy

The project delivery strategy started with the TDL DT requiring the use of AgilePM as the project delivery method.

External expert

With theoretical, but little practical experience of AgilePM, the consortium used an external AgilePM expert to guide it through the bid phase.

Instead of including a detailed schedule of the project delivery with the bid submission, expert advice was that this process should be performed jointly with the TDL DT after contract award as part of the Foundation phase. This was not, it was advised later, what the TDL DT wanted to hear!

Single Statement of User Need

Before the team launched into the detail it needed to put the project into context by focusing on the fundamental project objectives. This was achieved through the collaborative development of a Single Statement of User Need which stated:

“Report blue force track information to authorised requesting entities on demand in the Close Air Support (CAS) mission.”

As the planning progressed, so did the collective understanding of the technique.

A key objective of the AgilePM approach is to progressively reduce risk through incrementally delivering a solution. As such, establishing how the technical solution would be elaborated within the AgilePM framework was also a key part of the planning the overall strategy for delivery of the CIDS project.


The selection of AgilePM for the CIsS TDP was motivated by the TDL DT’s objective to demonstrate that complex military technologies could be delivered without delay or cost overrun.

Using AgilePM, the CIDS project comprised three distinct phases.

Foundation phase

This was where the requirements and technical design were developed. This phase was also where detailed planning was done for the subsequent Exploration/Engineering phase.

Exploration/Engineering phase

This was where the CIDS solution was incrementally developed through a series of timeboxes where MoSCoW’d requirements were logically grouped. These timeboxes constrained the implementation to time, cost and quality.

Deployment phase

This final phase demonstrated the CIDS solution to end users.

Achievement informs planning

Throughout the CIDS project, focus was maintained on control and metrics regarding the achievements within each timebox. Whilst all project timeboxes were planned in outline ahead of time, as individual timeboxes ended, the performance within that timebox enabled the detailed planning of the next timebox.

This incremental and iterative development approach where achievement informs the ongoing plans was at the heart of the project.

Organisation and governance

Using a facilitated workshop as part of the Foundation phase the CIDS project organisation was developed resulting in consensus and buy in from the project outset.

Project roles

Nominated individuals were assigned to the roles detailed in the structure which have defined responsibilities. The CIDS project team comprised individuals from TDL DT, General Dynamics UK (industry consortium lead), consortium partners Rockwell Collins UK and Qinetiq and 3SDL (TDL DT’s specialist technical advisor).

One clear and highly beneficial outcome of using the AgilePM ‘Space Alien’ structure was that it removed any hierarchy associated with the contractual relationships, resulting in a truly integrated team.


Reviewing structures were put in place to ensure appropriate governance of the project. These comprised of monthly project reviews with the General Dynamics UK Programme Director and gate reviews at the end of each phase and increment. These had representation from both the consortium and the TDL DT.

Personnel management

Requiring the implementation of a new project management method required people with a pragmatic, flexible and open-minded approach. For all involved the project offered a great personal development opportunity.


Selection of the right personnel to lead and work on the project was critical. AgilePM requires people with the ability to work effectively within collaborative teams and a tolerance of ambiguity. This was not a project for task focused left-brained project managers!

Equally the assignment of the technical co-ordinator role was pivotal. The role has required a combination of technical domain knowledge, foresight and leadership to ensure the technical solution achieved its requirements.

The CIDS project, with its ground-breaking use of AgilePM provided excellent personal, as well as organisation, learning experience.


Continuous, clear and effective communication has been a mantra for the CIDS project.

Open and honest

Traditionally there is reticence to share ‘warts and all’ information between partners and/or customer.

As the team relationship developed, aided by significant periods of co-located working, an open and no surprises culture of communication developed. A clear no blame mandate was established to promote open and honest communication. Where frustrations between groups did occur, they were effectively addressed to prevent any damage to the day to day working relationships.

Daily progress

Other communication aids were also developed by the team. Through timebox management worksheets, clear communication of requirements to be implemented, associated estimates and the allocated of resource were provided. Daily progress of timeboxes was reviewed by team leads such that exceptions were managed as they arose instead of managing them later.

Shared working environment

A key facilitator of effective communication was an electronic Shared Working Environment, supported by email, and telephone/video conferencing.

Executing the strategy

From the outset, the CIDS project sought to differentiate itself by reshaping the traditional MoD – Industry relationship.


CIDS project success was underpinned by the Foundation phase outputs and the associated facilitated workshops. Through the Foundation phase plans were developed collaboratively to ensure consensus.


Strong leadership however ensured that there was no management by committee that could have resulted in indecision and deviation from the project objectives. Establishing the detailed technical requirements and partitioning these into a logical development strategy was challenging but the detailing of the timeboxes was eventually achieved.


The emphasis through the Exploration and Engineering phase was to ensure that the project objectives were delivered. Managing schedule adherence was relatively straightforward since it was bound by the timeboxing. However, metrics were devised to monitor performance against technical outcomes to help inform the planning of subsequent timeboxes.

These also addressed concerns that incomplete timeboxed requirements could be deferred into later timeboxes, potentially resulting in a bow wave resulting in a technical solution only meeting the ‘Must’ requirements.

Coaching and mentoring

AgilePM as a project delivery technique was new to everybody and meant that we all learnt together.

Expert AgilePM input during the project bid phase brought confidence that the planned approach to the delivery of CIDS was the right one. As a result, the industry consortium was able to contribute from an informed perspective during the crucial Foundation phase workshops.

Throughout it was important to ensure that all involved maintained the same common view of what AgilePM meant for the CIDS project.

Whilst there was early confusion that AgilePM was a substitute for the engineering process, through team mentoring a common understanding was soon established


Successful delivery of the CIDS project was achieved through the behaviours and motivations of the people involved – the teamwork.

A new project delivery method required key personnel with a pragmatic, flexible and open-minded approach, coupled with a tolerance for ambiguity and excellent teambuilding skills.

The teamwork has come about through the desire to collaborate, to learn together, communicate and build the necessary relationships to successfully deliver the CIDS project.

Any stresses in the team dynamic were recognised and dealt with early, and before they become issues.

Conflict management

Through the highly collaborative and open team approach, with a no surprises culture, conflict has been kept to a minimum.

As in most projects there have been stress points during the project, but because of the team relationships, these have been anticipated and quickly resolved.

In traditional projects which fixate on the achievement of all technical requirements, a defensive posture can often arise if problems in achieving those requirements emerge.

The CIDS project, through the highly collaborative approach, and safety net of requirements contingency resulted in a far more open environment where good and bad issues were openly discussed.

Risk management

CIDS benefitted from a risk management strategy that used an incremental development approach in which high risk requirements were tackled early, with requirements flexibility protecting on-cost, on-schedule, and to-quality delivery.

A joint risk register was established to inform timebox management and ongoing engineering development, but not to identify any required financial contingency.

Instead of holding financial contingency, any additional funds that were required to ensure delivery of ‘must have’ requirements were drawn from the budget associated with delivery of lesser priority tradable requirements.


Key benefits that resulted from the way in which the CIDS project was managed included:

  • More believable plans, schedules and budgets, and a greater likelihood of adherence were outcomes resulting from using AgilePM with its fixed cost and time approach.
  • Using AgilePM led to a contract which eliminated financial contingency, delivering the maximum possible capability for the funds available.
  • The timeboxing approach resulted in multiple decision points at the end of each timebox, and each increment, at which alternative ways forward were compared.
  • The cost base for the project was reduced as no financial contingency was needed.
  • Through the Single Statement of User Need a common vision of the project objectives was collaboratively developed.
  • With short timebox spans, risk assessment has been aided by the increased focus that resulted.
  • Greater risk taking was enabled because by principle the project could not go over budget or slip schedule. This allowed desirable but higher-risk requirements to be included as Should or Could requirements without fear of penalty to the project. As a result, greater capability has been delivered to the end-user for the same money than would otherwise have been possible.
  • With MoD funds under continual pressure, successfully demonstrating incremental capability was also way of reducing the risk of project cancellation by keeping stakeholders engaged and supportive of the CIDS project.


The CIDS project has been a learning experience for all involved. It demonstrated that the MoD and industry can employ radical agile project management techniques to successfully deliver a technically complex project.

Through using AgilePM on the project, the traditional customer/supplier and prime contractor/subcontractor divides have been bridged to form what truly has been an integrated project team.

The ‘one for all, all for one’ ethos has prevailed throughout, resulting in a team that focused on delivering on the project objectives rather than what is best for individual organisations.

Whilst AgilePM has been central to the delivery of the project, it is not a panacea. The CIDS project has ultimately been successful because of the team – their professionalism, their technical capabilities and their commitment to the principles of AgilePM.

The use of AgilePM was a bold move, but the CIDS project has delivered successful outcomes for all involved.

In the current economic environment, delivering acceptable solutions on time and at a fixed cost is surely a priority for the MoD. The success of the CIDS project may have provided pointers for the future of project management in the defence sector.