Managing Software Development Risk

Posted on 30 July 2015

A software development project can be a significant investment so it makes sense to manage your risk with strong project management. The traditional waterfall method is relatively inflexible and can increase that risk, though there are times when that strict approach is warranted. Another project management technique called agile is much more flexible and has become widely adopted, but doesn’t always meet a client’s needs. Stratos Technology Partners has taken the best of both methods to create a hybrid approach so we can tailor project management processes for each client’s requirements.

Very broadly, the agile school of project delivery says that complex things like software can be built efficiently using the principles of iterative development, strong team engagement and a single-minded focus on work that delivers immediate value. The once-fringe concept has become mainstream since its genesis nearly 15 years ago, and many project frameworks support it.

Having used several agile frameworks and with three certified ScrumMasters (loosely akin to project managers in the Scrum agile framework) amongst our ranks, we are no strangers to the agile mindset. However, many of the organisations we work with have governance and operational requirements for upfront documentation to define the what, how, who, when and how much.

In response, Stratos has adopted a software delivery approach that takes the best of traditional project management’s upfront planning and the, well, agility of agile to refine the plan during the project. Using this hybrid method for projects of all shapes and sizes, our clients and developers benefit from:

In other words, everyone understands where they’re headed and the rules of engagement. Agile purists might well take issue with our process, but we stand by the point that agile should be, by its very nature, flexible.

The process should scale to suit the team – including the client, with or without any aforementioned requirements for a formal project delivery approach – and size of the project.

We begin with business analysis to identify and validate the functional and technical requirements. The result might be a specification document for client stakeholders, or it might be a prototype that users can interact with. We only go into as much detail as the client and development team require to understand the end-result of the project and be ready to initiate development.

We review the requirements in detail with the client to ensure we’ve understood their need correctly and have a mutual understanding of the next steps. The requirements are then signed off by the client, and the second phase begins.

The development team turns the requirements into a series of use cases which are, in turn, broken into tasks to implement the solution. The schedule is comprised of cycles (sprints, in agile speak) of short periods in which work will be completed and reviewed. For projects of any considerable size, a sprint usually lasts two weeks, but this is adjusted to meet client comfort levels and needs.

The team plans the order in which tasks will be completed, and tasks that are fundamental to underlying architecture or that carry the highest risk are prioritised for the initial sprint; the remaining tasks are put in a backlog. Development begins. The backlog is routinely reviewed with the client to ensure it’s still relevant to users and the organisation’s objectives.

Successive sprints are preliminarily planned but not in too much detail, allowing for more flexibility as the unknown becomes known. At the end of each sprint the client participates in a review of the sprint’s outputs. The rapid review cycle enables clients to:

See progress

Provide early feedback if the solution varies from what they had envisioned – at a time when change is usually less expensive to make

Ask the developers questions and talk about what’s been done to date

The review is also the time to drill into what the team (developers, client representatives, and other key stakeholders) has learned, whether changes are necessary and how they can be achieved efficiently. Together we discuss the impact of these refinements on the bigger picture, update the backlog and better plan future sprints. Development continues.

The final stage is deployment. We’ve tested individual components during sprints, but before the client commences user acceptance testing (UAT), a new tester performs end-to-end testing. Speaking of UAT, where feasible it will include installation at a pilot site and training so the system can be put through its paces in an environment that mirrors its long-term use as closely as possible.

All this time, we continue to maintain requirements documentation to the level that the client needs. This often becomes an artefact of the project for decision making and support after the project is completed. By now, developers, testers, and the client have accepted the project deliverables, and it’s time to roll out.

Training and support, if included in the scope of the project, is provided. And depending on the size of the project, the governance team will have agreed to a change management process for feature requests from system users post-launch. But that’s a topic for another day.

In short, our hybrid approach captures as much as possible about what we know about the project and its deliverables upfront. By breaking the project up into small units and reviewing each piece of work with our client, the work may be confirmed or new learnings may be incorporated into the project’s direction and feature set. This process engages clients with the design so the chances of producing a satisfying result is high and the transition to training and adoption is also smoothed.

* If you’d like to find out more about our hybrid agile method please don’t hesitate to contact us: hello@stp.co.nz.