I have since worked for/with many project sponsors (many times at the COO level) and the common thread between them all has been speed. I.e. they did not care how, just get it done. (I don’t think I’ve ever had a project sponsor get into the weeds of the PM software or RAID log I was using at the time.) That’s when I glommed on to Lean.

Here was a methodology focused on exactly what project sponsors actually care about – speed and value delivery. But what excites me most is that lean isn’t just a methodology – it’s a mindset that empowers teams to question everything that doesn’t directly contribute to project success. No unnecessary meetings, no bloated documentation, just an obsessive focus on delivering what matters faster.

By applying lean principles (including for a recent start-ups, which love to move fast), this usually means:

• Mapping out the entire project plan/process in detail, which eliminates meetings and documentation that don’t directly support delivery.
• Break the project into sprints focused solely on must-have requirements.
• Establishing regular stand-ups to identify and remove blockers (only).
• Creating something visual like Kanban boards to show work progress (and eliminate status reporting overhead.)

Lean isn’t just about efficiency – it fundamentally changes how teams approach project delivery by keeping them laser-focused on what matters most.

Take risk management – instead of maintaining elaborate risk registers that no one reads, you can integrate risk discussions into stand-ups and planning sessions. Not only do you eliminate separate risk review meetings, but it’s a more active and engaging way to manage risks.

I’ve learned to be pragmatic. The key is to identify the real purpose behind what you want to do, gauge if it adds value and then make it as lean as possible while still serving its core purpose.

In my experience, most stakeholders will embrace a lean approach once they see faster delivery without losing control.

Another common myth is that lean only works for manufacturing or software projects. I’ve successfully applied lean principles across industries, from financial services operations to pharmaceutical marketing transformations. The core principles of eliminating waste and focusing on customer value are universal.

People also often think lean means no documentation or governance. In reality, lean promotes “just enough” documentation – what’s actually needed to deliver value and maintain control, nothing more. It’s about being smart and deliberate about what we document and why.

Finally, there’s a misconception that lean is just another rigid methodology to follow. It’s a mindset focused on continuous improvement and adaptation. Always be asking “Does this add value?”

But, instead of a wholesale change, I think a grass-roots approach is the best way to approach this. I.e. let/have the people doing the work play with AI and figure out how to best use it.

For example, I am in the process of creating my own custom GPT seeded with all my previous project plans and RAID logs. The idea is that I can get a version 1 of both, project plan and RAID log, spun up on day 1 of a project (saving me a ton of time up front and giving me a great jump-off point for ensuing discussions).