Skip to content

Rigidity in project approaches needs to be addressed

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content
Shutterstock 1233205306

Have you ever wondered why it seems so hard to apply agile methodologies to the construction industry? Why does work in construction seem so rigid and old-fashioned? Well, the easy answer to this question is: because you can’t build a wall twice and you can’t run a sprint to fix any mistakes to something as permanent as a wall.

This, or some variation of it, was always the answer I would hear when debating this topic with other project professionals. But if you think about this answer a bit, you realise that it actually only refers to the execution phase of a project. What happens during the other phases? Can agile be used successfully during the initiating, planning, controlling or closing phases?

Agile principles can be applied more widely

I first explored this topic while pursuing a master’s degree in project management, where I applied scrum principles to the planning process of a small photovoltaic installation. Interestingly, I found that not only can these principles be applied successfully, but they can also increase the probability of project success as they engage the customer throughout and increase the transparency of information.

This was, however, only a small change in a relatively small-scale project. In construction, you often find more complicated projects that require intensive planning and years of execution – can the same concepts be applied?

It is precisely because of this complexity that there is more space for the exploration of the application of different agile methodologies. If project professionals are not trying to incorporate agile into different areas of their projects, it can be as detrimental as when they are not aware of which tools and processes are used by teams that sit next to each other.

The adoption of these new methodologies has risen due to challenges that are felt universally in project management; and since they exist, why not explore them, as they can potentially help make things better?

Look to recruitment process to increase project success

We are always looking back and trying to identify what went wrong and why a project exceeded its initial estimation in terms of scope, budget, time etc – but instead we should try to embrace professional diversity a bit more. With this, I am not only talking about the construction industry and scrum, but any industry that seems to work in a more rigid and old-fashioned way. Organisations that have established a PMO structure and standardised a lot of their processes throughout projects should embrace these practices a bit more.

This lack of ‘cross-pollination’ across industries is in many ways due to deficiencies in recruitment processes that seem to look for quick wins. It is my experience that companies are mostly looking to bring in candidates who have backgrounds that are as closely aligned as possible to the position they are hiring for.

Internally, the company may be praising itself for talking about diversity and emphasising how it can create value, but it seems that when it comes to recruiting, professional diversity is not considered. In project management, in particular, the foundational skill sets are for the most part industry-agnostic. Yet in recruiting new talent, these transferable skill sets are not often considered.

Furthermore, project professionals tend to follow one methodology throughout the entirety of projects. Organisations also create standard operating procedures for projects that repeat the same methodology from start to finish. Engagement of different methodologies at different stages of a project should also be explored and potentially applied.

Designing is not the same as installation, and planning is not the same as execution. Applying one methodology consistently in all phases creates a feeling of regularity, but each phase has different requirements and adaptability prospects. And so, therefore, it should be considered whether they should be approached differently.

We can’t apply agile if we are not open to new ideas

If I were to summarise in one sentence all that has been mentioned above, it would be: bring people with different experiences and exposure to different industries to fill the roles within your team.

I am sure I am not the only person who has felt that I would be a great fit for a particular role, but then have been rejected because of a lack of relevant industry experience.

We cannot talk about applying agile methodologies to our projects when we are not flexible and open to new ideas, and diverse candidates are often the ones that bring this to our companies and teams.

Praise diversity, but make sure you apply it in many ways and you will see the benefits of it in many different aspects of the organisation.

You may also be interested in:


Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Ian Heptinstall
    Ian Heptinstall 05 May 2022, 08:26 AM

    My one challenge Vasilis is the claim about agile methods being "new". Likewise working in a "rigid way" has nothing to do with the past ("old-fashioned" you said). I agree with what I see as your underlying message - that rigidity and inflexibility reduces project performance. In my experience good PMs have always known and done something about this. Also I fully agree with the benefit of professional diversity and having a broad mix of experiences in a project team. Coming back to agile, a few specific techniques seem new, but most are well established practices that often got overlooked or forgotten. The values and principles in the Manifesto for Agile Software Development, always seemed to me to reflect what good PMs did. (Even though it was not written about projects.) Maybe not in many large software development projects of the late 20th century, but definitely in the wider business and PM world. For example the advantage of processing work in small batch sizes was well established in operations management before agile became a thing. This idea was embedded into some large company project processes (for example the chemicals company I worked 35+ years ago), though it didn't seem to explicitly appear in the PM BOKs. It was one of those things that was done by some, but not captured for all. Isn't the idea of sprint-retrospective-improve-repeat an application of the Shewhart/Deming PDSA/PDCA cycle? And my first even working day in August 1985 started with a short stand-up meeting of the management team reviewing the last 24 hours production. I remember running a project moving to a new office in the late 90's, and the idea of stand-up meeting rooms, and visual management were two of the established ideas we incorporated I'm not not saying 'agile' is not a useful and convenient way to learn a number of good practices, either as a newcomer to the profession, or someone with deep experience in one domain/phase who needs to broaden their PM skillset. But, whilst the methods themselves may be new to some, they are not 'new to the world'. Though of course if you are a consultant selling services or training to a senior budget holder, I do understand why you might not point this out to your potential client!!