Friday, 3 July 2015

Transferring Domains

Sorry, I've been offline for a few weeks.

Recently I transferred a domain from Network Solutions to GoDaddy... there were some hick-ups. First Network Solutions didn't want to let me go (and give me my transfer confirmation key) without a big upsell.  Any information on the web that you can do this without talking to someone is wrong. Second, the registrant contact info was so old on Network Solutions that it didn't appear to come from any current record I had there and so the email address notifications were going to didn't exist anymore.  That got solved when I updated the information in GoDaddy after transfer (and getting some warning messages on other contact accounts.)  Finally, DNS is not automatically transferred, so I lost my zone file.  I had to detach the DNS from Network Solutions manually and create the zone file on GoDaddy (and hope I didn't forget any of the Google special auth URIs.)

Hopefully now it is all better.

Sunday, 13 July 2014

Technology Road-map Outline

I've been considering the following outline for a technology road-map.  My main goals are to focus on the gap assessment between current state and trends, and the risks and relationships between the parts.

1. Vision, Mission, Goals
2. Business Drivers
3. Business Capability
4. Maturity Assessment / Measures

Shared Governance
5. Stakeholders
6. Workflow / RASCI / Structure
7. Communication Plan
8. Organizational/Functional Relationships

IT Risks and Strategy
9. Technology Trends
10. SWOT Analysis / Key Risks
11. Contingencies / MoSCoW
12. WISE Grid

IT Tactics
13. IT Alignment
14. Concept Diagrams (As-Is, To-Be)
15. Context Diagrams (As-Is, To-Be)
16. 5 year Gant (-1,this year,+3)

IT Details
17. Dependencies
18. Initiative Details with CAPEX/OPEX
19. Parking Lot
20. Sign off

I've thought about a section of success and accomplishments; something to show measurement against objectives.

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.

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.