Wednesday, August 5, 2009

process corrupts, absolute process corrupts absolutely

Why are there continued changes in IT project management and SDLC processes? And why can’t developers and project managers define a single process that both agree on? Are there that many conflicting goals that prevent this from occurring? I think the root cause is the idea that a single process can be defined and put into place today, based on yesterdays findings and that will be beneficial tomorrow. No plan to put a stagnant process in place will never work, problems change, environments change and most importantly people change.

I think this is the root cause for continued process change, for example KanBan, which is based on Toyota’s car manufacturing process, just as Six Sigma was developed by a Motorola process break through. If you look closely enough, new processes are old processes re-purposed, re-named or slightly re-factored…why? I think the reason is that, once a process is put in place it goes through a phase of being formalized, dumb’ed down so everyone can follow, forced on to every new project and (most unfortunately) used to measure people’s ability and commitment to the company….exactness to steps instead of intent is followed. As the process becomes more out of step with current needs of both projects and people, they are targeted as being old and wrong and new ones are ‘discovered’ and implemented.

We need to get everyone (aka management) in line with continued process improvement (or whatever the new term for that is) and ensure that a meta-process is in place to continually review and improve and replace as needed.



No comments:

Post a Comment