I was riding to work on my motorcycle, and it had just started to drizzle when I felt my wheels lose traction. It was such a subtle feeling, the sense of no control. After what seemed like an eternity, the wheels grabbed the road, and I continued my journey. In that moment, actually more like seconds, I chose to do nothing and to let the bike “fix itself”. That is an unusual reaction for someone who takes control of situations that seem to be going differently than planned. I enjoy feeling like I am in control. The problem is that I can sometimes believe that I am in control. I’ve learned that the only control I have is in how I react to information.
One of the biggest problems we face in project management is control. Project Management literature is filled with lessons in how to control projects. We have metrics that tells us how we are doing in meeting our cost, budget and quality measures. We have books discussing project control, tools for controlling projects and systems designed to control projects. All of these are designed to keep a project “on track”, like guard rails designed to keep vehicles on the road. You can imagine what a car looks like after playing bumper cars with a guard rail and projects look the same way when they play “bumper cars” with the project controls designed to keep them on track.
Must projects be controlled to deliver business value or is it that business value must control project delivery? What should be the driver for project delivery? On time, on budget with an appropriate level of quality is still the rallying cry. The underlying assumption is that the business value is based on project delivery that is on time, within the scope, on quality and on budget. When we set projects up correctly, focused on the benefits, we establish guard rails that are based on the business value. If the cost benefit is tight, the controls are tight and there is a higher likelihood of project failure.
Projects must have controls to establish predictability. W practicing A L or Classic project management predictability is needed to ensure delivery. The issue is that we establish controls that are too narrow and cause more damage to projects than they add value. When I ride, I’m focused on what lies ahead, I don’t stare at the guard rail concerned about hitting it. The guard rail is in place in case I lose control, it does not to help me maintain control.
We must focus on why the project is being done, on the value it is creating rather than on what the project delivers. When we do this the project keeps forward progress, and we are less likely to respond to input that makes us sense the project is “losing traction”. Paying too much attention to the guard rails makes them more important than where the project is headed, the business value. Trying to correct small anomalies is like braking when a bike loses traction for a moment, it causes more damage rather than letting the project “fix itself”. Too much control can damage a project. What is needed is business value focused control.
Ride On, Manage On
2 weeks ago
0 comments:
Post a Comment