The story.
Your immediate superior requires that you, say, produce some given document to track the status of your project. Say, Gantt and Pert charts. You assume this is to help manage resources allocated to projects and to allow sales and marketing to know what they can say to customers. Your boss in fact tells you this. You spend much time, consequently, arguing with your peer managers to sort out the charts to satisfication.
Meanwhile, your developers either twist in the wind--thus producing no business value--or continue working blissfully oblivious to the so called project schedule--and thus ignoring business priorities, and wasting business value again. Either track is hopeless.
Occasionally you show the updated Gantt and Pert charts to the developers and the developers update you with their status. You attempt to balance each developer to 100% and update the project status as 87% done (as if solving the next problem only requires another 17.3 hours, which is 2.3 developers!) for your next report to upper management.
The reality.
While you've taken the word of your boss, and your boss is awfully proud of the detail in the tracking data thus demonstrating the tight reins on process the department have, however bogus in truth, the reality is that sales don't care about the status of "bug #12345678", but only what major features (like "now on Windows 2000!") they can pitch for the next cycle. Consequently, they ignore the chart as being "too detailed to be understood." Upper management also don't care too much provided the sales targets are met.
Thus, the entire effort was a waste of time. What would take only a conversation with sales and upper management to determine what they thought about the data you had supplied them--that is, if you considered them to be the customer for the documentation, and treated them accordingly--would drastically reduce overhead and potentially improve reporting to respond to the actual needs of upper management and sales.
Conclusion.
It's a form of CargoCult to assume that by producing some meaningless data you are creating information in order to report to upper management. If the manager spends all his or her time doing this to the detriment of the underlying team's actual management needs (and after all, the team is the primary customer for the manager's time), this is ManagingUpward and it is an AntiPattern in the strictest sense--that is, you actually think you're doing good but instead you are doing bad.
If you're told you need to produce some time consuming report, take the time to understand what's really needed and work accordingly. Ask clarification directly from upper management and sales; don't just let your immediate superior filter it for you because the document is not his responsibility. There's nothing wrong with finding out what your customer wants from you. That's your responsibility.
I was inspired by reading the CapabilityImMaturityModel. Good managers are actually interested in managing optimally, which means finding out what's needed of them. I've met too many middle managers who are too afraid they are going to get fired that they lack a spine. Consequently, since middle managers are always laid off (as reengineering teaches), they get what they deserve. But if they just did a really good management job, they would likely be seen as creating value instead of just managing value. Indeed, merely managing value is the definition of middle management (no profit and loss responsibilities), so obviously they have less job security than actual developers. -- SunirShah