There's been a rash of conjectures about all kinds of bad project management ideas things of late. Time to update the Don't Do Stupid Things on Purpose (DDSTOP) post.
I worked a program that had a simple goal - remove all the nuclear waste from a weapons production plant and send it to secure storage, cleanup up all the normal hazards and send them to their assigned disposal sites, uninstall all the infrastructure (heating ventilating, communications and security) while 5,000 people were still working there and not kill anyone along the way. The infrastructure remove program meant installing a complete wireless umbrella across several 100 square miles of property with full encrypted security while maintaining voice, data, first responder, physical, and cyber control.
There was in Incident in which a fire started in an elevator shaft several stories below ground when foam filler was used without reading the directions on its applicable. The result was a safety standown for everyone, including all us office workers, to get the message about health, safety, and safeguards of the materials and processes on site.
There was a banner campaign to get the message across. In our building a banner 15 feet high and probably 40 fee long hung in the lobby hi-bay
DON'T DO STUPID THINGS ON PURPOSE (DDSTOP)
I'm reminded of that when I hear suggested processes - in less threatening environments - like:
- Let's spend more on estimating than on the effort to produce the product.
- Let's use under sampled, non-statistically adjusted past performance for future performance and ignore that the past may or may not be like the future.
- When I say NO I really mean YES or Not Really, or Not everywhere.
- I wasn't paying attention in the Statistics, Microeconomics, or Business Management class, but listen to me anyway because I've got a lot to say about those topics.
- I know I get a divide by zero error when calculating ROI, but hey who cares, it's just someone else's money they won't really care
- Let's rename standard mathematica terms to fit our oxymoronic concepts of how to avoid telling those paying our salaries how much this will cost in the future.
- We accepted a cost estimate from our bosses that was lower by 10x to 100x from the actual cost
- We started developing software without really understanding what done looks like.
- We accepted this project for the price the customer wanted to pay and we'll discover the requirements as we go along.
- We think we can make decision about how to spend other peoples money with having to estimate how much money, time, or the probability that we will successfully deliver what we promised for that money.
- We're working on things the customer doesn't want.
- The customer doesn't know what he wants, so we'll start spending his money to find out. (This is actually the basis of Agile, so it can work if both parties understand and agree that is what is happening. Someone has to pay to discover what DONE looks like).