Saturday, June 12, 2010

Are you an IT hero? Have you ever worked late at night on an IT project (of any size) because you just did not have enough time during normal work hours to get it done? Mind you, I am not saying that this type of hero is all good or all bad. My biggest strength is “learner”; I love the idea of learning, even less than the end result of the knowledge gained. That desire to learn has fueled many nights of heroism in the face of languishing projects.

The main issue I have with this type of hero is not the heroes themselves but how they are misused, and relied upon in many IT organizations today. Just as hope is not a strategy, heroism should not be a strategy for making project deadlines. In my experience most IT project failures are not technical in nature. I have really never stopped a project because I could not accomplish something through software or hardware technology whose capabilities are fully understood. However, I have witnessed how knowledge (or the lack thereof) and poor processes (or poor process execution) have stopped projects completely, or until new paths forward were found.

Process is the major culprit. Under the umbrella of process I include project estimates, development methodologies, project management, and thought processes (for starters). Of all of these, thought processes are the hardest to correct, and the most insidious. For, it is here where the false paradigm of hero worship and reliance are engendered.

I submit that heroes are needed when we fail to execute. I have lived this. I have been pulled into projects midterm when the paths forward were clouded with process failure disguised as technology shortcomings. Better processes would have led to better understanding of technology boundaries for a given solution. This is actually where architecture improves the outcome, but that is a story for another time.

I am not saying that I have not fed off of this from time to time. In fact it is somewhat addictive. In the end, however, the repeated need for heroes inevitably leads to burn-out and morale issues. It is not sustainable. Examined from a business perspective, it leads to inefficiency and waste. Perhaps this is what Russell Mullen and Steve Caudill discuss in their book “A Hero Behind Every Tree - The Non-Technical Reasons Your IT Investments Fail.” I haven’t read it yet, but the title, description, and reviews seem to suggest the ideas that technology is not to blame for IT project issues or investment failures and heroes are not a strategy. Even if I did not personally know the authors, I would recommend it for that alone.

When I was trying to cover Social Networking the other night in a business class lecture I tried to prepare for inevitable questions from students that had never seen some of these tools. It was then that I literally stumbled across Wikis in Plain English. Have you seen this Plain English series? They are both entertaining and informative, which in my opinion makes them quite effective.

As I was watching the video on Wikis I immediately started drawing parallels between the Plain English series and Low Fidelity Prototyping (LFP), a.k.a. Paper Prototyping. I used LFP to capture and present UI and workflow mock-ups quickly, in front of customers. However, its intrinsic value in my opinion was realized in the information gained and relationships built by engaging the customers directly. Everyone knows that not all customers are created equal and some customers find it difficult to contribute to project efforts, even though they are the single best resource for defining usability aspects. In my opinion LFP is the simplest (not to mention inexpensive) and most effective way to get these customers to create with you.

After almost 20 years in IT I have trudged through many different movements in GUI and workflow design session tools and techniques: JAD, RAD, Wire Frames, MS Visio. However, LFP has always been the most flexible tool for quickly reaching customers and capturing the essence of their thoughts. Of course once this information is captured it should then be distilled in to more readable models to ensure that manager types and end-users know that we as IT folks understand their world.

With the CommonCraft Plain English series here is an LFP in motion, with a twist of entertainment added. If is very effective, conveying the intricacies of Social Networking tools, or even Borrowing Money. In fact, I see the CommonCraft Plain English series as a aid to help us learn the effectiveness of LFP and how to use it to communicate with high fidelity.

Wednesday, June 9, 2010

In a recent conversation I was asked to explain the difference between what I call Tech-sand and what Ward Cunningham called Technical Debt. First, I do not see them as the same thing. In fact I see technical debt leading to tech-sand. The more technical or design debt that a business incurs, the harder it can be to get out of debt and move forward. The business is then stuck in tech-sand, not able to move forward, and not able to easily move back and undo what got them there in the first place. And don't even get me started on the irrelevance of considering sunk costs.

Yes some organizations plan for technical debt. In fact, I would argue that most organizations realistically have to absorb some amount of technical debt to remain proactive and competitive. Let's face it, IT is a commodity that is only differentiated by how well it is aligned with business and how well it is used to build barriers to erosion of competitive advantage. The idea behind knowingly incurring technical debt is to pay it down by incrementally replacing components or systems before "interest" payments (in the form of increased maintenance costs) become too large a part of yearly budgets or before aging systems are no longer nimble. Steve McConnell explains it well in his take on technical debt. I see it simply as how leveraged your organization is with technical debt. The more technical gearing you have the less efficient you are.

I argue that my term, Tech-sand, is broader in scope than software and hardware design and development. It is actually a worse case result. It can be the result of many different architecture and design decisions that are not well thought out, or based on politics or flawed financial models that do not understand the TEI (Total Economic Impact). Not understanding the true TCO of a solution can also lead to technical debt and and complete misunderstanding of what it means to service the technical debt.

Tech-sand can also be compared to a big ball of mud. However, again, it is not limited to strictly design and development of software or hardware.

The concepts of technical debt, servicing technical debt , and TEI should be looked at with the same rigor and systematic approaches that we use to judge the financial worthiness of companies. Apply the ratios. Today's IT budgets primarily go to operating expenses, easily 60% - 70% in some cases. How much technical debt does a company have and how much of their budget is used for operating?

How well a company manages IT and how well they make important technical and architecture decisions affect these operating budgets. Simply put, the more technical debt IT incurs, the more money in the operating budget it will need to service said debt. The trick here is to quantify this debt and monetize the budgetary aspects of its effects. Adding more people to the budgeted workforce to service a poorly designed or out of date system surely adds to the operating costs and can be seen as resulting from technical debt. Spending more every year, after factoring out customary software and hardware annual increases, points to a disturbing and identifiable trend. The IT department and more importantly the business is incurring technical debt faster than it can pay down the principle of said debt by replacing aging, poorly performing, and/or poorly designed systems.

Sooner or later these poorly performing, and myopic organizations will find themselves in Tech-sand. At that point, incremental steps are no longer adequate and major initiatives are needed.

Is the use of Social Networking tools considered innovation? In an article I wrote several years ago, I defined innovation as "managing the processes that lead to the introduction of newideas, methods, and technologies that provide business value". While I am not sure that using Social Networking tools is innovation, using these tools can be innovative and lead to new ideas. In other words it can lead to or at least help innovation along. In an article I read by Jeffrey Phillips on the Innovation Tools web site, he declares that Social Networking is not innovation. Again, while I agree with most of his points, I think that Social Networking used correctly, including filtering noise, is invaluable to innovative teams.

If any thing, Social Networking is emerging technology if you consider as I do that emerging technology is technology that is not currently in use by a business. It's not just leading or bleeding edge stuff.