Saturday, 12 April 2014

How to Kill Innovation

It annoys me sometimes when people introduce me as "The IT Guy."  I went to school to become a computer scientist.  Computer science is about creating and/or synthesizing solutions to problems following the scientific method.  It is innovative and it is creative.  IT is about management.  It is a profession that, for the most part, is about control.  Control and innovation are at different ends of the spectrum.

Aaron Schwartz (1986 to 2013) was a brilliant mind who went places he shouldn't have gone and did things he shouldn't have done.[1]  He had a thirst for knowledge and he believed it should be free.  This got him in a lot of hot water, even given his accomplishments, and ultimately he took his own life rather than face massive fines and jail time for stealing academic knowledge.  His end purpose for this knowledge?  Increasing his intellectual ability.  How many of us have had our wrists slapped for doing the wrong thing for the right reason?  (In my professional life, I can think of numerous reprimands for doing the right things for the right reasons.)

Aaron tried unsuccessfully to get on the board of directors at Wikipedia; as his intuition told him things were not quite right at this breakthrough of community involvement and intrinsic motivation.[2][3]  The momentum of Wikipedia was immeasurable.  Wikipedia as a source of knowledge was game changing and saw the death of Encyclopedia Britannica and Microsoft Encarta.  The biggest collection of human knowledge ever collected and edited by volunteers.

And here is what changed.  The momentum stopped.  A small portion of content was being vandalized.  So control was needed, and Jimmy Wales facilitated the rise of the administrator.  He justified it by saying that only 500 or so core people contributed content.  What Aaron showed was that there were outsiders and insiders, and outsiders - infrequent expert contributors - accounted for most of the new content, while insiders provided most of the editing.  So Jimbo focused on supporting the insiders and the new administrators.  Though the motivation of the editor was to maintain a consistent quality, the motivation of the administrator was to implement control.  Outside contributors started to decline.

I and others have experienced this personally.  I stopped contributing to Wikipedia last year.  I tried to start an entry about the accomplishments of my recently deceased father.  He did a lot of good things for the City of Calgary that had not been recognized.  I have (he had) volumes of photographs of Calgary history that you wouldn't find in the city archive.  So I started the draft Wikipedia entry.  By the time I had the outline done, the draft had already been tagged as non-standard for deletion by an administrator.  By the time I figured out what was wrong, it was expunged.

A good friend who is very active in the tropical fish community was an avid contributor on the topic.  He was disappointed so many fish on the tropical list didn't have pictures.  So he reached out to the community to contribute their personal photographs - copy left - under Wikimedia.  He had a great response; over forty contributions, that he started to link into the Wikipedia page.  After a few, an administrator tagged the images as "stolen" because they were" too good" to be free.  The justification, later learned, was that he found one image contributed to a photo stream site by the same user whom contributed it to Wikimedia...  Wait a second.  An enthusiasts posts a picture of his fish to the public, grants public license, and that's theft?  And justification to remove 40 superb images?  Suffices to say that was the last time my friend contributed to Wikipedia.

Motivation is a fragile thing.  It doesn't take much to quash enthusiasm. Those two things are the keystones of innovation.






http://www.wired.com/2013/12/swartz-video/
http://www.aaronsw.com/weblog/whowriteswikipedia
http://www.aaronsw.com/weblog/whorunswikipedia

Wednesday, 15 January 2014

It's the Little Things that Count

It has been a while since I posted from the Armchair but today I was reminded of something so important to IT shops: It's the little things that count.  I did a quick job for a company - an out of band job - in that their internal IT was not able to do it - and it took me 23 minutes.  15 minutes of that was trying to figure out what the problem was.  Another 5 minutes to generate a wee bit of VBA code to change all control formats in an Excel spreadsheet.  And two days of someone's time saved (multiplied by how many spreadsheets, and there were a lot, as they were audit worksheets.)

I felt good about this.  This is one of the reasons why I liked being in IT: helping clients, saving time, saving money, and saving frustration.  And then the reflection on my past experiences and why I was popular in groups I worked in and why the IT machine disliked me.  Productivity solutions are not big projects.  They're tiny things.  They don't require high priced software or managers.  It is the practical execution of LEAN principles.  Identify those little, repetitive things that waste time and money and get rid of them.

In three local companies over the last 10 years I saw the "office productivity" groups get disbanded.  Each of these groups had "too much work" yet were eliminated anyway. They were very popular in the organization because everyone used PowerPoint, Word, Excel, and even Access and had these tools on their desktops. End users just needed a little bit more out of those applications - slightly beyond the reach of a power user. Personal productivity software is often the right tool for the job.  But big IT seems hell bent on killing the spreadsheet, etc.  Why?  Because its not manageable.  Because its not supportable.  Says who?

Says the person who measures themselves by projects and project price tags.  IT is ultimately a service within a company.  Technology enables people to work effectively and efficiently.  Isn't it fascinating how IT is trying to reposition itself these days as the agent for business transformation?  We can help our internal clients do better by being champions of continuous improvement.  Unfortunately many C.I. groups I know are very keen to coach others on how to work better without actually being able to do the work.

Givers Take All from McKinsey is a fascinating article about corporate culture that promotes the belief that workforces that help enable each other are the most productive.  For me that is true transformation: break IT silos and help lighten the load.

Monday, 21 January 2013

5 Project Management Pitfalls

There are always good intentions when starting any project, in particular when those projects are championed by new leaders eager to put their name on some corporate leaderboard. Today I had a sense of déjà vu, and I wrote and deleted a message several times to a new, old colleague about my appreciation of the book Death March by Edward Yourdon. So I’ve decided to put up an inspired top five list of pitfalls for friendly project managers everywhere that face similar dilemmas.

  1. Change for change’s sake is a mistake.

  2. Introduction of new processes, tools, technology, or methodologies into a project will blow any reasonable guess at a timeline.

  3. Throwing people at problems doesn’t solve them, it just makes it worse.

  4. Lack of change management is analogous to planned chaos.

  5. Process methodologies are philosophies, not standard operating procedures.



Change for Change’s Sake
Some old clichés come to mind. If it ain’t broke, don’t fix it. Why reinvent the wheel? It is okay to be the voice of reason and present the been there, done that in the face of change. New people tend not to be too excited to dig into corporate history to see what has been attempted and what learnings were produced. There is an oral history obtainable through discussions with the old timers that you won’t find in documented reviews, because failures tend to get less documented attention. It’s good to do a little research beforehand to discover if there is an audience for the change. I think of this as the counter to Einstein, who said crazy is doing the same thing and expecting a different result. In this case, crazy is doing something different and expecting the same result.

Injection of New Increases Uncertainty
We’ve all been here. We have a new project and we really want to try out the latest silver bullet trend. It is, after all, exciting to try new things. The only issue is that finding expertise on new is impossible. You learn by doing. You learn by making mistakes. And by that time, you’ve invested so much time in it, you wonder why you didn’t use something proven because you could have, in hindsight, done it in a fraction of the time. New things just haven’t had the burn in time, or the evolutionary filters to prove they have the survival stuff. So, if you are on a critical project, reject new like it was the plague.

Mythical Man Month
Sometimes we have tight schedules and we figure it is easy to throw resources at problems to get tasks done in parallel. We know there is a logistical overhead. But there is also a quality and consistency hit. With brief training, not all temporary workers will produce the same quality work. They likely have a different understanding of what the task is than their peers. So it makes sense that we have a quality control group. It makes sense to do a lot of level setting, and knowledge sharing, between project folks even when they’re on parallel tasks. Though it is super tempting to keep our heads down and focus, and maybe even entertain cutting out things like testing and quality control, it really is the worst decision we can make (because we put controls in place to reduce risk.)

Change Management Good
Change management is all about reducing risk. You don’t want feature creep. You don’t want interruptions. You don’t want to get hijacked by low value, high complexity, and quite likely pointless flavour of the day type distractions. They are distractions. Work the plan. If it isn’t documented, and signed/authorized by someone in authority, be prepared to defend yourself when things go south because the execution of unmanaged change is the fault of the execution team, and the originator of the change will choose not to remember the expensive, out-of-band change request. Even if they do remember, it will be your fault because you were never asked to foul the timeline.
Change needs to be communicated gently to all stakeholders. And too much change is a bad meal because an organization can only digest so much of it at a time.

Methodologies are Not Holy Scripture
Thou shalt not treat all problems as nails and methodologies as hammers. Methodologies are guidance. They are good philosophies that apply in certain contexts. If you try to regiment a philosophy, be prepared to waste time dealing with exceptions. For example, DMAIC is for process improvements where the process has a good level of maturity. DMADV is for new processes in organizations that have good understanding of maturity. PDCA is better for immature processes. Like living things, some ideas are only viable in certain environments. Know your environment. Pick fit for purpose and settle on just enough method to attain incremental improvements and/or consistent quality.

So this is my sage rambling of the day. Enjoy.

Thursday, 13 October 2011

ArmchairCIO Mourns Dennis Ritchie

Dennis Ritchie, one of the most influential people in the development of modern computing, passed away on October 8, 2011. Dennis designed the C programming language, and developed much of the Unix operating system. Its not my intention to go into great detail on the evolution of either of those. It suffices to say that C was the spark for languages like C++, Java, C#, and Objective-C - upon which most of the world's software is built. Without Unix, we would not have SunOS, Linux, or MacOS X - heck, even the iPhone runs a stripped down Mach Unix kernel.

I felt compelled to write a tribute blog, because a lot of attention has been focused on Steve Jobs death on October 5, 2011. Without the work of the demure Dennis Ritchie, Jobs wouldn't have much to sell. I saw no mention of Ritchie's passing in the major news media. Most of it is still homage-de-Jobs and the recent Blackberry outage. I think that is truly a shame because Dennis Ritchie's contributions and what they enabled are truly astounding.

In the summer of 1986, I was in my second year of university, taking summer courses to correct a "lack of discipline" I experienced in my first year. The University of Calgary computer science department allowed me to have an account on their DEC mainframes, even though I wasn't taking any courses that really required it, because I had asked the administrators for access in order to learn C (in order to learn how to fully utilize the Unix operating system.) I'm grateful for the patience those administrators showed me, because I had a knack for getting into trouble (with computers.) Dave Mason and Keith Andrews, if you are out there, thanks.

I bought the K&R C book by Ritchie and Kernigan (on Dave Mason's advice), and I was amazed how quickly I picked up the language; literally two weeks. Previously I had learned the procedural languages Basic, Pascal, Modula-2, and COBOL, and one thing about C stood out: it was concise. In very little text, requiring very little typing, you could build sleek programs. In some sense, that lack of verbosity was very enabling - especially at a time when auto-completion and code-generation didn't exist because most terminals/computers didn't have the horsepower.

I spent the next 20 years programming in C, or C derivatives like C++ and Java. This language was really a keystone in the development of everything digital. From your digital devices, their drivers, operating systems, to desktop computers, or other electronic devices; chances are a C compiler of some sort was used to turn that source code into machine instructions enabling them.

So thank you Dennis Ritchie, thank you for providing us the tools that continue to allow us to explore and solution the digital future.

Friday, 7 October 2011

Human Capital

My opinion on certification has changed. I am taking a journey towards a Certified Information Systems Auditor (CISA) designation and have joined Information Systems Audit and Control Association (ISACA.) I also plan to take at least one environment and sustainability certification in 2012. Professional development and self improvement are excellent goals. The personal networking opportunities are also incredible. I am not 100% convinced of the value of the various hurdles placed to maintain any certification, for example the thousands of dollars and a month of time on continuing education via conferences and what not. In my opinion, experience, aptitude and self-directed learning are still trumps in that game.

As I study up for the CISA exam using the CISA Study Guide by David Cannon (amongst other resource), I'm noting a lot of scrutiny in the realm of IT outsourcing that further validates some of my beliefs on the topic. I've seen some interesting notes and experiences, including:
  • Outsourcing is done for a variety of reasons
    • scope of work is unknown (we can't afford to do it ourselves)
    • staff isn't competent or experienced (we don't know how to do it)
    • upper management thinks it is a good idea (not a core competency)
    • we're CMM level 5 and anyone could do our jobs (we've got it totally figured out)

  • If a company and its outsource have not both performed an independent audit and/or shared those results before the contract is signed, there is only "hope and prayer" that the company's service requirements will be met. (p.150)

  • Outsourcing must be based on facts and evidence. (p.337)

  • If you're not CMM level 5, don't bother outsourcing.

  • Many outsourcing initiatives are done for the wrong reasons and possibly half end up in "in-source return" situations (p.136-138)

I also continue re-reading Death March by Edward Yourdon. Everyone in IT should read this book as its almost as instructional as Scott Adam's Dilbert. (It is amazing how in over ten years since this book was written, nothing much has changed.) I've gone over the section on process dynamics a few times, and years ago I shrugged at the Abdel-Hamid software process model, but now it is meshing with my thoughts on effective staffing and building corporate value.

I've read that human capital brings three things to the table that can be abstracted; training, expertise, and awareness. Training is what you can be educated on, and in IT, it would be the technical aspects of a job (like a programming language.) Expertise is your exposure to business knowledge and how to apply your training (like building Health and Safety applications.) Awareness is knowing how your organization works and who to talk to overcome obstacles. The intuition that comes with that is incredibly valuable, as you may learn when to ask questions and learn from the experience of others, as opposed to re-inventing the wheel.

Outsourcing can be okay at the technical aspects, but expertise can be problematic (as stated in previous blogs) because to keep the cost down, an outsource tends to (attract and) hire less experienced workers that likely don't have direct domain (business) experience. They are even worse at awareness, because the outsource is not part of the company's business culture.

I think many in the business would agree that a good senior resource can accomplish work in half the time it would take a junior resource. The senior resource has probably solved the problem before, or has parallel knowledge. The senior resources should be the norm against which all work is measured. These are the folks that have been with a company long enough to know how to get things done within the organization's culture. There are also experts, or gurus, that ascending above the average senior resource and tend to move mountains with their thoughts.

Consider the following diagram, where the Y axis is cost per resource, and the X axis is time in months. The work is constant (as the functionality of an end product would be the same.) Let's assume the junior resource cost $50/hr (2/3 of the senior resource) and takes twice as long to do something as a senior resource at $100/hr. Let's also assume that the guru is being measured at $150/hr, and he can move about nine times faster than the junior resource.



It seems obvious to me that assigning senior staff to a key project is both cost and time effective. And the really important thing is these staff represent in-house resources. Outsources don't have the gurus because they can't afford or retain them, and they have fewer senior resources because that domain knowledge is missing and they're insulated from a client company's culture.

The other part of the junior resource problem, as I gleaned from the Yourdon notes, is the buffer time it takes to get junior or senior resources engaged on work. Some might call this the learning curve, but it is more than just a technical aspect as you learn the tech, the domain, and the environment. There are other buffers as well (that may be bureaucratic or resource scheduling in nature.)

Here is my extension of the resource process model, including the concept of buffers, and adding some feedback. For posterity, let's call it the Wieser model of Human Capital.


At the start of process, new hires come into the system. You can measure their rate of entry. Once in, they will be assigned work, and you can also measure the "Rookie Buffer", that is, how long it takes them to achieve baseline (senior) performance. This feeds the assimilation rate. Sooner or later the junior resources evolve into senior resources. An important thing implied by the diagram is training. You can infer the effectiveness of training by the same means (because it should decrease the time it takes to do the work, and also decrease the number of iterations and/or errors.)

Once the resources have been assimilated (and that means they have the technical skill, the business experience, and cultural awareness) you can again measure and define baseline performance and know the pulse. The next big thing is the exit rate, that is, assuming the junior resources become senior resources, watch what happens to them. There are some interesting metrics here, because it can guide your adjustments to the entry rate.

LostA resource may get redirected, that is, take a different career path within the organization.
FiredA resource may get let go with cause.
QuitA resource may leave for some reason (that is important to figure out. Did they get a better offer? Was there something negative about the working environment? Threats lurk in high exit rates.)
RetiredResources retire (but tracking early retirement is an important indicator for culture.)
DiedAccidents happen, but work place accidents or related incidents need to be watched very carefully.
DiscontinuedThe resource, for whatever reason, was no longer required.


The big thing missing is exit rates at points of interest. For example, if you spend a lot of time and money training resources that balk during the training or shortly thereafter, that is a very alarming cultural indicator. Some put this into the retention rate and measure it over milestones like on-boarding completed, five, and ten year anniversary.

Now, if you look back at outsourcing, either as a company that is in transition to outsourcing and is having attrition issues, or as an outsource where you may have a culling of senior herd to keep profit margins high, you will see the model is front-end loaded. The true value and potential of developing the human capital will not get realized.

Monday, 25 July 2011

There are no silver bullets.

A friend recently forwarded me a blog about a Gartner survey that had interesting statements about the relationship of CIOs to other executives, specifically the CFO. Some bold statements were made. CIOs are more about solutioning and tech du jour as opposed to financial control. Many large companies demand solid financial and risk controls, so where IT doesn't contribute to the bottom line, it should absolutely be reined in.

I believe there is an obvious answer to why there is a trend to transfer power back to the finance folks. Some CIOs suck at execution. They don't even know that they suck; they believe they are doing a good job (the Dunning Kruger effect.) There is an old Turkish saying: The Fish Rots from the Head.

Why is it that some CIOs suck at execution? There are many factors I'm sure, but it really needs a discussion on what execution means in a business context. Execution is the ability to deliver in a timely fashion. Get 'er done b'ys. The term execution excellence has been bounced around. It adds more dynamics about the leadership and motivation skills at the head.

Getting back to why some CIOs cannot execute, perhaps some of these breaking points apply:

  • there is no clear strategy beyond "support the business" possibly coupled with a lack of understanding of the business and inability to set priorities

  • does not engage staff in the trenches (that is common for strict hierarchical organizations or disconnects like outsourcing)

  • introverted and lack people skills

  • weak leadership

  • cannot effectively communicate

  • cannot coordinate across business domains

  • does not play well with others (king of the hill)

  • gather upper IT management around them that isolate them from reality

  • do not trust their staff


If a CIO cannot deliver a good product and service, then they deserve to be marginalized under financial scrutiny.

So let's rephrase the negatives as positives. A CIO can nail execution if they:

  • have a clear strategy

  • understand the business needs and requirements

  • have the ability to effectively triage

  • are in tune with the issues coming from the front line staff

  • exude confidence and are personable

  • can rally all staff behind a vision or initiative

  • are good communicators

  • can coordinate across business domains

  • are team players and foster team play

  • support openness and transparency

  • delegate effectively


I'd recommend the latter for any executive job description.  The only thing missing for a CIO is IS/IT experience.  If the CIO is all that (and a bag of chips), then they're worthy of being on equal executive footing.

Wednesday, 22 June 2011

Top Ten Outsourcing Lies

Top ten lists are very popular, so after a recent meeting where I was hearing a few positives of IT outsourcing, I had a strange sense of Deja Vu.  Now the word lie is a bit strong because it implies a conscious, wilful deception.  I do not believe all folks that sing the praises of outsourcing suffer from some affliction.  I'd like to think the quote attributed to Napoleon Bonaparte is a better fit:  Do not ascribe to malice what can be easily explained by incompetence.  That said, this top ten list can also be used as a check list to ensure you have the right outsource and agreement in place.  It doesn't matter if it is a service, product, or project.  The proof is in the pudding as they say, and if you cannot evidence any of these items, you are not setting yourself up for success.

#10         An outsource improves business continuity.
It is naive to believe, unless it is in the contract, that an outsource has an Emergency Resource Plan or Disaster Recovery Plan that is as strong as your business requires.  Think of it this way, if you pass the treasure to someone else for safe keeping, are you sure you'll get it back?  Will it be there when you need it? Many outsource companies have in their contracts a limit on liability to the cost of their service and not the value of the treasure.

#9           An outsource has comparable or better security.
Is the outsource's perimeter security and information security policy as strong as yours?  This should absolutely be in the contract, but like point #10, the further away from you the break-point is, the harder it is for you to do something corrective quickly.  There is also the irony that by opening a conduit to the outsource you are actually adding another break-point (that is out of your control.)

#8           An outsource has better quality.
Quality is very subjective unless you try to quantify it through solid metrics.  At the end of the day service satisfaction, cost and timeliness are bottom line indicators.  Defining Quality can be a job in itself.

#7           An outsource is faster.
There may be a few reasons why folks think an outsource might be faster, but the reality is usually Mythical Man Month:  The more people there are involved in a process, the greater the logistics overhead, the more opportunity for iteration and clarification, and the longer it takes.

#6           Outsources execute better.
Does your outsource measure its execution?  Do they share that data?  Do they compare to peers?  Do they believe in management frameworks or systems to guide all aspects of their operation?  Do they have a Continuous Improvement program?  Are their resources experienced and happy?  An embeded resource has a face and a certain level of trust.  Many outsources are black boxes.

#5           Outsources are cheaper.
You can't add the logistical overhead without driving down the other labour costs, especially for near-sources.  The first TCO reduction comes from releasing your trench staff.  If you presume these workers were paid competitively and were skilled to start, and were also loaded up with appropriate work, how can it possibly be cheaper by adding more expensive resources (like project managers, case managers, client managers) and cheaper resources (that equates to less skilled or experienced)?  Many outsources after five years are more expensive than in-house teams.  Off-shoring does take advantage of disparity in cost of living and labour market, but it has the downside of cultural and work-hours disparity, lesser security, and risky continuity.

#4           Outsources have better people.
The best people tend to be paid well and like being taken care of.  Many outsources do not hire the best people because those folks would make the labour cost go up.  Who makes a better burger?  The burger assembler at [fast food restaurant of choice], or James Beard?  (Beard is a renown chef and uses cream in his tasty burgers.)

#3           Outsources know the business.
An outsource might know their business, but do they know your business?  This is somewhat counter to core competency think.  To assume an outsource has the business knowledge in your field assumes that they also work for your competitors and/or have worked for you long enough to pick up your corporate knowledge.  Is every service desk or call center the same?  Not every application you use or product you produce is.   There needs to be a competitive differentiator somewhere.

#2           Outsources have deep benches.
It has been my experience that many outsources replace two-with-one, and not charge two-for-one.  Unless you offshore, the outsource is drawing from the same resource pool as your competition.  Why would you expect them to have better success at attracting and retaining resources given the cost pressure?  Benches get voided when there is a lack of work.

#1           Outsources follow best practices.
Outsources tend to do what they're contracted to do.  This is because most work needs to be billable, and strangely many best practices are not directly billable.  Take documentation for example.  It makes sense that an outsource would develop its own documentation and process models to help them service you better.  The reality is, it is not in their best interest, and they're not likely to share this learning with you anyway.  Best practices take time, even if the ultimate goal is eventually driving down the learning curve for the bench.  But figuring stuff out is directly billable.  A Tom DeMarco quote comes to mind: Crazy is repeatedly doing the same thing and expecting different results.

It comes down to core competency.  Does it apply?  It is rational to want to choose an expert to outsource work to that is their core.  At the same time, it is not rational to increase complexity in any system and expect a decrease in entropy.  Restated, you can't throw more uncertainty into the mix and still expect the whole thing to be predictable.  Predictable really means low risk.