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.
Factors affecting project management
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.
“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 as
Prince 2 or ISO 9001 the landscape becomes even more daunting. It’s little wonder therefore that the best way forward isn’t always obvious.
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:
- The Prince 2 process is heavily focused on the client role with little coverage of the supplier –managing product delivery and planning are the only really applicable processes
- The relationship between client and supplier on a project can be constrained
- Extensive planning and costing up-front is required, putting too much pressure on estimation
- There is an inability to downscale for smaller-medium size projects
- The method is documentation- and process-heavy from start to finish
- Inflexible change control procedures discourage ‘good’ change from occurring
- Guidance about where User Experience and visual design fit into the process can be unclear
- It is often impractical to create a virtual team who sit together because of internal departmental workload
- Scrum requires a mind-set change from clients to take more ownership of the product
- There is a lack of formal communication and reporting for stakeholders
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:
- Contractual agreements often heavily influence how much work needs to be done up-front
- Guidance about what the inputs/outputs should be at different stages can be unclear
- Project roles and communication channels that need to be in place are ill-defined
- Terminology clashes between agile and waterfall can cause serious problems with understanding and communication during a project
- Validating sign off points when moving between project stages or confirming features have been successfully completed presents difficulties
- Combined approaches of waterfall and agile techniques can result in a maelstrom effect, particularly when working out which inputs/outputs to use where there are clashes
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:
Images adapted from: