In trying to get a handle on improving product performance, we discovered that simple examples were more effective as project management tools than were complex charts and spreadsheets.

We had a huge effort to figure out what our product’s performance should be. We had to query all our customers. It turned out that most of them didn’t have set requirements but instead “know it when we see it.” Others had interesting numbers we had never seen before and didn’t match anything we could relate to. They were then happy we were “going to meet it in the next product, because you asked us about it!” We had to query all our internal organizations and ask them what standards they were using. This was so we, as good project managers, knew everything that was going on and could possibly help ensure that all our products met those standards.

I recall staring at a large spreadsheet with hundreds of lines of “performance standards” most of which no one could figure out what they really meant to our project. Different tabs were for different customers who used difference terminology and measured things from different starting and ending places on the product or in the environment the product was used in. Our engineering organization often either didn’t understand what the customer was measuring or said that we couldn’t do in the lab what the customer could do in their environment without completely duplicating the customer’s environment.

As challenging as this was, it even got worse. It seems a marketing person or designer or beta tester would complain that something was not fast enough or had too many clicks to access the functionality or some similar issue. Engineering would then point at the “performance standards” spreadsheets and say “no one ever asked about that, and it would take months to work it out.” It actually seemed as if the “performance standards spreadsheet” made things worse, reduced communications and understanding, rather than better.

So how did this performance improvement initiative come about? It seems that on a few projects, the customer complained that some part of the product didn’t perform as expected. So our solution was to enumerate every possible “expectation” in advance and to try and engineer to that on every product. Isn’t that just he most obvious thing to do? Should be easy. Just the perfect task for the project manager.

While we continued to strive on every product to use the standards spreadsheet, it eventually evolved to a point where the performance spreadsheet just became another quality checklist item (“we’ve asked everyone to update it and they said it was fine — check.”). What really made a huge difference was something that now sounds very simple and intuitive. Let’s call it “performance by example.”

It worked like this: someone would either enter a defect or give me a call and say “this function is not fast enough on the new product!” Great, I would say, “How fast is it on our current product?” Silence. Then “I don’t know, I’ll go check.” From this point on we now had a benchmark to compare it too. I would still often get “it should be faster” but if it performed at least as well as our current product, I noticed that a lot of the energy went out of the complaint.

One engineering team came to me and told me that they needed to remove some functionality from a new product, because it was not going to perform well. It was ported from a more powerful product and they were concerned it was not doing as well on our mid tier product. I pulled together some folks and we compared it to our current shipping products where the functionality was similar and to competitor products where they already had the added functionality. We ended up tuning the performance on the new functionality and it went out working very well in the new product.

In retrospect this approach seems incredibly intuitive and obvious to do. Yet, we still went down the path of trying to “know everything in advance” to the point of forgetting to do something simple such as comparing what we were doing to an example of what was done already or elsewhere (see the series on project planning). When we set the standard of “it should perform at least as well and ideally better than our previous products” we empowered everyone in a worldwide corporation to make informed judgements on all aspects of the product (see more on business rules in planning). Having an effective list of performance standards is still a great idea (especially to make sure we didn’t overlook anything) but not in the place of something more straight forward and intuitively obvious.

Sometimes, even with all our advanced methodologies, tools and detailed planning, a good approach is to manage by example. The example serves as a reference point to at least provide an initial answer to many of the questions anyone might have about how things should work or how things should be done. The project manager should help select the good examples to be used but should emphasize that remaining doubts or concerns should always be brought to the project manager’s attention. Management by example is another project management tool that has worked well for me throughout my career.

Do you have any similar management by example approaches?