How can built environment designers use Kanban?

Find out how to use Kanban in your built environment design practice to achieve better project management.

You know what Kanban is, but how can (-can) your architecture, engineering, or construction design practice use it? Great question. Excellent question in fact. Indeed, it’s the industry-specific utility of the Kanban management method that drives this, the second in our Kanban series, blog. So read on for answers, you champions of AEC. We’ll keep this snappy — we know that brevity’s your bro when you’re busy (and you are).

Kanban makes project planning your strong point

Total Synergy’s product manager, Paul Hemmings, was himself a crafter of the built environment for many years, as an architect with his own practice. Lucky for us he later turned his attention and skill to mastering the world of development. Um, does that make him the perfect guy to speak to about this? Why, yes it does. So, yes we did.

“Generally, architects and engineers don’t do a lot of project management at university” said Paul, “You’re meant to learn about that once you get out in the real world, and then you’re learning it from people that didn’t learn much project management at university. Project management tends to happen more as a team of people working collaboratively and slogging their way through projects, just trying to get it done. The easiest initial way people tend to look at that is in terms of the amount of effort that a project’s going to require — people look at that like, ‘Here’s a job. How long will that take? Oh, that looks like it’ll take three people six weeks. Yeah. Okay. That’s fine.’ And so, we’d do that. That’s what we’d call project planning.”

Ok. But in project planning, you’re working with teams at a very high-level overview, approximating man/woman/nonbinary hours required to complete the work of the whole project. Then assigning a team to do that work. Pretty broad, and dare we say it, pretty guess-work oriented.

“But then once it gets started” said Paul, “you’ve got all these people, and they’re saying, ‘Okay, so what are we going to do now?’ That’s when you need to have a more granular way of looking at the world of your project.”

And that granularity, is where Kanban comes in, friends! It is a visual work management method after all, remember?!

‘To-do: design awesome building’ — why you need to break it down

So, what do you have to do? You have to look at the work items you’ve got in front of you. That might be ‘design an awesome building’. Weeeeeeeeell, ok. That’s concise, which is nice. But you can’t just do that and tick it off your list. You’ve got to break it down into chunks.

“You then need to look at it” said Paul, “in terms of asking yourself, ‘what are the big chunks’? And then you look at the big chunks and break them down into smaller chunks, then look at those chunks and break those down into even smaller chunks.

“You should try and work out your project in what development teams call ‘sprints’. Maybe they’re called ‘stages’ for an architectural or engineering practice workflow, and you might have a stage called ‘conceptual design’. But it’s still too big a thing to say, ‘You guys all go and do the conceptual design.’

“You need to break it down further. And conventional wisdom in is that you break it down until you get chunks of work, which are a day or two. The reason for that is you can put them in an order, and you can ask any team member, ‘What are you doing tomorrow? This thing that will take you two days? Okay.’ In two days’ time, if they haven’t finished it, you can look at the Kanban board (with cards moving left to right as they progress toward completion) and say, ‘hold on a second. There seems to be a blockage here’.”

How to create your Kanban cards

So, each one or two-day block of work is represented by a card on the Kanban board, and by looking at that board, you can instantly see where/what holdups are. Not bad at all is it? But remember that size does matter.

As Paul said, “if you make the chunks too big, like assigning one piece of work (or card) a three-week timeframe, it’s really hard halfway through to know if you’re actually halfway through the work or not.”

Excellent point, Paul! Look at it this way, folks, if you’ve broken your project down into smaller chunks for each Kanban card:

  • It makes problems really visible, really quickly
  • It makes it really clear what people are working on
  • It makes it clear in what order people are working in
  • When it comes time to review those chunks, review is expedited because (you guessed it) there are smaller chunks to review and they have the above features

The beauty of Kanban cards for resourcing

“If you were managing a construction project, doing the floor plans” said Paul, “you might need a dozen floor plans. Let’s say you know they generally take around a day or two each to complete, so you generate a Kanban card for each of the floor plans. And actually, now that you’ve generated those cards, you can split them up. You could say, ‘You do these ones, and I’ll do those ones’. It makes it easier to look at a job in terms of separable components that you can share amongst the team.”

Niiiiiiiiice. Very nice. You’ve gone from saying, ‘Who’s working on my project? I’m guessing I need three people for six weeks’, then getting the sense that the project is running late, then going to the resourcing meeting to start begging for people from other teams for an unspecified period of time. To knowing the number of hours you’ll need someone for, and the specific tasks they need to complete.

With Kanban you can be all, ‘Look, I’ve got six drawings here that take two days a piece — I’m going to need Mary for 12 days, because she’s the best at drafting and here are the reasons’. You boss, you!

Wait a minute, doesn’t that smell like bureaucracy?

We can hear you asking this now, and we’re sympathetic, we really are. We’re not keen on anything that seems like an addition to our workloads, and isn’t actually the doing of our work (#MoreTimeForDesign). However, as the old but accurate adage goes, ‘if you fail to plan, plan to fail’.

“A bit of bureaucracy at the beginning of a project makes everybody feel more comfortable that the job is going to be delivered on time and on budget. So it is worth doing” said Paul, “And if that means everybody’s sleeping better at night, then they’re going to be happier at work the next day. You won’t have as many arguments. It’s all good for everybody.”

That’s enough for us!

Not enough for you? In the next and final blog in this series we’re talking to real-life built environment businesses to get the scoop on how they’re using Kanban to crush it with their project planning and delivery.

Stay tuned.

More To Explore

Product

Product

Platform

Solutions
Resources
About
Clients

Plans

Book a demo

Sign up to our newsletter!

Ready for exclusive updates and exciting content? 🎉 Don’t miss out! Fill in the form below and join our newsletter community! 📧📝 Stay informed and inspired!