The Art of Simple in Project Management

Project management is simple. That doesn’t imply it is easy to do nor does it minimize the value it brings. Keeping project management simple is what brings the most value to any organization. When a project requires complex project management processes to keep it on track it may be too large. The project management processes should remain simple and projects should be framed to be managed as simply as possible. Organizations are filled with processes that have been built to take into account everything that can go wrong with a project. The processes are built for the exception rather than for the average or norm. Building processes based on what could be called the “happy path” will maintain simplicity. Teaching project managers a standard way to handle exceptions is far more valuable than building a process to handle all the possible exceptions that can occur.

The driver behind all the reams of paper, checklists, processes and complexity is fear. Fear is understandable in the world of project management. More projects fail than succeed so why wouldn’t you ensure you have all the “I”’s dotted and “T”’s crossed? The only thing that all the “I” dotting and “T” crossing requires is time, so why not spend the time? The problem is that time costs companies a large amount of money. The litmus test for creating documentation of any kind is whether or not it will be used for any reason (formally or informally), and whether it adds value to the organization. It is true that we don’t always know ahead of time what information will be needed a few days, weeks, months or years down the road. Is the possibility that information may be needed any reason to create documentation that may never be viewed again? Are we creating all of this paper to prove that we are doing our job or because the project will be more successful because the paper exists?

Traditional project management for software development has always struggled to prove that work is getting done and value is being created throughout the project life cycle. Questions such as “What do you have to show for all these weeks of work?”, “When will I see something concrete?”, and “How much more time and money is it going to cost before I get some results?” from clients are valid. Project managers must challenge themselves to see project management from the client perspective. Project management must be kept simple. Having project management activities appear complex does not create respect nor does it increase the value. Project management is respected when it can make project delivery easier for teams and organizations and that is only possible when it is simple.

The primary driver in keeping project management simple is trust. Developing the level of trust necessary requires rampant communication. Creating rampant communication is possible when project managers embrace the value from the Agile Manifesto, “Individuals and interactions over processes and tools”. This value is for all types of project delivery and should not be relegated to agile delivery. Project management communication must be transparent. It must provide a window into the true performance of the project. The project manager must be fully accountable for all aspects of delivery, not sort of accountable. The good, the bad, and the ugly must be visible to the entire team, from the sponsor to the client, from the analyst to the tester, from business to IT. The simplicity of project management is found when the degree of project team work is in direct proportion to the business benefit the project provides.

Ride On, Manage On.

Read more...

Project Management: Measures of Success

When I was taking my first Motorcycle Safety Foundation course, I defined success as passing the tests. That meant that I had to be able to control the motorcycle enough to get it through the course without too many errors. I’ve taken the same course two more times and each time my measure of success changed. I still wanted to pass the test. However, I wanted to pass the test confidently. I could measure the time, points, and missteps because they were objective, visible and very measurable. How do you measure confidence? I couldn’t tell you what the exact success measure was, but I knew when I reached the level of confidence for which I was looking.

Measuring the success or failure of a project can be a bit like measuring confidence. It is possible to identify when you’ve met your scope, time, budget and quality measures. The data for those measures are relatively easy to capture. The more difficult aspect of gathering the measures of success is gaining agreement on what the tolerance is associated with those measures. The exercise for determining tolerance may seem a bit like defining when confidence is achieved. How far off can the scope, time, budget and quality be on a project for it to still be successful? Is it truly 100% or nothing? That narrow a project is filled with risk, we must provide a tolerance for less than 100%, or we warp our behaviors. Perfection is always a goal, never an outcome.

Successful project delivery is determined based on the successful delivery of the business benefits. We must look past the simple delivery of a product or service. We must measure our success based on what the product or service we are creating will provide. If we stop short of the benefit, we have missed the reason for doing the project in the first place and the consequence can be project failure.

“The bike will go where you look” is a motorcycling lesson that is critical to remember to be a successful rider. I was riding, it was a beautiful day for a ride, and I went into a turn a little fast. I was concerned because I couldn’t see around the bend very well, and I was approaching the center line. The harder I tried to stay away from the center line, the closer I got. I was staring right at it when I remembered “the bike will go where you look”. I lifted my head, looked through the turn and successfully navigated the turn without touching the center line.

This same lesson is true in project management. The project will go where the project manager is looking. When we focus on where we are going, it causes the success measures to fall into place. The tolerances for budget, time, scope and quality become clear. We are able to lead the project successfully because we are clear about where we are heading and why we are heading there. We can communicate with the project team based on business value rather than project deadlines, the business benefits rather than 0 tolerance and project success based on reality rather than perfection.

Ride on, Manage On.

Read more...

Project Management: Take Control?

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

Read more...