Who Am I and What is The LeanWAM Principle?

 Looks like you've stumbled across my webpage.  I am not sure what you misspelled in your Google search to get here but I am glad you made it.

My name is Jason Todd and I created The LeanWAM Principle, a unique approach to work and asset management for smaller, lean organizations that lack the staffing levels necessary to support traditional work and asset management strategies but still need to realize value from their CMMS software.

I have many years of experience utilizing CMMS software from just about every user role you can imagine in industries like steel production, power generation, and municipal utilities.  I have been the journeyman maintenance person receiving their preventative and predictive maintenance work orders and having to write reactive or repair work orders to document maintenance against assets.  I have been the user designing new preventative maintenance programs or revising tasks and instructions on existing preventative maintenance programs in the software.  I have been in the role of maintenance supervisor using the CMMS software to plan and schedule work, manage the work backlog, perform QA/QC on completed work, running reports, reviewing key performance metrics, and pulling up repair history to support capital replacement justifications for assets.  I have been the project lead for implementing a new CMMS software deployment, designing a system from scratch.  And I currently administer the work and asset management efforts at a medium sized water district.  

So it is safe to say that I have intimate knowledge of what a work and asset management software needs to deliver to all levels of the organization from the field worker to the supervisor and up to the executive team who need to make data driven decisions regarding budget, investments, and how to staff and utilize labor resources.  I also know how many people it takes to do work and asset management "right."

The problem is, I have never been employed by an organization that is staffed properly to do this "right."  And as I looked around at similar agencies and industries I started to see a pattern.  There were organizations that were robust and had the budget and funds required to staff up and really do high level asset management, and then there were the rest of us wringing our hands with frustration because we could not apply industry best practice due to the lean nature of our organizations.

So I challenged myself with these questions.  If I cannot do it right, how can I do the best version of wrong?  Is there a way to design a strategy that can deliver value given the limitations that my lean organization imposes on me?  IS "close enough for government work" really close enough for government work?

Surprisingly, there were answers to these questions.  There most certainly was a way to deliver the most important aspects of work and asset management that, although not perfect, met the needs of my organization.  

I know that there are leaders out there that I respect completely, whose books I have read and whose videos I have watched and who I have applauded for after they have delivered their keynote speeches at large reliability conferences who, if they were to stumble upon my LeanWAM Principle might be appalled and dismiss the things I say as being totally and completely wrong.  And for an organization that isn't understaffed, this would be valid criticism.  But I did not set out to do it the right way.  The right way was impossible given the rules of the game I was being forced to play. 

So stick with me, we can all enjoy being wrong together.  You will see that with my version of being wrong, your work and asset management software will do more than you dreamed it could do with less staff than you thought possible and it might, just might, deliver the necessary value despite being understaffed. 

Ok, now back to your Google search and fix whatever typo you made that landed you here.  That Amazon wish list isn't going to populate itself.  

Comments

Popular posts from this blog

Wherever You Go, There You Are