The Combat Identification Server (CIdS) Technology Demonstrator Project (TDP) has been delivered to time, quality and budget using the Dynamic Systems Development Method (DSDM®).
This trial application of this method by the Ministry of Defence (MoD) Defence Equipment and Support (DE&S) has:
- Demonstrated the suitability of the application to a DE&S project
- Provided lessons for the future application of DSDM
- Shown the effectiveness of the method in achievement of delivery to time, quality and budget.
The CIdS TDP has been funded by the MoD DE&S Tactical Datalinks Delivery Team (TDL DT) and
delivered by an industry consortium led by General Dynamics United Kingdom Limited. CIdS is a complex
system/software project. The objective is 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 DSDM was a bold move, but the project has 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 DSDM
Traditionally project management in the defence sector has focused on meeting technical requirements, sometimes at the expense of project duration and cost. In a DSDM project, the performance requirements are expressed as Must, Should, Could and Won’t (this time) or ‘MoSCoW’. In the DSDM 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.
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 delivery of Must requirements.
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’ principal of DSDM.
Business and Commercial
From a business perspective the use of DSDM required a significant change in approach to the project.
Traditionally a financial contingency is held, to be called upon if difficulties are encountered in delivering the required project outputs. DSDM renders financial contingency redundant. Instead, the CIdS project requirements were categorised using the MoSCoW approach. Through a trading process during project execution, this 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.
DSDM 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 DSDM 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 DSDM. 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 DSDM 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.
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 DSDM, TDL DT and industry were able to align programme and payments.
Planning the strategy
The project delivery strategy started with the TDL DT requiring the use of DSDM as the project delivery method. With theoretical, but little practical experience of DSDM, the consortium used an external DSDM expert to guide us 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!
Before the team launched into 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 DSDM approach is to progressively reduce risk through incrementally delivering a solution. As such, establishing how the technical solution would be elaborated within the DSDM framework was also a key part of the planning the overall strategy for delivery of the CIdS project.
The selection of DSDM 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 DSDM, the CIdS project comprised three distinct phases. The Foundation Phase developed the requirements, technical design, and also planned in detail the subsequent Exploration/Engineering Phase 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. The final Deployment Phase demonstrated the CIdS solution to end users.
Throughout the CIdS project, focus was maintained on control and metrics regarding achivements within each timebox. Whilst all project timeboxes were planned ahead in outline, 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 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.
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 as well as 3SDL, the TDL DT’s specialist technical advisor. One clear and highly beneficial outcome of using the DSDM ‘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, comprising monthly project reviews with the General Dynamics UK Programme Director and gate reviews at the end of each phase and increment with representation from both industry and the TDL DT.
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. DSDM 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 DSDM provided excellent personal, as well as organisation, learning experience.
Continuous, clear and effective communication has been a mantra for the CIdS project.
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 colocated 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 develop they were effectively addressed to prevent any damage to the day to day working relationships.
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 later.
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 the project developed the plans collaboratively ensuring 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 requirement and partitioning these into a logical development strategy was challenging but the detailing of the timeboxes was eventually achieved.
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
DSDM as project delivery technique was new to everybody and meant that we all learnt together.
Expert DSDM 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 DSDM meant for the CIdS project.
Whilst there was early confusion that DSDM was a substitute for 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 have been recognised and dealt with early, and before they become issues.
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 with their fixation 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.
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, 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 include:
More believable plans, schedules and budgets, and likelihood of adherence were a fundamental outcome as a result of the DSDM approach with its fixed cost and time approach.
Using DSDM led to a contract which eliminated financial contingency, delivery 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 as 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, and has demonstrated that the MoD and industry can employ radical project management techniques to successfully deliver a technically complex project.
Through using DSDM 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 DSDM 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 DSDM.
The use of DSDM 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.