Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Saturday, September 25, 2010

On Certifications and Tribal Culture - Part I

This post talks a bit about process and certifications, as this previous one did.

Some time ago two colleagues were faced with a curious situation. After developing and testing in semi-critical environments, they finally would put in operation an industrial decision support system in a critical environment.

The first funny thing was the meeting with the company's IT Department: two developers, one user, and... six persons from IT! A DBA, a network manager, an information security specialist, a "requirements specialist" - who had absolutely no idea of the application domain, and two i-have-no-idea-what-they-were-doing-there specialists in something-that-doesn't-aggregate-any-value-to-the-client-but-is-vital-to-IT-department.

The three first guys quickly got to the point, took their notes, supplied a nice and short schedule and were eager to leave the meeting and do their stuff. The other three started to do very basic questions (one of them did the same questions done by herself in two previous meetings) and in the end provided a three month schedule to "certify the solution". The second funny detail was that both the hardware and development tools were bought by them - and they took almost one year to do this. Thus, the certification of the application, would take one month, while the re-certification of the platform would take three months.

When our user asked "why all that?", they said "it's our process."

Now I go straight to the end: while the first three took one month to do the really necessary stuff, the "process guys" took SIX months to do their job. The fact was that any, I say, any, problem that they could have found (and they didn't) wouldn't cause more (or even 10% of) damage that a six month delay caused in terms of production throughput problems and related costs. However, of course, they had a certified process to follow.

This IT Department is Cobit'ed, ITIL'ed, PMP'ed, and even Function Point'ed.

However, their users hate them.

Almost every single time we met our users, they complained about how IT was slow and bureaucratic, and worse than that, how it caused delays in production and consequently financial loss. And every time users complained, IT repeated their mantra "it is the process, if we don't follow it, something wrong can happen." Even when our user tried to assume all the risks, they again repeated their other mantra "the process doesn't allow, only higher level decision makers can change this."

One can see two weird things in this story: first, doesn't matter if you are causing problems to the production department, you must follow the rules of the supportive department. Second, if changes to the process are needed, they are going to take long to happen.

Have you ever heard of the tail wagging the dog?

I know that all that certifications promise alignment of business and IT. And I DO believe that in most cases when a company get them, it really has alignment between business and IT.

However, certifications have three problems: i) they are based on documents, and documents are not software or hardware. Or, in other words, users don't use documents. In special those filled by IT! ii) They represent a snapshot of the environment, and this environment changes, however iii) how to be responsive to changes if the process imposes a lot of bureaucracy to implement them?

What a company need to stay competitive is to be responsive to changes. The only way of being bureaucratic and responsive at the same time is having a lot of people to manage change. The problem is that a lot of people costs... a lot! Therefore, bureaucratic processes are slow or expensive. Sorry for saying that, but in real world, things are even worse: these process become slow AND expensive. Of course, neither certifiers, nor certified will tell you this. Just ask users if they are satisfied.

So, what's the solution? Continuous improvement. I would exaggerate: Quick Continuous Improvement. If your process, certified or not, cannot provide this, change it. Quickly.

And the tribal culture part of this post? I will tell a tale in my next post.


  1. I reading a "Zurich Axioms" book, about specutalion, and its have 2 axioms that fit in this situation.

    Sixth Axiom: Mobility
    Avoid putting down roots. They hamper their movements.

    Twelfth Axiom: Planning
    Long-term planning to generate dangerous belief that the future is under control. It is important never to take very seriously their long-term plans, nor those of anyone else

  2. Very good post!
    I think we should find out our way to manage IT resources and demands.
    First of all we can't never lost the focus and the value of IT in the corporation.
    But we can't forget that if we are straight in the certifications, we could become slaves of "the processes".
    Therefore, we should find a way to feel the moment to skip some "papers" and try to be more effective in our acts and decisions.
    And never forget to consider the culture of the enterprise and the changes of the enviroment.