We hear and
encounter a great deal of lack of process adherence in the IT industry,
particularly in the projects execution sphere. Most of the times, process
audits are nightmares for project teams
and people have the habit of 'PREPARING' for the audit after the audit schedule
announcement. This is not the case only with small or start-up shops where
processes might be managed in an ad-hoc manner.
Even the seasoned biggies, who boast of numerous process quality
certifications to their credit, are suffering from the disease. This disease is highly infectious and
creates bad blood between the QA and project delivery teams, often leads to individual/team
frustrations and worse organizational politics.
In the past various
attempts been made by stalwarts in the industry to regularize/de-regularize the
process framework structures so that one eliminates the overhead, improves the
compliance level and by the way increase the business value to the customer (if
at all possible :))
ISO
ISO failed to make a
cut with the industry mainly because of the fact that it's a generic standard
and has nothing to do with the industry itself. When your process framework is
agnostic about the industry, it becomes a dark box and nobody understands what
it does to improve the process quality, business outcome and ultimately the
value for the customer. Naturally many IT companies that have ISO are shying
away from even publicizing it. Many are
considering an exit
CMM Levels
CMM was addressing a
whole gamut of problems with generic standards because it is industry-aware.
Still the situation is more than chaotic- one project in level X, the other in
level Y, fudging of records just before the audit, meaningless documentation,
"project success but customer unhappy" scenarios and lack of
inspiration about processes and audits. What could be the problem?
Agile processes came
and improved the situation overall because of the insistence on team buy-in and
team empowerment. They took the processes closer to the teams. But is there
something missing yet?
I think so. I don't
think there are problems with different process elements themselves, but at
what level they are defined. The best
way is to 'Define the process elements at the
project level'. Why is it so important?
Because
Every project is unique- in
terms of objectives and requirements;
every customer/stakeholder is
unique - in terms of expectations out of the project;
Every IT eco-system is unique -
in terms of infrastructure flexibility and SLA agility;
Every project team in unique -
in terms of cohesiveness and collaboration needs;
Needs of an application
development project never matches with an ERP implementation or a Business
Intelligence initiative.
Defining processes
at the project level is not something new, in fact, most frameworks and
organizations optionally allow this. The point I want to emphasize is- it's not optional; it MUST be defined at the project
level and team buy-in for the defined
processes is very important for razor-sharp compliance.
One size doesn't fit
all. One process framework for the business division or the organization or the
whole industry is absurd. Let's NOT deceive ourselves by believing that
processes defined by one set of experts, written once upon a time within in the
comforts of an air-conditioned room are going to help our current project too.
We need a very pragmatic , down-to-the-earth, fresh
process definition that MUST happen at the project level, not even one level
above (say, Program level).
Let's treat each
project as unique one, let's involve the project team and the customer in the
process definition, tailor the framework to fit your unique needs and embrace
success. Happy projects!!!
