9 ways to help enable an Agile project controls team.

Although Agile was created for development of apps, there’s a lot we can learn from it and implement to improve teams across entire organisations. Companies implement Agile to empower workers, which in turn increases workplace happiness and boosts the output of the team.

Companies like Spotify have created their own versions of Agile to build incredible products on decoupled architecture, which allows them to release and test their product often.

In fact there are a lot of different Agile frameworks, including Safe, DevOps, Design Thinking, Kanban etc. But the most popular is Scrum.

Scrum is a globally recognised, extremely popular Agile framework created due to a need for a better way to deliver software. Invented by a team led by Jeff Sutherland, they wrote the Agile Manifesto which declares that they value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

You can think of Scrum as a way to get work done as a team, in small pieces at a time, with continuous experimentation and feedback loops along the way to learn and improve as you go. Scrum helps people and teams deliver value incrementally in a collaborative way. Scrum provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs.

As more companies adopt more modern practices, and the younger tech generation continue to pave the way for a digitally driven culture, we are increasingly seeing more businesses look to the same practices that made Silicon Valley companies the biggest and best in the world.

When I was starting out in my career in 2001, Exxon was the largest company by market cap in the world, followed by Walmart. Excel was seen as the equivalent of AI and project managers would grumble if they didn’t have 35 A3 pages of Gantt charts printed on their walls each month.

Although Exxon is still a big business, it’s less than one fifth of the size of Apple, whose incredible growth has come from the art of continuous improvement, customer-focused products, design-first attitude and most importantly, collaboration enabled through distributed ownership and trust.

Organisations as Machines

A typical view of leadership is a hierarchical organisation chart. Communication often flows from top to bottom along just one line, which means it doesn’t match the complexity of problems which moves in several directions at once. Decisions are left to one person, the leader, who, being only human, can become a bottleneck of speed and scale. They can miss new ideas, diverse capabilities and potential that exists all over the organisation.

The hierarchical management culture we are familiar with was developed for factories over 100 years’ ago in 1910. Henry Ford, Frederick Taylor and Henry Gantt (inventor of the Gantt chart) optimised labour productivity. Together they developed the hierarchical organisational structure and created project management as we know it. Their work opened an era of unprecedented effectiveness and efficiency.

Organisations such as Ford were hierarchical and specialized machines. Led by the few who sat at the top, turning people into parts of their well-oiled robotic labour force.

For decades, businesses that embraced this machine model and the principles of Taylor’s scientific management dominated their markets, outperformed other organizations and drew the best talent.

From Taylor onwards – 1911 to 2011 became “the management century.”

Organisations as Organisms

So, things are shifting due to organisational challenges brought on by the “digital revolution” that is transforming industries, economies, and societies.

Organisations are starting to see the value of empowering all employees, leveraging their creativity and using the power of crowd intelligence to elevate the business – creating a network of distributed leadership.

“People are much more likely to do things if they feel a sense of ownership and “it was my idea” versus being told what to do. We need to create leaders, not followers.” – Gitte Frederiksen

Agile organisation’s react by being more than just robust; performance actually improves as more pressure is exerted.

Moreover, such companies simultaneously achieve greater customer centricity, faster time to market, higher revenue growth, lower costs and a more engaged workforce.

We are evolving from organisations as machines – to organisations as organisms. Or from hierarchy to holacracy.

The effectiveness of Agile in engineering

A plethora of companies are increasingly adopting these strategies outside of tech. Actively embracing digital transformation highlights global efforts from incumbent companies to stay relevant in our new world of AI and tech first products.

An incredible success story of Agile in engineering is SAAB and their JAS39e Gripen fighter jet program. They adopted Scrum, minimized organisational hierarchy, worked with 1000+ engineers in 100+ teams and used 3-week sprints over 3-month increments to develop their jet with modular architecture.

SAAB JAS39e Gripen project outcome:

• $15 billion cumulative cost
• $43 million per jet
• $4000 per hour flight cost
• New iteration every 6 months

In comparison, Lockheed Martin used the traditional waterfall approach, with big design upfront for the F35 jet with the following outcome.

Lockheed Martin F35 project outcome:

• $1.5 trillion cumulative cost
• $143 billion over budget
• $337 million per Navy F35C jet
• $31,000 per hour flight cost
• Delayed until 2022

According to Jane’s aviation weekly, the Gripen is the most cost-effective fighter jet ever made.

So, it is safe to say that there are better ways to manage people, teams, and businesses than the one-hundred-year-old, top-down hierarchy.

Who’s using Agile?

Many more companies have now adopted Agile. For example, Shell and Phillips have Agile centers of excellence. Oil giant bp has embraced Agile as part of a business-wide digital transformation, and companies include;

• GE
• Boeing
• Siemens
• BAE
• John Deer
• ING
• BBC
• Disney

And many, many more have followed suit.

How to adopt an Agile Project Controls team.

It’s clear that there are advantages to using Agile to deliver exceptional value.

However, like all big change, it takes a cultural shift in both managers and teams. You need to be open to providing a vision, and allowing the team to deliver it independently, steered by servant leaders who are there to clear roadblocks, and help solve problems. Not manage up and command people to do what they want.

Now, that’s not to say leaders can’t lead, and managers should be fired. But by creating a culture of creative problem solvers and enabling a network of thought leaders in our businesses, much greater problems can be solved.

So, with that in mind, let’s look at how we should set up a project controls team using Agile.

Here’s my 9 top tips for getting it right.

1. Do not reinvent the wheel

Most importantly, you should follow the Agile frameworks. I have seen Project Controls teams fail when implementing this – because they didn’t focus on improving their workflows, only delivering them week-in-week out.

They got bogged down with the BAU (business as usual) processes that absorb your time when churning out reports on large-scale projects. And then Agile didn’t offer the improvement and team morale, it just became another process that got in the way of their massive workloads.

So, follow the rules of the framework, just like you would with PMBOK – you need to respect the rules for it to work properly, otherwise your just another team using a task board.

2. Know your role! – scrum master, product owner, stakeholder.

Scrum has roles! It has them for a reason. It’s important that the team knows who performs what and that the respectful appointees know what they’re doing. The number one reason Agile fails is because of poor management. Just because you use a Kanban and have standups; doesn’t mean you are using (or being) Agile.

In a planning team this is still true. Make sure your Scrum Master (can be someone on the team) is an Agile pro. Ideally your product owner is someone like the planning manager (Agile trained of course), and the stakeholders are the decision makers of the project.

Knowing the roles, allows the people who provide them to work and support the team effectively.

3. Make the schedule, updates, reports & work quality your product.

Agile focuses on exceptional product delivery through continuous improvement. Scheduling teams need to deliver information to managers each reporting cycle so that key decisions can be made. Use these as your “products” each sprint.

Once you understand the breadth of your products, you can plan and deliver effectively and then improve how you do it, to gain ultimate stakeholder satisfaction.

4. Log the time it takes to release your products (updates/reports/decision making content) and try to beat it each month.

Agile isn’t about doing the same task month in, month out – it’s about continuous improvement. The first sprint should be about capturing the time it takes you to do the work you need to keep the project on track. All subsequent sprints should be focused on delivering the products – but faster and better, each time around.

By allowing your team to make their own decisions on how they can start to improve this process, they can start to formulate new ways of getting the work done, and that is where the Agile process comes in.

For example, each item on this list is a project requirement that you would list as a deliverable, with the key fields here being the method and durations of the tasks.

In total there is 20 days’ worth of work, with only 2 days being spent on schedule quality, which in my opinion is the most important output, as this is where your “single source of truth” is maintained.

If you can come out the other end of a project with facts about how much time you removed from processes, time you gave back to the team and efficiencies you created that improved quality, you’re onto a winner, and have some great achievements to include in your CV.

5. Use sprint planning to formulate potential improvements for the coming sprint (not just deliver the BAU work)

Sprint planning happens at the start of each sprint. Work with the team to identify ways to improve on product delivery each month. Look to improve and automate the update process, reporting, analytics and delivery of vital information. All of these tasks take time away from actually planning the work – which is why we’re there in the first place!

Instead, focus on removing as much of the repetitive work as possible from your workflows. Remember, if you must perform a task repeatedly, you can automate it.

People are creative, and being stuck in this repetitive loop of update, report, publish, repeat – absolutely destroys workplace moral. Agile can help teams liberate themselves if you let them be creative.

The proposed method column in this table example, shows how a team could work towards simplifying the process, and can come together to iteratively deliver improvements of the new methods each month.

Eventually, they could automate the entire process, and become a team of highly focused project planners, not updates and report monkeys. Think of the upside for the project and quality of schedule information if almost 100% of their time could be spent on delivering realistic high-quality schedules.

6. Align sprints to your project reporting cycle

Set sprints to the same cadence as your reporting cycles. Keep the rhythm of the project pulse going by introducing sprint planning at the start – close with demos and retrospectives at the end. If you report each month, then utilise a month-long sprint. If it’s bi-weekly, then great – that works too. But it’s best practice not to have sprints longer than a month. 2 weeks is optimal.

7. Retrospectives should provide a forum for the team to express their pain points.

Retrospectives are a wonderful opportunity for the whole team to get together and talk about their successes and pain points from each sprint. Perhaps getting time with a person is difficult and updates are delayed, or it took too much time manually updating actual hours into P6.

Once you identify new pain points to improve, list them, work out new ways to improve, and add them into the next sprint during the in the sprint planning.

The first step of improvement is knowing what to fix! And retrospective provide a sounding board for the team to speak openly and safely, to identify things that went well and things that did not.

8. Hire a data analytics developer, so planners can plan.

Planners are data analysts to a considerable extent, but in reality; a professional Power BI developer or data engineer can take you places your planning team could not. Think professional BI solutions, professionally written DAX, M, Python, semantic data models helping you solve problems, plus the incredible power of Microsoft Azure and Power Automate to help you automate your entire data flows from database or API to report.

This is the kind of stuff you truly need to expertly nail your data project. Whereas most planners will develop solutions that are limited by their understanding, which in my experience means P6 data exported to excel files (or bad XER extraction if you are lucky!) which end up being massive, messy, inconsistent, and unsustainable in the long run.

Additionally, taking time away from planners to do data focused work reduces the quality of the planning. Which defeats the whole point of the exercise. Remember, you are looking for quality in, quality out, with no human hands in the middle.

9. Don’t let the Agile processes be highjacked by a micromanager.

I can tell you from experience, that some managers see daily standups as a progress meeting for them, which it is not! And once they get their claws into the meetings and we start going “around the table” every morning, looking for updates and putting the pressure on, you’ll be left with a team with low moral that absolutely loath the daily standups and hate the manager who beats them up for not delivering badly estimated tasks!

Don’t let it happen! Agile is not about being able to estimate every task you do perfectly (humans are intrinsically bad at estimation), and it is not about having to report your progress to someone every day. It is not a monitoring system!

The stand-up is a quick time-boxed (15 min max) meeting to allow the team members to raise their hands and point out any issues they may have. It is an opportunity to bring issues to the team and leverage the skills of the many to solve problems.

Agile is a process designed to help teams deliver projects where there are a lot of unknowns, and to develop products that continuously improves over time. Its customer focused and helps developers deliver what clients want, rather than what they think they want!

If you get a progress obsessed planning manager in the mix calling team stand-ups the “morning progress update”, then it’s already going badly wrong.

A standup is for the team, and the team only.

Why not try and improve your project controls team’s performance with Agile?

So, there we have my top tips to start using Agile in a Project Controls team, created from experience!

As I mentioned above, Agile doesn’t just start working, and your team become as nimble as a pack of tree climbing cats. It takes buy in from the team and management, an Agile expert, some training and discipline to help your team get really supercharged.

But I promise if you do it properly, you’ll have teams that are:

• Motivated and enjoy the creativity to perform their role
• Value focused and delivering better work month in, month out!
• Improving quality in all aspects of their project controls work, including better quality schedules and information, and faster data updates.
• Automating reporting process and delivering more accurate, reliable data to your decision makers.
• Increased visibility, adaptability, alignment, business value and stakeholder satisfaction.
• Happier in their day-to-day work because they are free from repetitive workflows and are not update/report monkeys anymore!

If you allow your team to be their own leaders, and formulate new, better ways of doing things, you’ll see incredible things happen. Because a person will always work harder on their own ideas than on something they were told to do!

So, if you want to supercharge your Project Controls team, get them working Agile with a focus on process improvement (not just banging out updates and reports).

But remember to get some Agile training in too, so you all know what you’re doing and using the tools, artifacts, and ceremonies properly.

At BaseOne, we deliver all our work using Scrum, so if want to empower your teams to deliver more, but don’t know where to start, please get in touch.

Matt – BaseOne!

Share: