Project management is the lifeblood of any software development; it enables the delivery of client requirements and is instrumental in determining the success of a project. It’s vital, therefore, that project management processes are carefully selected and well defined in advance of work starting to ensure the smooth running of the project and clear communication between all parties.
However, project management can be a challenging concept, something which is amplified in the software industry because of the inherently unpredictable nature of creating different types of products for different types of clients – every project has its own special DNA of sorts.
As a result, choosing the best approach from the plethora of techniques available can be a difficult and, at times, confusing process.
Most of the popular project management methodologies are derived in some way from Waterfall or Agile philosophies, the subject of which continues to divide opinion in the software industry and often internally within different organisations, departments, and teams. In my experience, it’s the perceived predictability and control of Waterfall that attracts some where the flexibility, lack of documentation, and reduced baggage often associated with Agile appeals to others.
When you’re working on the consultancy side, these internal battles are often complicated further by the addition of multiple clients across a wide range of industries, each with their own requirements and preferences. When you need to support different internal processes or industry standards such asPrince 2 or ISO 9001 the landscape becomes even more daunting. It’s little wonder therefore that the best way forward isn’t always obvious.
“It’s the perceived predictability and control of Waterfall that attracts some where the flexibility, lack of documentation, and reduced baggage often associated with Agile appeals to others.”
When comparing waterfall and agile there are a couple of derived processes which epitomise and champion each methodology – Prince 2 (Waterfall) and Scrum (Agile).
With its underpinnings strongly related to Waterfall-based government projects, Prince 2 is particularly strong in the areas of project governance and project management. It’s prescriptive in nature and enforces an end-to-end structure for a project through the use of stage boundaries, checkpoints, and tolerance levels.
Prince 2 provides us with a solid structure for controlling projects and communicating with clients; however it doesn’t define the mechanics of producing software and is heavily focused on the client role in the imposed client-supplier relationship.
Scrum is an Agile product delivery framework that aims to deliver the right solution at the right time. It’s a set of guiding principles based on regular customer feedback and responsiveness to change that ensures features with the most value are delivered earliest.
Through the assumption that detailed requirements emerge during the course of a project, Scrum provides the flexibility to handle change dynamically without jeopardising the overall project objectives, providing a set of processes which we can depend on when development gets chaotic.
“The layers of complexity we’ve identified in managing projects with multiple stakeholders and across multiple industries make it difficult to find the ideal fit for everyone.”
Although Prince 2 and Scrum may each offer many benefits, the layers of complexity we’ve identified in managing projects with multiple stakeholders and across multiple industries make it difficult to find the ideal fit for everyone. This is a challenge we’ve been facing for a while now and in our search for the ideal solution (reviewing, researching, and experimenting with different techniques) we’ve faced a number of problems as outlined below:
At Box UK our project management approach has traditionally been based around Waterfall and Prince 2 with some Agile principles integrated for delivery. For a long time, this has proved to be effective because it was prescriptive and consistent but also meant that clients were well-informed and given the opportunity to regularly review what we’d done. There is of course a trade-off, however, between providing predictability and commitment yet maintaining flexibility, and combining the two approaches brings its own set of challenges:
As a result, we’ve been tinkering with the mix for some time now to try and find the right balance between the more predictive nature of waterfall and the flexibility of agile. What we’re finding is that it’s about using the best parts of the latter to oversee the software development process and making that fit within the project environment. We’ve been so enthused by the results that we’re experimenting with formalising this balance into our own project management methodology to provide a consistent framework for development – we’ll be announcing more news about this soon, so watch this space.
In the meantime, here are some useful resources which we found when researching this expansive topic for ourselves:
Interested in learning more about Agile? Download our white paper “Seven Elements of Agile You Can Take Outside Software Development”.