Why We Should Focus On The Not So Obvious
Standing on stage, [new Alcoa CEO Paul] O’Neill did not speak about increasing market share or earnings forecasts. Instead, he pointed out the nearest emergency exits. “In the unlikely event of a fire or other emergency,” he said, “you should calmly walk out, go down the stairs to the lobby, and leave the building.” O’Neill’s sole focus that day was on how to make a habit of worker safety.
To understand why injuries happened, executives had to become intimately involved with work process and manufacturing techniques, which led to conversations with frontline employees about their ideas, which led to streamlining operations, which led to lower costs.
O’Neill soon emerged as one of the best CEOs in modern business history, thanks to his unusual emphasis on safety. By attuning employees to proper procedure, O’Neill streamlined production. “Costs came down, quality went up, and productivity skyrocketed.” Bloomberg Businessweek, Bound by Habit, March 19-25, 2012.
Often getting one thing right, which ultimately requires tweaking the other things that touch on it, can help get everything right.
I like this example from Alcoa because it focused on safety — not production, costs and profits — and yet made a huge difference in all those things.
Another fundamental we often forget is that if we focus on quality then not only does quality improve but so does productivity, cost, etc. (See focusing on quality gives us productivity at no extra cost.)
It is often too easy to focus on the obvious stuff and not on what it is we really need to be doing.
Are you focusing on the key processes and goals that will truly make a difference in your project?
One thought on “Why We Should Focus On The Not So Obvious”
Comments are closed.
Comments from around the web:
Dan Kempf • At its basic level, all project managers should be doing lessons learned. In medium to large corporations the loading of lessons learned into a data base is desirable. But, unless institutionalized into the processes, it sits with hundreds of others. People move on. Different people run new projects with little stability. Best effort is to have at least seasoned people who can apply at some level. In general though, risk assessments will reduce impact and issues resulting in lessons learned.
Bruce Benson • I love digging into the history of past projects to build my current project, but I’ve rarely found where a formal “lessons learned” step ever produced something truly useful (in my case, just once and it was a great experience dump that I literally could use as a template for my project at that time.).
What I’ve seen that worked well, for me, was to mine the data produced by past projects. Yes, I still read through the lessons learned slides, if they exist. However I find that digging into the requirements database (how many requirements when they started, how many were added and at what rate over the course of the project, how long to implement each one, etc.) and the schedule archives (what did the schedule look like at the beginning, how often did it change, what did it look like when they finished), status updates (meeting minutes, slides, dashboards etc.), defect database (total, rate of arrival, rate of repair, etc.), etc.
Once I find these for hopefully several past projects, I can characterize how projects generally progress in this environment. It is always interesting to see the often pronounced difference between the original delivery date and the final one and see from the data evidence of where things were off.
Bottom line is that I’d rather use naturally occurring data generated by the project then rely primarily on a lessons learned document. We are doing the same thing, learning from our predecessors, but here we are using what is usually better information (and sometimes embarrassing/incriminating – things that are rarely mentioned but useful to know) and we don’t have to rely on our predecessors to have remembered it all in a document or database.
Good topic.