Then your boss comes in and says that a critical customer will be coming in for a visit in two weeks, and he wants to be able to show a working demo of the portion of the product that you have been working on. He wants you to make this your highest priority. You tell him that you can do this, but that it will have to involve a number of other people working on other areas of the project, and will likely delay delivery of what will be needed for the real product, as you and others will have to take time away from doing that real work in order to get something temporary together for this demo. Your boss says that’s what he wants you to do, as this customer is very important. You do it, and the customer seems happy, although it appears to you that what you demonstrated was really of only mild interest to that customer, who appeared to have other, more important, things he really wanted to discuss with your boss. Your boss seems happy with your demo, but otherwise occupied with other issues related to this critical customer. In any event, you’ve done as you were asked and delivered a good working demo. Nice job, you think.
A month later, you (and the others who were involved) are now about two weeks behind in your project efforts, and your boss demands to know why and how this critical work got delayed. You remind him of the demo he asked you to prepare, but your boss says, “But that was only a quick demo! You never told me that it would delay the project [despite the fact that you did]. This delay is unacceptable and so is your performance! I want to know what you’re going to do to get the project back on track! You know that this project is your highest priority!” You have just become a victim of “Showing Progress vs. Making Progress Syndrome”. No good deed goes unpunished! [See The Schedule Estimate Extortion Game and No Good Deed Goes Unpunished!]
I’ve fallen prey to this syndrome myself, always to my regret. I’m always disappointed with myself that I’ve given in to pressure to have 'something' to show (for example at a 'critical trade show'), knowing that damage would be done to the actual development effort and that the delivery of shipping products would be delayed, but caving in to the pressure anyway. Like the common cold, no one is immune.
In general, bosses are afflicted with this syndrome far more often than their subordinates. They seem to feel the need to show off to their bosses or others, or to bow to pressure exerted by their higher ups. They want to impress others and nothing, in their view, impresses more than a good demonstration. What better way to 'show' the great progress the boss (and his team of course, he said laughingly) is making than with a showy demo. If it comes at a cost, so what! Delays are the fault of those doing the work, not of the boss (or so the boss may say).
Those doing the actual work are generally more interested in getting the job done than in putting together a big 'dog and pony show'. They know from painful experience that delays due to 'showing progress' will be held against them. They will be measured for 'making progress', and if their real progress doesn't 'measure up' to expectations (which of course never included any 'show demos'), their performance evaluation will suffer. Of course, if they refuse to put together these 'dog and pony shows', that will be held against them as well. They’re damned if they do, and damned if they don’t.
What is the right thing to do in such a situation?
If it is possible to show progress as a natural consequence of making progress, that’s a win-win situation. In this case, a natural point in the project effort has been reached where a demonstration can be given without any impact to the project schedule. In fact, if such points of progress can be identified, it would be a good idea to make this fact known to your boss or higher ups and encourage them to come and see a demonstration of what has been accomplished by the team. Such a demo can often be set aside so that it can be readily re-assembled for demonstration at short notice without significant project impact. As such natural 'show point' demos can be made available, the management team and the rest of the development team get a good picture of the project status, and can give kudos for making critical people aware of the real progress being made.
Problems arise when, in order to 'show progress', you must stop (or at least slow) 'making progress', and devote significant side efforts separate from the real project tasks. When this is the case, it is imperative to make the impact of 'showing progress' brutally clear. The likely delay to the overall project must be totally understood and accepted by all involved. Management must recognize that real revenue will be lost due to the delay that will be incurred to prepare for this 'showing progress' demo, or whatever it is (see Late Projects Kill Companies!). If at all possible, the revenue loss should be quantified so that its impact can be fully understood. If, after all of this, the need for 'showing progress' is still mandated, then you can move ahead with the understanding that management fully buys in to the impact (although they may still deny this after the fact). [See also Ineffective Engineering Costs You Time, Money, and Customers! and When Bad Things Happen to Good Projects.]
Completing complex projects in a timely fashion is difficult under the best of circumstances and when all goes well. Artificial complications that are a result of 'Showing Progress vs. Making Progress Syndrome' greatly complicate the process further and often derail it. If at all possible, strive to 'make progress' without artificial detours to 'show progress'.
Copyright 2011 Workplace Insanity, All Rights Reserved