The Hardest Lesson to Learn?

Posted by: Timm J. Esque | Posted on: January 4th, 2012 | 1 Comments

This is obviously a judgement call and you may have your own opinion of the hardest lesson to learn.  I encourage you to make a Comment and share your own view.  Based on over 25 years of observing, helping and participating with project and process teams, I believe the hardest lesson is – slow down in order to go fast.  The purpose of slowing down of course is to do things right the first time.  Most of the time lost in execution is lost re-doing things that were not done properly the first time.

We’ve all experienced making time consuming errors when we rush to complete even minor tasks.  The risk and the impact go up exponentially when we’re talking about a team of people working interdependently with each other to get things done.  On waterfall projects, this often means having to rework large parts of the ultimate project deliverable.  On agile projects you find out much faster if you are making errors or heading down the wrong track.  But in the rush to get started “doing productive work”, even agile teams can have costly mis-starts.  Agile software teams often don’t take the time to get clear about how their outputs will integrate with the larger intended outcome.

This is not a new observation and experts are pointing it out all the time.  In an Forbes article from earlier this year, McGuire and Tang from the Center for Creative Leadership point out how speed is entangled with complexity and uncertainty.  In a complex and uncertain environment, speed requires clarity and clarity requires some time spent up front having appropriate conversations.  A new book I will be writing more about is called Strategic Speed: Mobilize People, Accelerate Execution.  Based on a combination of studies and cases, the authors say that the key to speed of execution comes down to clarity, unity and agility (view author interview).  Clarity and unity especially require time in the planning stage to make sure people are pulling in the same direction and that it is clear why it is worthwhile to do so.

Because this problem is systemic, it can be difficult to know where to start to address it.  In our experience the problem starts with the top down deadline that is often given to project teams before they even begin planning.  The first step to slowing down to go fast is for the sponsor’s of projects to replace the top down deadline with a request.  The request is for the team leadership to get with their team and define what it will take to achieve the project goals.  Generally, there is too much uncertainty for the team to know exactly how long it will take.  They need to set and monitor short term deliverable goals and report on their ability to meet these “horizon” plans.  Over time it will become apparent if the team is likely to achieve the necessary time goals.  But either way, teams given the chance to have input into the plan and to operate from their own goals, will achieve those goals without shortcuts that lead to costly delays later in the project.