Process, process, process…

Process, process, process…

I\’m a fan of both documentation and agreed processes. Really. A big fan. There\’s nothing quite like it. OK, so I\’m a DBA and we don\’t normally document stuff or follow due process, but I really wish we could. It would make things so much easier.

There is a major challenge with this – it\’s not easy. We all WANT to have everything nice, tidy and available, but we generally rail against processes that don\’t do what we want, when we want them to. It does seem that a lot of processes and standards exist because then someone can place a tick in a box at audit time (and those timese are becoming more and more frequent, I can tell you).

A business process is usually aligned with a methodology. ITIL, COBIT, PRINCE, TOGAF, etc are all great tools to help you get a handle on what you\’re doing, how to evidence that you\’re adhering to to process, and provide auditors with warm feelings inside.

However, when the process just doesn’t make sense (even if it ticks all the boxes), you\’re less likely to collect good data about your project\’s performance against key deliverables and KPIs. If the process only exists for it\’s own sake, then you should really take a long hard look at that process and see if it could be done another way or removed altogether. This, I fear, is a stumbling block for many. Wouldn\’t it be great if we could just do the job, and the process takes care if itself ? I know I would. I\’d also buy-in to a process that was designed with my needs in mind, and if the business needs could also be met from the same data, then all the better.

Got a couple of quotes for you here. One from Albert Einstein, and one from a good friend:

Einstein : \”Things should be simple, not simpler.\”

Friend : \”The trick with PRINCE2 is knowing which bits NOT to implement.\”

Einstein was right on the money that. If the process isn\’t simple, change the process. All well and good, but try not to get hung up on simplifying EVERY process. There\’s an iterative approach to evaluating what you\’re doing, and that\’s really important. It\’s not enough to say that you have always done it that way, so that\’s how it\’ll be done every time in the future. If you always do what you\’ve always done, you\’ll always get what you\’ve always got.

My friend was also spot on in his assesment of methodologies – why would you need to run every project to strict principles, when not all of the those principles can be applied to every project ? To quote Monty Python, \”Universal affirmatives can only be partially converted : All of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan\”.

I\’ll give you a quick example, if I may ?

Today I was passed a document for review. It had a RACI matrix, scope, executive summary, all the things that you need keep your auditors happy. Except content.

That document only contained a link to a spreadsheet that actually had all the data in. The data that was collected and confirmed by those in the RACI matrix.

The problem here is that there\’s no process for expressing the useful data in the methodology being applied, so the first document only exists to complete the process, and nothing else. It has no other useful meaning. Further, the REAL data has no project metadata associated with it, and as such is considered by the project as \’junk data\’. If it\’s junk, why does it exist ? If it\’s not junk, how could it be properly classified ?

Perhaps the solution may be to revisit the project processes and standards to make them simple, or perhaps not apply all principles to all projects ?

I\’m not sure, but reviewing one appropriate document has to be more efficient that reviewing two that have no actual value.

And it\’s easier.

Back soon…