Process Definition at the Project Level

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!!!