There are several quotes that resonant with me on a near daily basis in the project management domain. All of these come from direct projects or programs.
- I don't agree with you, that's because I don't understand - it is not incumbent on the listener to come to understand the ideas presented by the speaker. It is the speakers obligation to explain. So in the absence of a clear, concise, and logical explanation provided by the speaker, the listener is clueless as to why what is being said has any value.
- Just because I'm confused, doesn't mean you should stop talking - it may take awhile for the meaning to become clear enough for the listener to grasp the concept.
- Don't do stupid things on purpose - most new and innovative processes in project management are driven as the result of bad management or people doing stupid things on purpose. Doing waterfall when the requirements are still emerging, attempting to define all the requirements up front and failing to do rolling waves, making estimates of cost and schedule when the requirements are not stable or possibly not even known. All these an many more must be fixed before any new or innovative ideas are added. Otherwise you may have made the right decision for the wrong reason. If you work for a Dilbert boss, find a better job. If your customer can't tell you what they want the developed product to do, someone has to pay to find out. Agile is a method to pay to discover what the customer wants. A Concept of Operations is another way. A formal Capabilities based plan and its requirements specification document are others. But someone, somewhere, somehow has to discover what done looks like, either up front or along the way. Otherwise you'll only recognize done when you run out of time and money.
- Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about - if the conversation depends on making up new definitions for words already in use in the domain, it's going to be a rocky road to understand. Redefining the term risk management is my favorite for the agile proponents. Agile is not riks management. Agile is a software development method that provides information to the risk management process through evidence of working software. It is put of the Track and Analyze process.
- We don't try to predict the future in order to control it, we try to predict the future to prepare a proper response to the possible emerging events - the complete lack of understanding of statistical processes and probabilistic forecasting is the basis of most bad estimating processes. Which in turn creates the very false notion the forecasting should not be done. The fundamental principle of all business process is the value of the delivered item is dependent on its cost, as well as other attributes. But if I don't what something costs, I can't place a value on it.
- Never calculate without first knowing the answer - if you have no sense of what the answer might be, could be, should be, you have no way of determining if the calculation is correct. So when you here someone say this will cost $1MM how does that person know? What is the basis of estimate?
- Forecasting involves making projections about future performance on the basis of historical and current data - without knowing something about the past it is difficult to forecast the future. This does not mean you need to know the numbers but we need to know something about how the past number would have appeared. This is called a model.
- Put your CFO hat on. All business is driven by cost. If not, they won't be in business long - the simple and poasibly simple minded notion that we don't need to know the cost of our work efforts ignores this core principle of all business ventures not matter the source of funding.
So when ever you hear a pithy platitude, see if you can put it into the following structure:
- For - who is this statement, solution, idea targeted? What is the domain and context?
- Who - what is there problem? Can the problem be solved by simply stopping doing the "wrong" thing and start doing the "right" thing?
- Our solution - what is the "better" thing to do and how will you recognize that it is working?
- That - what is the tangible benefit to the project or business for doing this thing? What are the units of measure of this benefit? Who cares about the benefit? Let's start by asking those with the money if they care.
- Rather than - what is the description of the problem as a baseline measure? So we can test that the new idea actually made improvement.
