The Standards Succubus

I once spent a year of my life helping a large North American service provider become Capability Maturity Model (CMM) level 3 and 4 compliant. I was young, and maybe even a bit delusional, so at the time I did not appreciate just how much of my youth was being squandered. With a few consulting colleagues in tow, I enthusiastically went about mulling over literally thousands of pages of system documentation and devising a massive volume of common processes, templates and technology standards for this particular organization’s software development life cycle. Yay me.

Of course it seems absurd to me now that a technology-based organization would have either the time or the millions in budget required for what was a huge undertaking. But since it was the late ‘90s, when IT outsourcing was becoming a billion-dollar business, standardizing your approach to software development, and in the process achieving CMM compliance, was de rigueur.

Believe me, I am not trying to dismantle with one pithy retrospective the reputation or suggested value of a model that has served the industry for decades. 

Rather, I am left wondering: what was it all for? Surely there were faster, more cost-effective ways of identifying, agreeing on and deploying key standards to get the organization working towards a common goal. 

Therein lay the problem, I think: somewhere along the line the standards became the goal. You see, the original goal was a more commercially motivated one: cut costs by removing unnecessary steps in the development chain and improve time to market by establishing a common set of technical standards usable by multiple resources. But with all that time and budget and people allocated, the standards effort took on a life of its own, and no one, including myself, had the foresight or pragmatism to rein it back in. 

Either way, did our efforts pay off? I don’t really know. After my colleagues and I achieved the CMM certification we never went back and assessed our original goals.

From Greek Tragedy to Erotic Thriller

So why on earth, as an executive committee member of the TM Forum, am I coming off as anti-standards?

I don’t mean to. In fact what I said earlier is what I genuinely believe: standards are critical for the industry to interoperate. As a founder and CTO of a software company, I know this all too well.

So I’m not trying to avoid them. What I’m trying to avoid is the myth of Sisyphus in the creation and management of standards—that is, the futile and endless pursuit of standards in the absence of a tangible commercial reason for them.

When I talk to other organizations about standards or manage them inside my own company I always try to apply a few simple core principles to creating, managing and using standards:

1. Have a good reason. Make sure there is a good, commercial reason for creating or adopting a standard. Don’t pursue standards for standards’ sake.

2. Focus, focus, focus. Focus on the core inconsistencies (e.g., baseline definition of M2M devices, key definitions for product-service-resource) or the interoperability issues (e.g., radio network protocols, key handover points between Product Management and Software Development) you are trying to solve. Don’t try to get everything standardized before you act. Technology does not like to wait for documentation, nor should it.

3. Keep it simple, keep it brief. If you end up writing more in the standards than in lines of code, chances are you’ve lost sight of points 1 and 2 above. Process standards should be seen as light guidelines, not how-to-breathe manuals, while technology standards should be binary, matter-of-fact positions that are not subject to interpretation. Standards should not stifle or waylay innovation.