"When I plan a project, the first thing I do is make a list of what's unique .... what will my new and untried experiences be for myself and my team, and what's new for the customer: will they see the value?"It strikes me that what is said above is just common sense; profound in its plainspoken words
Not actually me, but others whom I respect say this
But, then what?
Having identified the unique, and made the list, one must go on to prioritize the importance of dealing with each. There are matters of risk management, cost-to-benefit, and the simple fact that managing more than a dozen objects in a class is just beyond the pail for most.
Of course, you can distribute the load and delegate to others to take on their dozen objects, and thereby get more breadth and perhaps depth.
Kano Analysis
At this point, there is something to be said for Kano Analysis. The value of unique -- as viewed from the customer side (an Agile principle applicable to all projects) -- has multiple characteristics:
- Some truly unique outcomes will be ignored by customers; they are "indifferent" about them, and perhaps only if missing do they cause a customer to fuss
- Other unique stuff is the real ah-hah! of the project. This the customer reacts to strongly
- And then there that which is somewhere between indifferent and ah-hah!
The first rule of resources is there's never enough. And so, to the unique there must be allocations of scarce resources, and thus the PMO is paid the big bucks to manage who gets what.
At the end of the day, if done "right" as judged by sponsors and customers, the PMO is rewarded with the chance to do it all over in the next project. How swell!
Buy them at any online book retailer!
