Recently in IT & Agile Category

- Put the customer above everything. This means customer satisfaction is above profits, revenues and even employee satisfaction. KPIs, Bonus, etc need to make this direction clear. Management behavior needs to make this clear.
- Temper customer satisfaction with fairness. A lot of times our obsession with customer satisfaction drives a misguided customer to take advantage of us. This does not go far. We are very tough on ourselves when we make a mistake but we want the same transparency from the customer when they screw up. Fair is fair. Paradoxically, customers end up by respecting and trusting us more.
- Tackle a problem immediately. Speed is of the essence. Act immediately to address any issue with a sense of urgency. Tell your people they have an open direct escalation lines to management to fix any problem.
- Solve endemic issues with process. Constant fire fighting does not scale. Our people are trained to spot recurrent problems and deploy permanent solutions that prevent the issue from happening again. The company is constantly tuning practices and evolving processes.
- Hire smart, accountable, high-energy people. We can only address new issues fast through accountable, high energy people. We can only solve problems permanently with innovative solutions through smart people. This is why we invest so much in the recruitment process and in creating an environment where this class of people can thrive.
This insightful article from Thomas Wailgum at CIO.com summarizes the typical situation organizations face when having to adapt commodity software to a changing business and to their specific processes.
Do not change ERPs
Traditional software packages (ERP suites the best example) are, by definition, not meant to be customized. The strategy of ERP vendors is to embed in their software, business processes that are common enough to be deployed in the largest possible number of companies. The continuous addition of new functionality produces a bloated mass of alternative code with very complex product release cycles.
Organizations that customize a package create a private "code branch" that needs to be maintained in-house. This is like diving into the gates of hell. From that point on, you inherit part of the vendor's complex development cycle. You make it very difficult to merge your own changes with the next product release of the vendor. Your maintenance cost sky rockets and your meager resources get sucked by these packages. The wise and experienced IT professional only needs to go through this process once to never again dare to customize an ERP.
But if you use packages to only implement commodity processes how do you support the processes that are your own? And how do you support processes that are the result of internal innovation and represent your own strategic competitive differentiation?
Commodity vs. Competitive

Innovative processes, strategies and ideas and their supporting IT, flow from the Invent, up to Deploy To Scale. In time they become a commodity (as they are copied by others) and move sideways to Manage Scale. Finally some of these processes stop being mission critical and can be Offloaded.
Packages are a good fit if applied to processes in the Context quadrants. And, in this case it is acceptable that the organization actually adapts to the ERP processes. Hey, it is commodity, so except for some reengineering discomfort, why not?

Build Custom Software
IT applied to the Core quadrants however, needs to reflect the innovation that is created inside the organization. In this case you need to build custom software. You need to have the software adapt to the organization processes. There is really no way around it.
ITs that support fast changing organizations, are already doing this. A typical enterprise architecture tends to divide itself between packages and custom built systems. A zoo of Java and/or .Net systems, Sharepoint customized portals, and Process Workflow tools support the two left quadrants. Web Services (I don't dare use the term "SOA") glue these things together.
So, is this a good strategy? Isn't there anything to hate about custom systems? Yes, there is. I will blog about it later.

Besides my daily job as CEO of