CIO Toolbox

Tools for today’s CIO

Cite a Standard, Know the Standard

Misc Standardl.png

The great thing about standards is that there are so many of them.  There are standards for just about anything.  Early in my days as an engineer a colleague of mine was looking describe the specifications for the newly released CD-ROM drives for PCs.  He ordered what he thought was the right standard from ISO and got something entirely different.  Mind you, it didn’t stop company reps from claiming full compliance when we asked them about their new systems.  In another case, I called upon full DOD-STD-2167A compliance for a standard computer software project back in the day only to find that the cost ballooned far beyond expectations (almost as bad as some of the other over-specified common every day products.)  Thankfully, someone took the time and walked me through the standard I had casually referenced and pointed out all the processes, documentation, reviews and attestations that I had invoked for my relatively small project.  Lesson learned, I started reading standards and specifications to understand all the mandatory, optional, normative, informative and other nuances found within.  I liked it so much that over the years I also contributed to a few including: ACP, DOD, IETF, ISO, TBS and others.

Standards are great since they help make things work as expected.  For example, they help make sure that when you plug in an electrical appliance, so that it safely performs as expected.  While standards frequently help things work, sometimes different interpretations or optional functionality within standards can prevent stuff from working properly together.  That’s just one reason why it’s super important to know what parts of the standard are important to you and what parts are not so important.  There are several others reasons too, including perhaps the most important one: cost.  Yes it can be a pain to have to wade through what can be hundreds of requirements, but ultimately simply pointing to a specification number is entirely unhelpful.

Technology seems to be evolving more rapidly than ever before and sometimes the speed of innovation outpaces existing standards.  New approaches for meeting requirements can create discord with the existing standardized status quo.  That’s when it becomes even more important to understand those details behind that specification or compliance standard number.  Maybe that new capability makes a number of requirements obsolete, or perhaps far exceeds the tolerances of days gone by.  Organizations, and the people using specifications to help their organizations, owe it to themselves to build out a comprehensive understanding of the specifications they are using and the rationale behind asking for them.

Perhaps it’s the pace of change, but recently I’ve also seen an increasing number of people ask about non-existing certifications or ask about compliance against standards that don’t apply to a particular scenario.  While not quite as egregious as the ISO Open Cold Storage of Cabbage standard I pointed to above (you saw that, right?), they are unfortunate none-the-less.  Calling out standards that don’t apply to your type of business or regions where you operate can create a drag on your business that you just don’t need.  So before you cite a standard or specification, take a moment to ask yourself what particular parts of the standard are most important to your business so that you can be sure that the solutions you specify do everything you expect them to.

By the way, sometimes people might simply call out an arcane standard with the hopes of cutting a meeting short by stumping the supplier sitting across from them.  You’d never do that, right?

Categories: CIO Toolbox, Uncategorized | Tags: , , , | Leave a comment

Growing jobs and innovation using a 3P approach

Hey, I’m over on the Microsoft in Government blog today.  I explore how governments can invest their dollars to best benefit startups. I asked entrepreneurs to weigh in, and they identified three guideposts.  These 3Ps won’t be what you expected.

Categories: CIO Toolbox, Digital Economy, Entrepreneurs, Innovation, Uncategorized | Leave a comment

Come on Deputy, Don’t Fear the Tech Gear

 “Senior leaders in government remain concerned about IT projects”, revealed a good friend of mine following a recent executive roundtable he attended.  He went on to note how unfortunate this is given the strong potential that technology has to meet the government’s objectives noted in the speech from the throne and other significant initiatives. 

You’ll recall that the speech from the throne ( ) calls for a review of administrative services with an emphasis on improving efficiency.  It also calls out the launch of a “digital economy strategy to drive the adoption of new technology across the economy.”  eGovernment conversations also raise the concept of government as a model user of technology, or even in some cases , a leading edge adopter of technologies through the use of test facilities.  So why the reluctance?

There are any number of reasons why senior leaders may be nervous about embracing IT enable service transformation.  One leading reason is the uncertain outcomes following several large bag phonegovernment IT projects.  I believe that this is a result of incongruous timing between policy and technology.  Government priorities, policies and even projects often span several years.  One great example is New Brunswick’s goal to become self-sufficient by 2026 ( ).  Started in 2007, this initiative had a close to 20 year time horizon.  If we shift to have a look at the technological pace of change where new features / services are being delivered on an almost weekly basis, especially in the case of internet based services, we can quickly see the staggering amount of change that can occur over 20 years.  While the number of changes due to weekly enhancements (1040) gives us a number that we really can’t appreciate, perhaps taking a look back at a common technology 20 years ago will put things in perspective.  The early 1990s saw the emergence of 2G networks and the cell phone pictured here.  So it would have been hard to imagine the multifunctional smart phones many of us use today. 

Now let’s think about a traditional large government project.  Large government projects take time, often spanning multiple years.  Often the time between original concept to final delivery can span several technology generations leaving even the seasoned project manager with a change control nightmare just to keep pace with changes in technology and, perhaps even more challenging, changes in their customer’s expectations.

Ruthless Incrementalism

Given this apparent discordance between policy and technology, what is a senior leader to do? My feeling is that the key is to deliver measureable and meaningful outcomes in shorter timeframes.  In place of multi-year, multi-million dollar “Projects”, deliver multiple low cost projects within a given year.  Instead of one million-dollar project, reconsider the project as a “Program” with one thousand, thousand-dollar projects.  These small projects promote agility in face of technological change while building towards the broader program goals.  The program can make rapid adjustments to ensure ultimate success should any one small project fail.  There are a handful of other key principles that support this nimble approach to IT services delivery that I’ll explore later through this blog.  But until then, with my apologies to the Blue Oyster Cult, “come on Deputy, don’t fear the tech gear

Categories: CIO Toolbox, Digital Economy, Uncategorized | Leave a comment

Blog at