What 11′ 8″ Can Teach Us About Project Management

maxresdefault1There’s a low bridge in Pennsylvania.  How low you ask?  11′ 8″.  Why is it so low? Because it was built for a train in an era before automobiles were as popular as they are today and before trucks were as tall as they are today.

The railroad company is happy with the bridge, but wanted to protect it from a tall vehicle, so they put up a steel barrier of the same height just feet before the bridge to protect it.

From the railroad’s perspective the problem is solved.

The city didn’t want vehicles hitting the bridge either, so rather than pay for an expensive rebuild they put up signs warning drivers about the height and attempting to direct them to a different route they had invested a lot of money into building where it would be safe to cross.  The city also knows that each person on the road had to pass a drivers test that primarily consisted of knowing how to read and follow signs.

The number of incidents in the video would suggest that people aren’t following the signs the way the city intended.  While this could lead us to start a commentary about drivers, I believe there’s lessons to be learned here about project management.

What does this tell us about project management?

We need to remember the bridge project was successful from both the railroad and city’s perspective.

In both cases the project managers and organizations were insulated from the environment.  Government, and government backed railroads are rarely incentivized to apply the Toyota Principle of Genchi Genbutsu.  One great example of Genchi Genbutsu was when the project manager for the Toyota Sienna decided to take a road trip in the United States.  He didn’t just drive across the country, he drove that model year in all 50 states and noticed just how big the United States was.  He realized that Americans weren’t just using vehicles for the shorter trips common among Japanese drivers, but long, multi-day trips with families and gear packed in the vehicle.  When he was done with the journey he increased the number of cup holders (Americans are also more likely to eat in their vehicles) as well as improved luggage space.

11-foot-8-bridge.jpgFor the case of 11′ 8″ the railroad company didn’t adopt the culture of Go and See beyond the intent to protect their asset.  I imagine that the city’s version of seeing what happened was less about watching it on youtube, and more about seeing the amount of traffic violations issued by the police officers for infractions.  In every case, it’s the fault of the driver, not the fault of the city for not having improved the road.  In general city officials are heavily insulated from their consequences elsewise how could a firefighter in California work more hours than physically exist in a year?

Applying Genchi Genbutsu is best applied with a cultural perspective shared by the organization’s leadership.  That leadership should foster systems that encourage a go and see attitude, but even when leadership isn’t 100% on board a project manager should be routinely going and seeing as much of the project work as possible.  It’s when you see the work and working environment that you can notice positive risks.  Small opportunities to improve add up a lot over the course of the project, and I know people who work harder for empathetic leaders than any other type.

So what can we learn from this?

Americans tend to have trouble trusting road signs.  This comes from years of speed limit signs being based upon arbitrary laws and not actual road designs, constructions signs left up months after construction is finished (sometimes just so fines can increase for law enforcement), and I also believe the font might have something to do with it.

Leadership in a project isn’t putting up a sign and expecting people to follow it.  It’s going and seeing the challenges that people are faced with (like where’s the road I’m supposed to take if it’s not this one) and help them overcome those challenges.  Leadership is about removing obstacles.  The best way to find obstacles isn’t on a report.  It’s from going and seeing for yourself.

A Brief Comparison Between Lessons Learned and Retrospectives

A Brief Comparison Between Lessons Learned and Retrospectives

Project lessons learned and project retrospectives produce different products but both try to accomplish similar goals.  According to Jennifer Whitt, director of projectmanager.com, lessons learned segments of information discovered as events affect a project’s cost, time, scope, process, or morale (Whitt, 2013).  While Jeffrey Pinto presents four principles to reviewing a project namely, objectivity, internal consistency, replicability, and fairness (Pinto, 2016).  Brand’s article in the Journal of Environmental Health is a good example of the outcome from a review focussed on lessons learned.  It creates an article that covers the major components of the project and provides a tabulated list of challenges with solutions (Brand, 2016).  A review process that focuses on a lessons learned deliverable can easily result in a critique or finger pointing.  If a review process devolves into this behavior it will discourage honest feedback among stakeholders and participants in capturing and sharing information to help the organization improve.

Retrospectives are similar in that they document the results of a review process but differ in the tone, breadth and depth of the deliverable.  Because of this they take a different tone when capturing information in the review process.  A retrospective may contain lists of challenges and solutions, but the overall tone of the document is more similar to an essay than a flow chart (Kenny, 2014).  The questions outlined in one example of preparing for a retrospective focus much more on discussions about process efficiency and less about the personnel that may have directly contributed to the outcome (.  Focusing on decisions rather than the decision makers is an important key.

Unfortunately I have a great deal of experience participating in review processes from working with the Army, but no experience with creating retrospectives.  The United States Army’s After Action Review (AAR) process is designed to create a lessons learned document.  Each item discussed results in either a sustain, or improve rating.  They are not widely published.  Although there may be ten units across the Army with the same equipment and mission set there are few products that float between them to increase organizational efficiency.  The biggest lesson from this assignment isn’t in how to capture the data, but rather in being shown there are  options to the types of products used to package all of the data from the review process.

 

References:

Brand, J. E. (2016). Rewards and Lessons Learned From Implementation of a Healthy Homes Research Project in a Midwestern Public Health Department. Journal Of Environmental Health, 79(1), 20-23.

Hoberecht, B. (n.d.). Project Retrospectives. Retrieved July 31, 2016, from http://www.pinnacleprojects.com/index.php/project-retrospectives/157-article-retrospectives-3-foundations-for-the-perfect-retrospective

Kenny, K. (2014, November 3). A Look at Our Retrospective Process. Retrieved July 31, 2016, from https://www.viget.com/articles/a-look-at-our-retrospective-process

Pinto, J. K. (2016).  Project Management: Achieving Competitive Advantage, (4th ed.). Boston, MA:  Pearson Education, Inc.

Whitt, J. (2013, September 30). How to Capture Lessons Learned at the End of a Project. Retrieved July 31, 2016, from https://www.youtube.com/watch?v=DBUqW_ek4hI