Framework Sceptics

Once in a very great while one comes across a project or company so embroiled in paperwork that you come to suspect their managers of a fetish for red tape. However, most projects want to succeed and most companies want to make money, so it does not occur too often, and when it does the consequences for success and profit are easy to predict.

Amongst IT Service Management consultants its a bit of a sport to speak disparagingly of commonly used process frameworks like ITIL and BiSL, and project consultants in general like to make light a of full-blown PRINCE2 approach to projects. It would be very amusing for a physicist to essay the shortcomings of relativity, a composer to mock music theory or an accountant to say that the GAAP standard takes itself too seriously, but they don't tend to do that. These people realize that you don't have to involve Einstein's entire work every time you conduct an experiment with time and space, not all notes need be in a composition, and not all rules apply to all ledgers at all times. They go quietly about the business of being good at whatever they're good at.

Not the IT consultant. You're not a man to be reckoned with until you've stated that this or that framework is far too complex, never mind that you've never worked for an organization large or complex enough to utilize it. Project leaders are even worse. Depending on whom you ask, well over half or, according to some, more that three quarters of projects end in failure. Failure. Not on time, not within budget, and certainly not delivering the desired result. In my (albeit limited) experience, most projects suffer from a lack of preparation and an excess of unstructured work. I've yet to encounter the truly pointless progress report, the completely useless review meeting or the irrelevant risk register. Neither have I seen an IT department run so well that it cannot benefit from a little process optimization and a smidgeon more compliance to standards.

The criticism that a framework is too complex is irrelevant as long as it is not the stated purpose of that framework to be implemented down to the last detail. Scalability is at the heart of all frameworks I mentioned. The criticism that compliance comes at the price of agility and efficiency is a non-sequitur. It's true, but compliance is still worth the warranty it gives.

BP can tell you, they were not broken by over-compliance to a set of rules and regulations. One or two executives might even admit that a few more inspections and reviews would not have gone amiss. Similarly, I doubt a CIO was ever berated by his CFO for wasting money on process compliance. Rather a lot of them have had complaints about budget overruns on their projects, poor knowledge and asset management and opaque departments, I daresay. A little bit of common wisdom, also known as a best-practice based framework would not hurt to make sure the same comments don't come up during the next review.

Rather than proving the mastery of your trade by critiquing the work of others (which is used to great effect by many on a daily basis), contribute to the improvement of your tools and help to make the frameworks as slim and efficient as they can be. It's not like ITSM is an academic discipline (as opposed to, say, aerospace engineering).