Get decision support faster with agile development


Management and reporting software for decision support is an increasingly essential part of public service delivery, but building fit-for-purpose tools can get bogged down in conservative and expensive intensive design approaches.

To get a new tool developed quickly and with minimal impacts to business, Defence’s Capability Development Group had to break away from process-intensive engineering and accept risk.

A series of failed software projects in the 1980s and 90s led to the complex design and systems engineering approach in common use across the public sector — but a question that we don’t ask often is whether it is sensible to trade off design rigour (and thousands of pages of shelf-ware) to deliver benefits that are “good enough but not perfect” earlier.

Obviously doing so involves a degree of courage and a healthy appetite for medium to high risks — particularly when it comes to a software project — but with some sensible controls it is entirely possible to develop and build a fully functional product that delivers almost exactly what is needed in just six months.

Compare that with traditional waterfall approach which in the same timeframe might barely be half-way through writing and verifying system and architectural requirements.

When he took the role of Commander of Capability Development Group, Lieutenant General John Caligari was dissatisfied at having to wait over a week to be able to understand the greatest risks in the investment portfolio, key information and the current status of each project.

He was also dissatisfied at the enormous amount of effort required to generate a weekly report on the progress and key risks and issues instead of solving problems and managing projects.

The solution: (1) instituting a culture that generated investment and project management intelligence out of business as usual activities; and (2) an agile and evolving information management system capable of meeting emerging needs and making intelligence available for immediate consumption as it matures.

The product is called the Capability Development Management and Reporting Tool.

The first iteration was a SharePoint site — consolidating the key information needed for program and portfolio management and then expanding further into project management information to increase convenience of managing projects from a central point.

Once the central information management system began to deliver value, the demands for greater capability emerged: task management, risk and issue management, diary (or briefs), deliverables, scope management and committee management.

The user base multiplied exponentially across the department when stakeholders and end-users understood that they had immediate access to intelligence about future capability and could take an active part in risk and issue management.

Emerging needs quickly exceeded the capacity of SharePoint, leading to a decision to develop a bespoke second iteration that offered improved work flow, increased security, a database with data available for external applications to utilise, and the capability to present the investment intelligence in different ways for different senior executives to inform decisions they were responsible for.

Processes and regulation would normally prevent a project of this nature from starting up until delivery of a fully engineered system performance specification and agreement that the risk profile associated with realisation of the capability fell within reasonable parameters.

Add to the challenge that the system had to be ready for new starters arriving in only six months and the project arguably had a reasonable degree of risk at the outset.

With the time constraints involved, agile development was the only real option available. The project implemented sprints spanning approximately three to four weeks using the existing system and business process to form the functional elements to be scheduled.

Effectively understanding and managing risks in conjunction with governance and project leadership were critical to the success of this project. The key means of controlling and managing risk to achieve delivery were as follows:

  1. Competent developer — It is vital to have a developer who is competent and can quickly comprehend the business needs and workflows through user engagement in order to trade off effort creating a requirements specification. The ability to mock-up to confirm understanding is highly beneficial. A developer who is unable to meet the demands of agile design will be revealed through their performance in the first two sprints. That is the logical decision point to assess whether the risk of progressing with agile design is sensible, or to change track.
  2. Project governance — Project governance above the project manager is necessary to provide strategic direction, establish constraints and set the key outcomes required for production release and future sprint.
  3. Knowledgeable client lead — A client lead that is critical who understands rationale for business processes and relative benefits of system functionality and the intent of the senior executive is necessary to act as key interface to the developer.
  4. Systems engineer only to the degree necessary — Principles of systems engineering should be applied. Requirements elicitation, design, code-cutting, verification and end-user testing will feature in every sprint, but only to the degree that they are necessary. There’s no point writing a detailed specification if you can better describe what you need by other means such as a scenario description, diagrams or mock-ups.
  5. Design change review team and change agents — A design change review team comprised of actual users and stakeholders is critical to ensure that functionality of the highest value was delivered first. The review team becomes critical in helping the workforce transition to a new product as they are in a position to describe how and why the product behaves as it does.
  6. End-user and user engagement — End-user and user engagement are vital — if there isn’t an effective means to raise issues and see that issues are resolved, users will lose faith in the system. Bring everyone along for the journey.
  7. Balance priorities — Decision priority should be balanced between the needs of the information consumer — senior executives, information suppliers — the many project managers, and technical feasibility and maintainability — developer effort. If there’s disagreement, the senior executive in charge of project governance wins.
  8. Treat identified process weaknesses as an opportunity — Don’t be surprised when weaknesses in your workflows or business rules are revealed during development. Agile development provides an opportunity to change culture when a requirement doesn’t make sense. Where you identify this, shift development to later sprint to give you time to better develop and describe the requirement before kickoff.
  9. Expect rework — without a fully defined requirements set that precisely specified exactly what is to be delivered, you can expect each sprint to achieve somewhere between 80% to 100% satisfaction. The more that can be defined, the greater the likelihood of satisfaction. Rework moves into the next sprint and its priority is considered along with everything else identified for implementation.
  10. Keep to the sprint schedule — stick to the sprint schedule as a key constraint, but understand when the sprint release should to be delayed to address a critical issue and push less important issues to the next sprint. This allows maintenance of progress in parallel to resolving old issues.
  11. Early testing — Early testing is vital to enhance understanding about the way in which the technical implementation satisfies the requirement. The proximity of the developers to the end-user allowed for quick five-minute consultations, which ultimately saved hours of work implementing a solution that would not be satisfactory.
  12. Pause occasionally for documentation — Recognise when a pause is sensible to allow developers to ensure that there is adequate design documentation for the product. The ability future maintainability of the product depends on documentation, but design documentation should be limited to what is required. Trade off less functionality development in one sprint to make sure developers have system design and architecture adequately documented.

About the author
Premium

The essential resource for effective public sector leaders

Can you afford to miss the next briefing from Mandarin Premium? Sign up today.

Get Premium Today

>