The Boost for BIM Management (Boost FBM or BFBM for short), for those of you who are not familiar with it, is a course in which we provide some management and soft skills modules for professionals for the AEC Industry. It’s aimed at people who already know BIM and consists of 3 weeks in which we […]
The Boost for BIM Management (Boost FBM or BFBM for short), for those of you who are not familiar with it, is a course in which we provide some management and soft skills modules for professionals for the AEC Industry. It’s aimed at people who already know BIM and consists of 3 weeks in which we talk about Agile and Scrum, Lean, risk management, teaching techniques, problem solving, strategy development and much much more.
This is proving to be a particularly special edition because all attendees were coming from Masterkeen 5 (do you remember them? the guys who were interested in Virtual Reality, Robotics, Computational Design and Smart Cities), so we could really squeeze everything out of the days we were given, without having to re-tackle topics like Model Uses, Levels of Development and Common Data Environment.
My module is at the very beginning and it’s a handful of days around Project Management. So, can you guess what I talk about?
1. BIM and Scrum
Giving the strong connection we need to maintain with our digital tools and that we often operate in unstructured (or inefficiently structured) organizations, I find that AGILE in general and Scrum in particular provide efficient suggestions on how to organize our work in BIM in a better way.
I already talked about it here a bit (in Italian), focusing in particular on the BIM Coordinator and his possible role as a Scrum master, following the principles of facilitation and servant leadership.
So, where to put our BIM manager?
1.1. The BIM Manager as Product Owner
This set up works particularly when you have a BIM manager who’s not top notch from a technical point of view and/or is not a big fan of working (and God knows I’ve seen both). In the first case, you have to direct his energies because you don’t want him on the model. In the second case, you have to focus the few days he will dedicate to your project before going to party with the intern.
In both cases, Scrum gives you the Product Backlog as an instrument to list, detail and prioritize features.
If this makes sense at all, you have him working on the part of our BIM Execution Plan in which we have the detailed list of features, correctly prioritized, that are to be included in our information delivery model. According to the Inspect & Adapt coaching cards by Geoff Watts, which I like a lot as a training method, a good Product Backlog needs to be DEEP, meaning:
- Detailed Appropriately;
- Prioritised Ruthlessly.
Which of course applies perfectly to the kind of document we need.
The same cards provide suggestions for activities, in order for a Product Owner to INVEST more on the features of the Product Backlog, meaning to make them:
- Independet from one another and solution-agnostic: if your product owner doesn’t possess technical skills, you don’t want him going around to suggest software and formats just because he had seen mention of it somewhere;
- Negotiable in terms of priority and implementation: one feature might be crucial but it’s not obvious that we can implement it before implementing others and only a technical manager (our BIM coordinator as the Scrum master) can provide feedback on that;
- Valuable in and of themselves (i.e. are they vertical slices?): each feature, each model use, should have a value and be reasonably independent from the others: the team will put them together in sequential order, based on the technical solutions they choose, with the help of the Scrum Master. If this is not the case, the problem is probably in the conceptual framework used for the product backlog.
- Estimable: both in terms of time, effort and cost, we should be able to put each feature into numbers, which means that they should be adeguately detailed.
- Sized appropriately: in a Scrum product backlog you usually start with smaller items (our components, for instance) and you build up incrementally to create the bigger features.
- Testable: a good feature has a clear definition of “finished” and “working” and can be tested in its working environment or against a quality benchmark.
That being said, according to th same coaching cards deck, great product owners are:
I never tried my hand at the role, so I wouldn’t know, but that sounds like a good BIM manager to me.
1.2. The BIM Coordinator as Scrum Master
I already went into detail on how this could work, so I’ll just skim the surface of this topic, using some suggestions from the same coaching cards. If you like this instrument, I suggest you also check out the Scrum Mastery Quote Cards, a good learning tool from the book authored by Geoff Watts about Servant Leadership.
Great Scrum Masters are RETRAINED:
That sounds like a good BIM coordinator to me.
If I retrospectively thing about both successes and failures in this role, I can easily trace back both of them to particular lacks or strenghts in these features.
Again if we’re seeing this from a BIM manager point of view, it might be good to think about how you can help your coordinators be more respected, or how you can empower them to be really disruptive. Food for thoughts.
Hint: they use funny acronyms so that you have a better chance to remember this suff. Try and create your own.