Is "Use BIM" a Project Objective?

Labyrinth by José Manuel from The Noun Project
I was recently on the jury for the Ballard Howell Lichtig Collaborators of the Year (COTY) Awards. One of the submission requirements was an outline of project objectives. There were a variety of responses, including but of course not limited to:
  • Establish and commit to a budget, schedule, and quality goals early on as a team
  • Drive Operational Efficiency through Lean principles in design
  • Use IPD and LEAN to deliver purposeful design, high value, and less waste
  • The new environment should [among other things] demonstrate stewardship of resources
This excerpt provoked a few questions for me, the most prominent being:
Should project objectives define the end results or the path to get there?
Projects objectives generally cluster into categories. The categories that apply to building projects (and likely other types of projects) are: Cost, Schedule, Performance, Regulatory, and EHS. However, in Tocci's Project Execution Planning sessions, we often talk about specific BIM Uses, Quality Control processes, and desired behaviors when we discuss Project Objectives. Although I'm sometimes the facilitator driving the discussion, I can still identify a few reasons why process doesn't fit in objectives.
  • It can unnecessarily constrain the team and put emphasis on the wrong outcomes.
  • Process objectives are often hard to measure. How do you know if the team achieved "use BIM"?
  • Teams are actually often willing to compromise on process, especially when held up against objectives such as cost or schedule.
At the same time, I see the place for process in objectives:
  • Since we are often willing to compromise on process, identifying it as an objective places it front and center.
  • Without identifying process objectives, we can get stuck in a rut - even if its a rut using an innovative technology, such as BIM.
So what to do?

Given the level of project delivery transformation and variation across the industry, I do think it is important to identify desired processes and behaviors. Several of the teams that submitted for the COTY award did exactly that - referring to those guiding principles as their "True North" or "Covenant".

However, it isn't enough to write these principles down or even enough to post them around colocation or project trailer - although you should probably do both of those things. You also should think about:
  • Checking: If nothing else, issue periodic surveys to a broad number of team members, asking them to rate the overall team's adherence to the desired processes and behaviors. Aggregate the data, post the results, and see how you're doing.
  • Adjusting: If the team isn't adhering to the desired processes or behaviors, do some adjusting. But first, think about where the team is "off course". Is it because they don't want to follow the process or that the original process is no longer a fit? You may not need to adjust the team's processes; you may need to amend your original plan.
What do you think? Is their a place for process in project objectives? Why or why not? Leave your thoughts in the comments or tweet them to me!

You might also like to read:
3 (Slightly Different) Ways to Define Smart
Motivation and Integrated Project Delivery

Like what you read here? Don't want to miss my next post?


No comments: