After my first post on Troubled Project I got some nice reactions:
Damien Braeckman ‚I like the “”complexity game”” (good name by the way) and often add an additional dimension to it. After having the solution explained to my by the team, I rephrase the solution and explain it in my own words to the team. If they all nodd, you’ve got it right and the solution stands. If not, either the solution is too complex, or it is not understandable or explainable to the customer. Cross-checking!
Paul Royer even wants to use the games for his upcoming book on Project, Program and Portfolio Health Assessment.
I even got a good suggestion for the Expectations game
Peter Hill ‚Ask the stakeholders what the project must deliver in order to gain acceptance. If you receive muddled, ambiguous answers, and widely different expectations, that is an early warning sign that your project could be heading for deep trouble. Unless you define acceptance criteria, you will have great trouble closing the project out because you will have different views as to whether the project is “”complete”” and customers will be unlikely to take ownership of your project deliverables.
In my next post I will discuss the following games:
– Do the team game
– Do the does size really matter game
