If a tree falls in the woods...

I came across the Copenhagen Interpretation in a book I'm reading. This idea came about in quantum mechanics by Niels Bohr, Werner Heisenberg and others, working in Copenhagen in the early 20th century. In simple terms, the Copenhagen Interpretation says that something doesn't exist until we observe it. So if a tree falls in the woods and no one is there to hear it, it doesn't make a sound.

So what are we trying to observe on our projects? What do we try to capture by our reports, metrics, SLAs etc? The Copenhagen Interpretation supports the idea that we get what we are looking for.

I was doing work at a call center one time. There, they were looking at what percent of time the representatives were available to take calls and when they were "logged out" meaning they were taking a break, doing documentation from a previous call etc. This data point was pretty consistent across the representatives. However, when they dug a little deeper, they found a small set of people that answered significantly fewer calls. This didn't make sense since their availability was the same as others.

As it turns out, some representatives figured out how to scam the system. They watched the representatives around them getting calls and could predict when they would get a call. They logged out for a few seconds, the call went to the next representative over, and they logged back as available, knowing they wouldn't get another call sent to them for a while.

So you're going to get the behavior you look for and reward. If you reward the number of bugs the coders find, they'll find a lot of bugs. If you recognize the person that can fix the crisis, you'll get a lot of fires that need to be fought. So don't think lightly about what you measure.

Anti-Patterns in Project Management

I'm on a project now working with a client on best practices for BPM projects. My focus is on the project management aspect and I have a couple co-workers focused on the software development aspects. One of the topics that came up this week was anti-patterns.

Anti-patterns can be thought of as repeating a set of actions that are anything but a best practice, or, just repeating a bad habit. It's a pretty common theme in software development. Spaghetti code is a good example, continuing to produce code that is poorly structured, confusing, or hard to follow.

But as I was thinking about it, I realized anti-patterns can apply to project management as well. I was in one organization that practiced the "death march" anti-pattern. Projects would get going, everyone would know it was going to be a disaster except senior management, and then the meltdown would happen. Then everyone gets assigned to the next project.

Another of my favorites is management by fire fighting. It's only the fires that get attention and the fire fighter working the long hours saving the day is recognized as the hero. If the organization was a little better at addressing risk, it might have a few less fires (not to mention stop rewarding people for putting the fires out if they could have prevented them in the first place).

So what anti-patterns are in your organization? Can you do something to replace them with some best practices? Are you so caught up in the day to day execution of your projects that you don't see them?

The Five S's of Lean

One of the principles of Lean is known as the 5 S's. Developed in Japan, they are 5 steps that are taken to help become a more lean organization, all starting with the letter S. In English, they have been translated as Sorting, Setting in Order, Shining, Standardizing, and Sustaining. Though the concepts focus on manufacturing, they can also be applied to knowledge workers.

Sorting - What does your desk look like? Do you have piles of papers or magazines you hope to get to some day? Lots of extra cables hanging around? Business cards waiting to be put into your contact management system. The first step in becoming a lean knowledge worker is to sort your desk and office area. Keep only what you are going to need on a regular basis close by.

Setting in Order - Similar to sorting, but with more of a focus on your process flow. It's answering the question of where is the best way to arrange what I need on my desk? When I sort, my computer is something that is on my desk; when I set in order, I set up my laptop just to the left of center, with a second monitor in the center of my desk. I have a space to the right of my mousepad for documents I am working on. Setting in order becomes more important when I'm working on a client site. I have to set up every morning and need to adjust based on how much space I have. If I'm in a conference room with other people, my space may be very limited.

Shining - At the end of each day, taking a few moments to make sure your workspace is clean. Throw away that candy wrapper that's behind your monitor, sort any papers you are done with, and put books back on the shelf.

Standardize - It's important to set up standards with the people you are working with. Do you have an in-box you want anyone from your team to put papers into? Do you have a standard time for your daily stand-up meeting?
Sustain - Keeping the practice going and revisiting the other four S's when you need to. If you get a new, larger monitor, you will have to sort and straighten. If a new member joins the team, how does that change your standards within the group. Sustain is kind of like kaizen, you don't go through an improvement and stop; you keep looking for improvements.

How much technology do you need?

In an interesting twist, today's stage of the Tour de France was run without race radios (article). Normally the radios are used for the team directory to communicate to the riders; things like when the next climb is, potential hazards, or where a rival is in the race. It can become important if a small group of riders break away ahead of the pack; knowing if any of those riders can take over the lead of the race and therefore need to be chased down. So it provides additional information to the riders to help decide on tactics.

The question is how do the radios impact the race? Riders seem to prefer the radios, knowing exactly what's going on. The organizers that put the radio ban in place for today thought it might add some drama. Looking at today's results, I don't think it had a big impact either way.

This got me thinking about tools to help run projects. In the workshop I ran this past weekend, I took a very manual approach; using note cards etc. I mentioned some of the tools that are available, but also said I prefer the manual approach whenever possible. If you have a team co-located, you can get away with posting your user stories as note cards on the wall and writing your burn-down chart on a white board. Things get more complicated when teams are spread across multiple locations. That's when you need to start looking into tools.

So if you're spending a lot of time keeping your tools up to date, you have to think about what value it brings. If the answer is not much, then maybe you should try going without, like the riders did today in France.

The Road to Agility Workshop

Yesterday, with the help of Ron Montgomery, I co-ran a workshop on agile project management. This was a 1 day introduction to agile that was run in conjunction with the Kansas City PMI chapter. If you attended the class and are looking for the slides, click here.

The workshop went pretty well. It was tough getting everything that we wanted to cover included in a 1 day format. We received some feedback about running additional workshops that go into more detail on some topics.

What attendees seemed most interested in was how to sell agile in their organizations. What do you have to do to convince executives this is the way to go?

I think the highlight of the class was when we did a planning poker exercise. We had 50 attendees that we broke into 8 teams. Each team selected their PM and Product Owner. The remainder of the team were the "developers." After creating their user stories, each team went through the estimating process. There were some interesting discussions that followed as they tried to estimate the stories.

Proof of Concept

I have a project going on now that's a proof of concept; working with a client to demonstrate how my company's software can solve their business needs.

Obviously, there are some shortcuts that I can take on this project. For one, I don't have to worry as much about testing because the application is not going to go to production. However, in good agile technique, we are testing during each iteration. At the end, we want to demonstrate a system that works, even though we may not go through all the corner cases we might in a thorough testing approach.

We also don't have to worry about documentation. We'll show the end users how to use the tool, but we don't have to worry about future users. We also don't have to worry about support documentation.

We also didn't do as much up-front work. Typically, because it is a process improvement project, we'll look at the as-is process and figure out the ideal to-be process to implement, then start development based on improvements we've uncovered. In this case, we are just re-implementing the as-is process with the only improvements being what comes with our software; things like improved efficiency, better reporting, better tracking of resources and workloads among other things.

So a proof of concept should be just a first step. Assuming we are successful, we will be able to come in and really help our client. So while the demands on this project aren't as big as a full blown implementation, we still need to show business value. On any project, that's really what it comes down to.