Insight: A project manager view of agile project risks and difficulties

What difficulties and risks do project managers say about agile projects?


In a follow-up to our recently published “Reasons for Agile Failures” survey report, we delve more deeply into one of the datasets from that survey. We felt it was important to explore the reasons behind decisions, particularly for project and program managers. They are invariably the people who feel the immediate impact of any failures.


As a vitally important segment, we surveyed project managers, program managers and portfolio managers and asked them what difficulties they have found when deploying or running agile projects. There were, of course, common themes across teams and companies for agile deployment and implementation initiative, but we found a small number of reasons specific to project and program managers.


Below are the six most common observations made by project and program managers.


These six were by far the frequently cited reasons for agile project problems. Most, if not all of these observations, lend support to the notion of competing priorities and being squeezed from all sides.


1. Lack of executive/director sponsorship & ownership.

This problem was the most commonly stated problem. They often felt that they were set agile deployment as an objective by executives or senior management without the necessary backing of a senior sponsor. When problems inevitably arose, they felt that the sponsor/s did not understand the business context or constraints that existing before embarking on the agile journey. PM after PM describes the frustrations that they felt with executives or senior managers retaining their plan-based (often waterfall) mindset. When push came to shove, the executives and senior managers judged the agile project using the same metrics and standards they used for other non-agile projects.


2.Conflicts between development and customer teams.

Whether external or internal, the customer must be consulted and involved in the agile project implementation. During many projects, the customers were an afterthought. They were not sufficiently trained in the agile development methods that had been selected or were only provided with a last-minute briefing of what would be required. Despite the well-publicised need for heavy and ongoing engagement (and colocation) of customers in the agile development process, many customers had not planned for the effort that was required. This theme presented itself time after time and project managers were still surprised by the negative reaction of the customers.


This caused conflicts originating from both the development teams and the customers. Both had different priorities and were often not insulated from the demands, expectations, and behaviours of customer organisations and other project teams.


3.Remote & distributed teams (or customers) makes it complex and logistically difficult.

Due to the face to face and co-located nature of most agile activities, the recent COVID lockdowns have made these type of dev activities only available over zoom/skype sessions. Like much of the global economy, this has been a major disruption to projects world-wide.


4.Conflicts between the project and PMO, finance, commercial & HR teams.

This is a similar, though distinct, problem for project managers. Unless the rest of the organisation is brought along on the agile journey, or at least provided with revised expectations, there are always plenty of conflicts between the agile teams and different parts of the organisation. By not adjusting expectations of how the agile teams will interact and behave, the constant conflict will doom any agile initiative.


A prime example of this is was when finance and reporting teams required budgets and regular reporting from the agile projects. Often the budgets and reporting requirements were structured in a way that was incompatible with the agile method that the teams were using to run projects. A frequently occurring example was the structure of sprints, backlog prioritising and financial revisions and the corresponding reporting often did not align with corporate requirements.


5.Slow adoption by the dev team, other IT managers, and other teams.

As observed by most staff we surveyed, project and program managers felt that without an appropriate change management strategy, many employees simply did not want to move to agile. This slowness to move impacted the project managers, as this was often set as a key performance objective. Many felt this was unfair, as many of the supports that others had been provided were not yet available to the agile project team.

Many project managers and program managers wanted the team to promote themselves more purposefully. Without the constant communications of changed expectations, many teams external to the agile team forgot about them and went back to their old mindset. They then judged the agile project results with a pre-agile mindset and saw nothing but unknowns and potential risk of failures.


6.Incompatibility with long-term strategy and larger architecture.

The project managers and program managers observed that the mechanisms used in the agile projects were often criticised by enterprise architects as lacking the bigger picture. The managers in the larger organisations found themselves quarantined from the strategy planning sessions and enterprise architecture workshops. They were seen as too much trouble and were perceived to be not delivering or providing other teams with what they needed.


What does this tell us?

The survey results provide us with some insight into the challenges faced by the project managers and program managers in organisations rolling out agile projects.



  • They must continually educate executives and senior managers and ensure that the enthusiasm for the agile deployment doesn’t fade. If they haven’t got a clear understanding of why it needs to be done, they won’t have the commitment when problems occur, and their influence is needed.

  • If you want to implement agile, you need to understand and communicate clearly what problem you want to solve. The reasons for implementing agile need to solve one or more current problems.


Otherwise, they will almost certainly be treated as yet another management fad of the month.

11 views

© 2020 by Method Buzz