top of page
  • Planifi

Project Retrospectives for Engineers and Architects

Project Retrospectives are a concept widely used in Agile project management: what they are; how they can improve your design projects; and how to get started.


In this video experienced design industry leaders JJ Brantingham and Don Archibeque discuss their process for project retrospectives to help your firm perform better.


Overview and Introduction: Why and How Should we do Project Retrospectives


JJ Brantingham (00:00):

Hello, I'm JJ Brantingham. I'm here with Don Archibeque. We're both from Planifi, and we're here today to talk about how to do a project retrospective. Obviously we'll start by introducing what it is, what are the benefits, and how do you get started. By way of background, Don Archibeque here has 30 plus years experience in A/E, not only as a project manager, but as a director of project managers, reviewing project management teams and enhancing them. Don also spent time on the other side of the table as an Owner's Rep. Myself, I spent 20 years, well over 20 years, spent time as a principal at a firm in operations, IT, and finance.

(00:46):


So again, as I mentioned, we're going to get started by explaining what a retrospective is, what are the benefits of performing those retrospectives, and how to get started if you're interested or it sounds good. So obviously to get started, what's a retrospective? If you're not familiar, these are short meetings to basically uncover learnings, mentor and enhance your project teams, uncover challenges, issues, opportunities. They're not about blaming, they're about discovering and improving, and they're short meetings. They shouldn't be one hour meetings. We're looking at 10 to 30 minutes with the project teams.

(01:28): And then the next sort of sticky wicket is how often do you do them? Some people prescribe to more of a regular basis. Others look at doing things at the end of milestones and phases. The important part is that they're not too far apart. Three months gets to be too long, and frankly too late to make corrections. But more importantly, a lot of things get lost or forgotten. So let's talk about ... Don, you ran a lot of these meetings with your teams. How did you figure out the best pattern to get started with your groups?


How Often Should we Conduct Project Retrospectives?

Don Archibeque (02:06):

So first of all, thinking about when to do these retrospectives, it's kind of like asking a person, what did you have for dinner last night? Well, it's really clear. They can tell you what was great about the dinner, maybe what wasn't so great about the dinner. They can even tell you the ingredients that went into preparing the dinner. But if you wait two weeks, it becomes less clear, and I think you start to lose detail that you can actually learn from. While each project phase is just like a dinner, every one is different. And so as you are going through a project, there are typically a series of deliverables that you're required to prepare and send out for review, whether it be in the schematic design phase or design development phase or whatever.

(02:56) And there are times within that work where it's important for you to take a look at, okay, how did this go? Did we have all the information we needed? Did the scope increase? Did the scope decrease? How are we doing for time? There are just a lot of things that need to be communicated as efficiently as possible creating standard process for information exchange. And I think that's one of the real benefits of a retrospective. You gain learnings very, very quickly and efficiently. You provide communication about those learning in real time. Did I mention very efficiently as well?

JJ Brantingham (03:33):

Yep. Yep. Great. So obviously, our point here is your need to evaluate the size of your projects, what type of work you're doing to sort of align the retrospective timing to the work you're doing. Obviously environmental, those are going to be really quick and maybe you'll combine a bunch of them together. For other services, other design projects, you're going to maybe space them out a little bit more, but you'll look at it to schedule them around those deliverables and throughout key parts of the project.

(04:04):

And the second part is, it's really reviewing project status. And as I mentioned before, uncovering issues, proactive implementation of counter measures, but just as importantly, talking about learning successes, challenges, problems that are going to pop up, but it's not about blaming, this is about learning. And then that's where that last part of praising and mentoring comes in to the process.

(04:30):


What is the Goal of a Project Retrospective?

So that's the goal, that's what we're trying to achieve. So let's talk about the next thing, what are some of the benefits of this? Why should you consider doing these retrospectives? Well, we'll just talk through each one of these a little bit. Improve project performance. As these issues are uncovered earlier on, you're trying to discover those problems, and it's not after the fact, or too late to solve.


Don Archibeque (05:00):

Right. I mean, there's a million analogies a person can make, but let's take the marathon analogy. That always works for me. You don't want to wait , if you're running a 26 mile marathon, till mile 16 before you take corrective measures. You need to be shouting out your splits and understanding how you're doing for the time that you've allotted to run your marathon. And it's a lot easier to make a 15 second per mile improvement as opposed to a minute 30 second per mile improvement. So the longer you wait to take corrective actions and implement corrective measures, the harder it is to actually do the assigned work and take those corrective measures. Small adjustments closer to real time is going to provide more consistent positive results.


JJ Brantingham (05:54):

Yep. And in a project, that just equates to splits are more or less your burn rate, how much time, how much work, how many hours are you spending. It also relates to the deliverables. You don't want to wait till the deliverable's almost complete, the design's complete, to uncover a problem, that maybe different design teams, mechanical, electrical didn't coordinate or civil and mechanical had different thoughts. So getting those teams coordinated, too, to uncover problems earlier on is a big benefit.


Team Collaboration and Communication

Don Archibeque (06:29):

You know, it leads to that'" if not, why not discussion". And when the team's there, a lot of the times the team really takes a hand in helping solve the situation that a particular discipline is running into. Maybe there are obstacles that are in the way that can be removed, and so having the team hear what's really going very well. Or conversly what obstacles need to be removed is a good thing for everyone involved.


JJ Brantingham (06:56):

Yep. And that's really our second point right there, team problem solving is going to result in better design decisions at the end of the day. Getting those heads around the table for short meetings to talk about recent work, potential upcoming work, too, a great chance to improve those, or at least a much higher probability that you're going to come to a better decision. (07:22): Reduced out-of-scope work, and that's maybe not intuitive, right? You maybe wouldn't think that's an outcome, but it really is, you know, a quick conversation about what are people working on. Say if someone, maybe, got a request from the owner maintenance group. The team thought maybe that was a good idea, something they should start to work on, but it could be out-of-scope.


Don Archibeque (07:46):

Yeah, any time a scope increases or decreases, it's going to have an effect not only on money but time. And all team disciplines that need to be aware of what's going on. So what is this difference in scope that we're discussing and how does it affect the team as a whole? Lot of times you find that a scope increase might be directed at a particular discipline. They take off running in that direction, only to realize later on in the project that maybe the rest of the team wasn't up to speed with that scope issue.


JJ Brantingham (08:24):

Yeah, and we talked about before, but there's usually multiple stakeholders involved with client projects. So if some of those other stakeholders are getting involved, they might be unknowingly increasing scope on the client end, and this is all about better communication is going to keep that scope aligned correctly, to keep both you and the client satisfied. But this discussion does bring up our next one. Uncover those change orders. So if it is something that the stakeholders feel they need, now, earlier on, is the time to talk about that before you did the work.


Handling Scope Creep

Don Archibeque (08:59):

Yeah. That's the amazing thing I find with working with A/E teams is so much of the time they really struggle with asking for compensation for the work that they're doing above and beyond the original contract price. And I think this is where the team can come to the assistance of the individual discipline team lead. If there has been a change in scope and compensation is due, I think that the team is pretty good about pointing out, hey, this is the impact on the project overall, whether it's additional hours, whether it's maybe bringing in some more specialized expertise, or just a number of things that go along with that, and there's a number of impacts it's going to have with the adjacent disciplines and projects. So change order management and retrospectives work together like peanut butter and jelly. It's a good thing.


JJ Brantingham (09:55):

Yep. Yep. We've got a whole session on change orders and the no cost change order, which turns into the cost change order later. So keep an eye out for that. Next one's a little less intuitive. We're talking about proactive project management, but we're doing, talking about retrospectives, looking in the back, but really this means less rear view, because the idea, again, is to do these in such frequency that you're catching problems and talking about what's coming up at the same time, and thus creating more proactive solution and project management. Right?


Don Archibeque (10:35):

Yes. One of the big objectives I think that we at Planifi try to really communicate to project teams is that I think for many, many years we've looked at data showing how much we've invoiced, how many hours we've spent. Now what we're trying to do is get folks to start looking forward and really planning ahead and then managing to that plan. So it's kind of like in pool, you call your shots and then you execute that work and make the shots. And that's really what we're trying to get to, is just call your shots, execute the work, make your shots within the requisite time and fee that you've been allowed.

(11:18): And in order to do that, you have to do some pre-planning. And a lot of the times you find that there are things that could preclude you from actually executing the way you thought you were going to. Those things that keep you from executing exactly the way you thought you were going to. These are learnings, and learnings that can be put into place for the next series of deliverables that you're going to have. And as you continue to gain this knowledge during the course of the project, every phase gets better, more efficient, and you continually pick up momentum as you lead toward a successful outcome.



JJ Brantingham (11:57):

Yeah, exactly. It's about uncovering learnings earlier. You might find out that part of the client team is not responsive, and if you wait until the end of schematic design for the PM to find that out, the PM doesn't have that opportunity to go reach out to the customer and talk about how do we solve this. This is the type of obstacle that can be effectively and proactively managed.

(12:21): The other thing I'd like to contrast this remote with, the way a lot of firms do what they think is a retrospective is, some sort of a PM roast, or they have at the end of the project, they have the PM comment and talk about a little bit about what went right and a whole lot about what went wrong. But there's limited learnings there. There is less opportunity to take corrective actions on that project. Hopefully the idea is, if you're doing these more frequently, you're not waiting until the end of the project to do a roast and uncover it. There's learnings along the way to improve it. (12:57):

And again, that's why we're talking about less rear view and getting the team aligned and communicating. Which is our last point, reviews more frequently, and that you're not doing the PM roast approach. Just again because there's too many learnings that are lost and you're trying to roll up and blame a project on one thing, when Don and I both know, having been in those meetings, there's 10 things that contributed to a project going wrong. And that's probably mild. It's probably more like 100. And to try to roll those all up into a 15 minute summary is frankly probably not that useful. Right?


Don Archibeque (13:36):

Yeah, absolutely, We're working to create enhanced team communication and moving towards self directed work teams. The opposite of that is when you have a project manager that is the "messiah", so to speak, the all knowing, he's assigning everyone work or she's assigning everyone work and holding them accountable to complete that work. This approach just doesn't allow for the teams to really get involved and take ownership of that project. And I think when you're sharing information and communicating and working toward a self directed work team, with the project manager facilitating the distribution of information, the removal of barriers and obstacles, then the team starts to take ownership and I think you're going to have more success, more predictable success more consistently.


JJ Brantingham (14:31):

Yeah, exactly. And we have a whole session on self directed work teams, so keep an eye out for that. We'll talk you through the benefits and how to develop self directed work teams, and it really is part of the project retrospective process. (14:44): So how do you get started if this sounds good so far? Few basic steps. Obviously, you've got to figure out how you're going to schedule them and try to get something scheduled. If you drag your feet too long, obviously that won't happen. So what are you doing in these retrospectives? We'll dig into this a little bit more. So one of the top ones we have is update the scope definitions, because scope does change as projects are underway and execute, right?


Don Archibeque (15:15):

Yeah, routinely. I mean, every project starts out with a predefined scope of work, a predefined schedule, and you think that things are going to clip along just the way they've been planned. Well, I can count the times on one hand in a 30 year career where things have just gone off exactly as planned. The reality is is that a lot of things change, personnel changes, priorities within the firm can change, priorities with your key stakeholders for the customers. Project management team can change. So yeah, there are going to be unforeseeable changes in the project, absolutely.

(15:56):


Is that going to impact more than the discipline that's being communicated to by the client? Probably. Should you get that information out to the team as quickly as possible? Absolutely. So having an opportunity to discuss that really kind of sets the stage as you go forward. Hey, we've got a client that likes to change their mind, scope ebbs and flows with their mood, it seems like. And so you learn from the first retrospective that be on guard, all of you. Depending on who's talking to you and what conversation you're having, you may have some news to bring back to the team. It's a great opportunity to implement and reinforce standard work for change order process.


JJ Brantingham (16:36):

Yep. Yep. And we have, that's almost a double point, right? Update the definitions, and then the second point around scope alignment, just make sure everyone's aligned then with the current and correct understanding of scope. Right?


Don Archibeque (16:49):

Yeah. Certainly alignment is a big deal, and I'm going to kind of go down a bit of a rabbit hole here, so pull me out if I get too deep, JJ. You have to bid projects in every A and E firm to win them. And sometimes the difference between the person who is out there hunting for work and the people who are executing work, there is a misalignment. And as the project manager, you have to brainstorm along with your project team. How are we going to take this project that our business development and sales guys have won for us and execute within the constraints that they've had to put out there in order to win the work?

(17:33):

Sometimes that requires a redefinition of what the deliverable is, or maybe a primary definition of what the deliverable is. If you have an engineer trying to do the very best job developing a project that is the absolute gold standard, but that isn't what the client paid for, you have a misalignment of scope. And so making sure that you're keeping your finger on the pulse, and how do you do that? You start to see that people are spending a little bit more time early on on a particular deliverable than you had planned for them to spend or that you collectively had planned for them to spend. And that needs to be adjusted, just like in a marathon, as quickly as possible so it's as minor adjustment as possible.


JJ Brantingham (18:24):

Yep. Yep. And for an example there, we've got budget status, and if using our tools or whatever your tool that you are using, you know, you want to drill into that project, look under the current phase that you're reviewing, and take a quick glance at job to date plan versus job to date actual to uncover that. And then it's a quick conversation about well, what's your understanding of what you're doing? And I know exactly the people that Don's talking about, and some of the people that want to deliver a gold standard, but in the case of the customer, maybe went with more of the bronze deliverable because that's what they could afford. And that's what we have to match to.

(19:06):

So doing a quick review, and again, this just means opening that current phase. Go down the list, ask any questions as a PM, or let the team ask their own questions, and then go to the next phase, make adjustments. So you can quickly select a few weeks, take it from 40 hours to 30 hours or make that adjustment real time, so these meetings are productive in updating scope and status, right?

Don Archibeque (19:32):

Absolutely.


JJ Brantingham (19:35):

You will want to develop your own agenda, what you think is the most key things to discuss? We always like to ask the questions, what are the current challenges, but also what are the successes? Anything, hey, anyone have anything that they found is working really well on this project? So you can share those learnings and keep improving the team, and then issues that, you know, those they sort of go together, right?


Don Archibeque (20:03):

Yeah. I think a lot of people will think about successes in terms of who did an outstanding job with a particular deliverable. But if we drill down on that for just a minute, maybe someone has found a particularly responsive key stakeholder, that when you ask for information, they get it to you in a very, very timely fashion. That's a success. And you want to pass that on to your teammates so they have the same information, and as quickly as you might have procured it.


(20:34):

There are a number of successes that come along the way. Maybe something that would have to do with coordination meetings and utilizing maybe an internal resource to help schedule coordination meetings. That's a success, because maybe the rest of the team didn't know, oh, that's something that we have internally that we can take advantage. So success isn't defined as something just within the deliverable that you have. It could be a process success.


JJ Brantingham (21:05):

Yeah. Or just a tip. We could use tips in there, as well, just ideas that people discover that are, you know, things are going well for them, that turned into something that was helpful. So however you need to phrase that, to sort of tease those out, we encourage it because that's one of the best ways to improve teams is keep building on what's going well. Then obviously issues and challenges, just understand, hey I'm struggling with this, or could be uncovering a coordination challenge between disciplines. It could be those issues that we mentioned earlier, like a client not being responsive and needing to understand that. So quick conversations about those issues.

(21:49):


Scheduling the deliverable, right? Fundamental PM status. I think that last survey we saw something like 34% of AE firms had schedule challenges. So do a quick review. In our tool, you can bring up all your project schedules in a single screen. Look at those deliverables. They show up as the milestones, which also comes to the next part, is you're never doing one project or rarely doing one project. So deliverable coordination, review and ask your team if they see any challenges with deliverables on other projects, but also make sure they have an understanding of what's coming up and what needs to get out the door on your project, as well. But again, review it and ask questions.


Don Archibeque (22:34):

Absolutely. That's the main thing. Ask questions. Whether you're asking questions of the team or the team is asking questions among themselves, that is the key.


JJ Brantingham (22:45):

Yeah. And we touched on budget status. Last one, these are opportunities to praise and mentor, to enhance teams, build teams. That's one of the goals of retrospectives. So take the time to make sure you say thanks. Say congrats, good job. Share learnings, you know, on this project I did this to overcome that, right?


Don Archibeque (23:09):

Yes. You create an environment for success, and by creating that high level of communication and trust and formulating that self-directed work team, you'll find that you have success on projects more often than you can believe.


Summing it all Up

JJ Brantingham (23:26):

Yep. Last thing I didn't mention, we said these are 10 to 30 minute meetings. As you get started, you're going to overrun. It's going to take a little longer. Don't be discouraged. Your first meetings might turn into 45 minutes to an hour, especially as teams get used to sharing all their challenges and sharing all their thoughts. But you'll develop efficiency over time the more frequently you have these. Also, if you do have them more frequently, less will build up and you can get through them quicker and be more efficient at having the meetings, right?


Don Archibeque (24:02):

Absolutely.


JJ Brantingham (24:03):

Yeah. All right, well thanks for your time. Hopefully this was useful. If you want to find out more about us, you can go to planifi.net. You can reach Don at don@planifi.net or myself jj@planifi.net. If you have any questions or comments, want to find out more, or talk about retrospectives.


At Planifi, our goal is to make planning drop dead simple. So I encourage you to find out more on http://planifi.net Thanks, and have a great day.




bottom of page