Project management: agile methodology
Able and agile
25 May 2017
How can innovative planning techniques from the software industry be applied to construction? Pieter Rautenbach reflects
The construction industry is notorious for projects going over budget. Regular criticisms include a lack of customer focus, ineffective use of technology, poor contractor relationships and communication.
Rapid advances in technology have affected many industries, including construction. It is important for organisations to be able to adapt quickly: projects often fail due to ineffective risk management or poor communication when changes do occur, an issue that is exacerbated by poor planning.
Being agile
Agile methodology was developed in the software industry to deal with a rapidly evolving business environment. It is designed as an alternative to traditional project management and focuses on iterative, incremental development so teams can respond effectively to change.
In the agile approach, a project is broken down into small, fixed timeframes known as sprints or iterations, and an integrated team is responsible for each of these. They follow the principles of the “Agile Manifesto” of 2001, drafted by software practitioners:
- individuals and interactions are more important than process and tools;
- working software is more important than comprehensive documentation;
- customer collaboration is more important than contract negotiation; and
- responding to change is more important than following a plan.
Being agile encourages teams to test concepts before moving on to the next phase and use feedback rather than relying on predetermined assumptions.
Agile or traditional?
Rather than having a top-down system where team members are told what to do by the project manager, agile principles enable those responsible for the work to decide which work to carry out.
The key features of traditional project management are as follows:
- scope is defined before work starts;
- payment is linked to fulfilling this in a predefined time period; and
- change is viewed as a risk and therefore discouraged, though some changes are inevitable.
The agile project management framework instead allows the scope to be refined constantly to provide the most value. The client, consultants and contractors work together with common goals that take this into account. The differences between agile and traditional project management are shown in Table 1; similarities are shown in Table 2.
| Agile | Traditional project management | |
|---|---|---|
| Scope | Not fixed; most important tasks are completed first according to user stories | Generally fixed scope divided into a work breakdown structure and work packages |
| Planning | Detailed plan delivered on an as needed basis, and tasks continuously prioritised to create value. Resource responsible for completing the task decides what work will be carried out | Detailed plan developed upfront, with a focus on adhering to this. Resource responsible for completing work is told what to do by manager |
| Goals | Providing value to customer | Meeting contractual obligations |
| Design theory | Design is optimised to create value | Work is carried out to meet the objectives of the design and specifications |
| Customer input and feedback | Customer input and decision-making required throughout project and feedback is continuous during each iteration | Customer input required early in project; customer feedback generally given at the end of the project |
| Quality control | Quality control is completed for every activity as the activity itself is completed | Quality inspection is conducted at the end of the project |
| Organisational culture and management | Collaborative team where all stakeholders have input. Continuous improvement is part of the ongoing process | Command and control with strict hierarchy. Lessons learnt are implemented in the next phase or project |
| Contract theory | A shared risk, shared reward contract is implemented to encourage aligned outcomes | The contractor is generally motivated by contract milestones and meeting specifications within a certain timeframe and for a fixed fee |
Table 1: Differences between agile and traditional project management
| Agile | Traditional project management | |
|---|---|---|
| Weekly plan | Sprint/iteration | Weekly work plan |
| Presentation of work completed | Customer showcase | Site inspection |
| Review of work completed | Sprint retrospective | Weekly review |
| Graphical report of work completed | Agile burndown chart | S-curve reports |
Table 2: Similarities between agile and traditional project management
Construction projects often fail to meet customers’ expectations because project teams are unable to communicate properly or deal with change effectively. The software industry has successfully responded to similar issues by focusing on providing value for the customer.
Customer behaviour
Customer input is key to ensuring that the project team focuses on value-generating tasks, and the manifesto recommends that this collaboration be preferred to contract negotiation. It is therefore important for the contract strategy to allow both parties to communicate freely without jeopardising their respective commercial positions, as opposed to traditional command and control relationships. This requires trust to be developed over time. To encourage iterative learning, individuals must be able to talk openly about mistakes without fear of retribution.
Contract preparation
Software companies have found that fixed-price contracts are not a good match for agile principles, as projects working under such principles must embrace change; clauses that enable the customer to terminate the contract easily have also been used to entice customers in the software industry to try more agile strategies. These measures may only be applicable to construction projects on a case-by-case basis, however.
In construction, shared risk and reward contracts are becoming more prevalent. Several standard forms of shared risk and reward agreements already exist. It is important that shared risk contracts provide value for the client and allow the contractor or design team to make a fair profit, as it is for all stakeholders to be given adequate governance of their risk.
In the detail
When agile principles are applied, the detailed sequence of activities is not decided in advance. Traditional project management tends to focus on developing a detailed plan upfront, assigning the tasks to the team – “push planning” – and following the plan as closely as possible, with a recovery plan developed when the project is delayed. The problem with maintaining a detailed plan upfront, though, is that sometimes changes occur quicker than the detailed recovery plan is able to take into account.
Under agile principles, the project team discusses, develops and refines the short- and medium-term plans on a continuous basis. This avoids the need to develop a detailed plan beforehand or recovery plans when events deviate from those predicted.
“Pull planning” is adopted under agile principles, as opposed to traditional “push planning”. The person responsible for completing the activity should choose the work to be done and be accountable for finishing it. The detailed planning tends to occur on an as-needed basis closer to the time when the activity is about to start, and the inevitable changes that occur on projects are accepted. The person responsible for completing the tasks determines the resources and time required to do so.
Constructive agility
The uptake of agile or other short-term collaborative planning techniques in the construction industry has been slow, but is gaining traction. Agile approaches are not yet well understood in construction, and there may be a training cost for adopting them.
Application of agile principles in construction is more difficult than in the software industry due to the nature of the workforce, too – a result of the short-term contractors and large number of parties with different interests that tend to be involved.
Existing forms of contract and the difficulty of establishing trust between different parties in construction will need to be addressed before collaborative agile or similar principles can be successfully implemented.
There are instances in the construction industry where short-term collaborative techniques have been successfully implemented. One such is the last planner system – a collaborative, commitment-based planning device that was derived from lean methodology in the 1980s – and major improvements have been achieved on projects that adopt this.
Agile and lean are not the same but have themes that overlap, such as:
- providing early value for customers;
- using self-organising teams;
- removing unnecessary steps;
- completing work in iterations; and
- developing work in response to evolving requirements.
There are cases where collaborative short-term planning has reduced construction durations, increased customer satisfaction and improved project success rates. The lean construction movement has shown that collaborative, self-organising and empowered teams that focus on providing customer value can be effective in construction, and that there is also great potential still for agile techniques.
While some existing processes in construction align with agile principles, significant changes will be needed at an organisational level to implement them effectively. The hierarchical structures to which the industry has become accustomed must be adapted to allow a more self-organising, integrated team approach. Parties working for different organisations will need to communicate openly and honestly for agile principles to be successfully implemented.
Existing construction contracts have been developed to avoid risk, but. these too will need to change so as to align with the expectations of all team members. Shared risk and reward contracts appear to be better suited to the agile way of thinking. Conversely, the fragmented nature of existing construction practice and the potential cost of learning are barriers to implementation.
Despite these hurdles, there is great potential for the methodology to have a positive impact in construction and overcome significant issues in terms of time and budget management.
Pieter Rautenbach is State Manager (Queensland) at Red Arrow Group
Further information
- Related competencies include Programming and planning
- This feature is taken from the RICS Construction journal (April/May 2017)