The challenges of project management

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.

An introduction to the options

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 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.

“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).

Prince 2

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.

Challenges with existing methodologies

“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:

Challenges when using Prince 2

  • 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

Our Findings

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:

Interested in learning more about Agile? Download our white paper "Seven Elements of Agile You Can Take Outside Software Development", and get in touch to discuss how Box UK can support you at every stage of the journey.

About the author

Box UK

Box UK

Box UK's team of simply brilliant thinkers, consultants and application developers mastermind simply brilliant solutions to the world's toughest, performance-critical web and software assignments.


Gavin Davies

Aug 8th, 2011

Interesting post. My instincts are always to go with agile because that “feels” like how software should be written and in my experience it produces better software.

Box UK

Aug 9th, 2011

Thanks for your feedback, Gav. The next post in this series will look at how we use agile in more detail, however, I definitely agree that writing software using an agile process offers many advantages and wrapping this with some of the Prince 2 techniques provides a good process framework. Talking of “feeling” what gets me excited about using agile is the way the team works together to choose and commit to the work they are going to deliver in a sprint and that incredible feeling you get when the eventual demo goes well.

Chris Waggoner

Aug 16th, 2011

I like the fact that you put focus on the weakness of each methodology. I have always believed that the primary role of project management is to manage expectations. Both methodologies make an attempt to manage expectations and both are successful to a certain extent; however, depending on the individual “personality” of the project, porgram and client(s), either or both methodologies can come up short. Therefore, it is benificial as a PM to understand the strengths and weaknesses of each methodology and to apply them wisely and accordingly to the situation at hand. This is specifically true for a PM consultant who deals with many different business cultures. Personally, I’ve intuitively been combining various methodologies to fit the situation at hand for many years. I’ve never considered documenting a blending of the methodologies. The difficult part will be documenting when to use one methodology over the other and to what extent to use one over the other. In my opinion, just understanding the strengths and weaknesses of each methodology is 90% of the battle. After that its a judgement call based on experience.

Box UK

Aug 16th, 2011

Thank you for your comments, Chris. I think you make a really great point here and I think the pain points are when different methodologies conflict with each other, so knowing where the crossover is can enable you to make the right decision according to the circumstances of the project you are working on. Like you suggest, the circumstances determine what’s best and it’s possible to implement a Scrum process which is abstracted from the client entirely, or if they wish to be more involved you can provide more complete integration which can have many advantages such as increased return on investment and control for the client whilst avoiding more formal change control procedures.

Kenley William

Feb 20th, 2014

Nice Post!

Kenley William

Feb 20th, 2014

As a project manager I use scrum in my projects. One of my friends referred me to use the Guide to Scrum Body of Knowledge by I like the concepts of sprints, daily standup meetings, etc.


Feb 21st, 2014

More and more companies are trying to get nimble to enable them to respond to change with agility. Over the years, there has been a clear shift in momentum about the ways how companies manage projects. So, the project manager should be a PMP certified, who can better handle the planning, execution, and closing of any project. To get yourself prepared for PMP is good one

Add Your Comment

Related content

We're hiring. Let's talk. View available roles