I have been working hard on basic principles for product re-engineering.  From the looks of this series you can probably tell it might be a book some day.  It's all just a matter of time and priorities.  So much to do, so little time!  I'm sure you know the story.

Anyway, in this final part of my six-part series on business agility, I'd like to share some ideas recently emerging from intense engagement in this area.  Although they're probably not all quite ready for prime time and almost certainly not all self-evident, I think you'll enjoy them.  There's some good stuff here.  So here's my current list.  Feedback welcome!

1. Extreme business agility is ultimately about products, not processes.
   
   
2. It's not about IT requirements either.  It's about envisioning how you want product analysts in your company to be working three years from now.
   
   
3. GUI-based prototypes completely obscure product complexity.  They're great for getting business people excited, but if you're not really, really careful, they can get your company into a world of hurt.
   
   
4. Operational product know-how must never walk out the door when a key analyst retires or quits.
   
   
5. Decomposition might be good for figuring out what products are made of, but to engineer products you must build up.
   
   
6. Artificial constraints on products or your capacity to configure and deliver those products arising from the limitations of legacy systems are categorically prohibited.
   
   
7. Be forewarned, thinking in-depth about the company's product that way isn't as easy as it sounds.
   
   
8. Anything you can talk about must have a name.
   
   
9. If you want to play in the game you must use the right name for a thing.  As Confucius said several thousand years ago, "All wisdom is rooted in learning to call things by the right name."  Live by it.
   
   
10. A thing is a thing is a thing.  It is that thing only once, even if you modify related criteria.  For example, what "child" represents remains the same even if you have different criteria in different uses for how old a person could be and still remain a child.
    
    
11. Represent different criteria for the same thing in different uses as rules.
    
    
12. Definitions are never a when-we-can-get-to-them affair.
    
    
13. Definitions are for people, not machines.
    
    
14. There are far fewer terms in your product than you think whose definitions can't be based on the dictionary.
    
    
15. Allow unfettered customization of products — as long as it's reasonable.
    
    
16. Management establishes the boundaries of reasonableness.
    
    
17. The boundaries of reasonableness are always expressed as rules.
    
    
18. A rule at an earlier point in a product value chain must not refer to an event at a latter point of the value chain.^[1]
    
    
19. All decisions about product configurations or delivery must be explicit, not implicit.  There is no such thing as a default or assumed decision, even if agreed to en masse.
    
    
20. Head south if anybody from IT says they can go do all this on their own.

References

[1]  Refer to Part 1 of this series for an explanation of product value chain.
Ronald G. Ross, "Extreme Business Agility (Part 1):  A Value Chain for Re-Engineering," Business Rules Journal, Vol. 9, No. 9 (Sep. 2008), URL: http://www.BRCommunity.com/a2008/b438.html

# # #