Part 2: Who Defines Value in a Project?

There’s a consistent blind spot in technically driven projects. Engineers, designers, and project teams often assume they understand value because they understand the system. They don’t. At least, not completely.

In Lean thinking, value has a very specific meaning. It is defined strictly from the customer’s perspective, based on what solves their problem at the right time and cost (Womack & Jones, 2003). That sounds obvious, but in practice, it’s one of the hardest shifts to make.

Because internally, value often gets confused with:

• Technical excellence

• Complexity

• Over-specification

• “Best practice” applied without context

  
  

You see this when designs become more detailed than necessary, or when systems are specified beyond what the client actually needs. The assumption is that more sophistication equals more value. In reality, it often introduces cost, complexity, and maintenance challenges without improving the outcome.

There’s a good example in the material you worked through. Companies can become so focused on technical refinement that they lose sight of what customers actually want. When that happens, teams start justifying decisions by saying, “the client will understand later.” That’s usually a sign value has already been misaligned.

Value is not what the project team finds impressive. It’s what the end user finds useful.

From a BIM perspective, this is critical. A highly detailed model is not valuable if it doesn’t support decision-making, construction, or operations. A perfectly coordinated design still fails if it creates inefficiencies on site. The model is only valuable if it serves the lifecycle of the asset.

This is where ISO thinking helps again. Quality management systems are built around meeting requirements, but they also require continuous feedback and improvement. That only works if the requirements themselves reflect real value, not assumptions.

So, defining value becomes less about technical specification and more about asking better questions:

• What problem is this solving?

• Who experiences the result?

• What does success look like in operation, not just delivery?

  
  

Most projects don’t fail because teams don’t work hard. They fail because they optimise for the wrong definition of value.

Case Study: Over-Engineered HVAC System

A commercial development specified a high-performance HVAC system. Technically strong. Energy efficient. Aligned with best practice.

In operation, the client struggled.

The system required specialised maintenance, higher running costs, and frequent adjustments. The facilities team couldn’t manage it easily.

From a design perspective, it delivered. From a user perspective, it created friction.

The team defined value as performance. The client defined value as reliability and simplicity.

That misalignment is where value was lost.

Conclusion

Value is one of those words that gets used constantly in projects, but rarely challenged. Everyone assumes they’re delivering it, yet when you step back, it’s often defined internally rather than experienced externally.

That’s where things start to drift.

The examples show that value is not lost because teams lack capability. It’s lost because teams optimise for the wrong things. Performance over usability. Complexity over practicality. Specification over real need.

The HVAC case makes it clear. A technically strong solution can still fail if it creates friction for the people who have to live with it. The issue wasn’t design quality. It was alignment.

That’s the shift. Value is not what the system is capable of doing. It’s what it consistently enables in the real world.

From a project and ISO perspective, this changes how decisions are made. Requirements can’t just be captured and frozen. They need to be tested against reality. Feedback needs to be continuous, not procedural. And most importantly, the definition of value needs to come from the people who experience the outcome, not just the people delivering it.

If that doesn’t happen, projects will keep delivering technically correct solutions that miss the point.

Getting value right is less about doing more. It’s about understanding better.

References

Womack, J. P., & Jones, D. T. (2003). Lean thinking: Banish waste and create wealth in your corporation. Free Press.

Liker, J. K. (2004). The Toyota way: 14 management principles from the world’s greatest manufacturer. McGraw-Hill.

Laufer, A. (2012). Mastering the leadership role in project management: Practices that deliver remarkable results. FT Press.

University of Wisconsin-Madison. (n.d.). Technical project management course material