This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. All too often when projects fail, people are reassigned, project managers and key team members fall from favor, and the company quickly moves forward toward other new and important business initiatives. This phenomenon, at least the “quickly moving forward” part, also often happens to a lesser degree when production systems fail, backup/restore procedures don’t work, security breaches occur, and other bad things happen.  In these cases, however, because they are ongoing activities, IT generally does an excellent job discovering the root cause of the issue and performing the needed corrective action. Production groups then take the additional step of analyzing what organization and/or procedural factors allowed the issue to occur to prevent it from happening again. This mainstay of organizational and procedural introspection should also be used more heavily when projects fail or fall short of the desired result.  If you do, it can enhance your organizational awareness as to why the project environmentally failed, unrelated to the work performed by the project members.  This increased knowledge can be captured by asking the following questions: Was the project team given the needed resources to complete the project? Was the project properly prioritized, thus having the ability to gain the needed information, approval, support and resources of those outside the team, but crucial to its success? Was the correct mix of technical and non-technical skills approved and included in the team’s original [...]

This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. Every department within IT is part of an overall technical ecosystem that is connected to all other departments in some way.    For example, Business Analysis provides functional specifications to the programmers. Trainers provide classes which help programmers learn their craft. Database Administrators design database schemas for use by the programmers and oversee the storage and movement of data in cooperation with Enterprise Architects and Production Operations. At a macro level, Data Security protects the computing environment, Data Communications maintains the computing backbone and the Help Desk keep all IT and user devices up and running. If any of these departments fall short in the execution of their responsibilities, then IT and the company it service could fail.  As a result of this interrelationship, productivity initiatives in any one department can positively affect other areas of IT and the company overall.  This concept is called “Productivity Linking”.  Understanding these connections allows you to strategically prioritize your productivity initiatives, based on what is best for IT as a whole.  The technique used to document and analyze these connections is called “Productivity Mapping”. The Productivity Mapping process begins by defining your primary goal, which, generally speaking, will loosely fall into three fundamental categories. General Productivity Enhancement Specific Department Productivity Enhancement Specific Process Productivity Enhancement General Productivity Enhancement is the goal of boosting the organization’s overall efficiency. This type of productivity can be attained using [...]

This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. Like data, corporate knowledge is created, stored, distributed and consumed.  Unlike data, however, it can also be easily lost. This lost knowledge is caused by multiple factors, including: Retiring IT staff Employee attrition Temporary contractors moving on to other assignments Vendors completing their software development engagement and moving on to new clients Employees with technical skills moving into non-technical roles, causing their technical ability to diminish Preventing knowledge loss within IT has three primary steps; Creation, Retention and Distribution. Knowledge creation comes from two primarily sources, mental and physical. Mental knowledge is generated via ongoing employee experiences, formal/informal training, innovation-related activities and through the implementation of new software, processes, and methodologies.  Physical knowledge are the artifacts created by employees as part of their jobs.  These include internally-built software, written documents, and formalized internal procedures. Physical knowledge has the potential to be used by the company long after the employee or contractor has left the scene. The retention of mental knowledge, however, is much more elusive. The issue with this mental knowledge, often referred to as “corporate knowledge”, is that it’s embodied in people.  As a result, it can easily fall prey to human frailties, employee career choices and non-work related decision criteria. This raises the question of how to retain this corporate knowledge when employees, contractors, vendors and others exit the corporate nest. The following activities retain human-based knowledge. Implementation of [...]

This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. A few years ago I had the pleasure of speaking with Joseph Raynus about the difference of being “efficient” and being “effective” and its effect on IT productivity and business value.  His thoughts are still very relevant to IT organizations today.  He is the founder of ShareDynamics, a speaker, an author and an expert in business process management and strategic program/project planning. Mr. Raynus said that generally speaking, IT organizations are efficient regarding the ongoing execution of defined production processes and, if solid methodologies are in place, in the definition, approval and follow-through of project related activities.  The question is “Are these technical endeavors effective in their ability to maximize the value of IT to the business?”. He went on the say that IT process drives efficiency, but IT strategy and alignment with corporate goals drives effectiveness.  He went on to say that there are four philosophies IT leadership should consider when trying to maximize their organizational effectiveness. Keep up to date on changing corporate objectives and business conditions: Given the continually increasing speed of business decision making and industry movement, IT executives and staff must continually ensure that the goals they are reaching for have not changed during the project execution phase.  The risk is that an efficiently executed project may not be deemed as effective if it helps attain a goal that is no longer in place. Timeliness is [...]

This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. Asset reuse is the repurposing of intellectual property, software, physical devices, business processes, and other similar company assets. From my perspective, this is one of the most powerful ways to maximize productivity. I say this because it helps you get more value out of the items you already own. In effect, you’re getting additional value for free. Economically, there is a major financial incentive to reuse your created, purchased, and acquired assets. As an example, let’s assume that the purchase of a new software costing $50,000 was justified based on its ability to save the company $60,000 (For the finance people reading this, yes, I’m totally ignoring the time value of money to make the example as simple as possible.) over a machine’s expected life of three years. Therefore, its return on investment is 20% = ((60,000 – 50,000) / 50,000). If the software can be used for a second purpose at no additional cost that saves an additional $5,000 during its three year expected life, then its total return on investment becomes 30% = ((65,000 – 50,000) / 50,000).  This 10% increase in ROI came with no additional cash outlay and relatively no risk or additional effort.  It only required inventiveness of the IT group. My favorite two examples of this concept are Source Code Control (SCC) software and Project Management (PM) software.  SCC software is designed to store, manage [...]

This post was first published in my “Driving IT Productivity” column on CIO.com and has been updated from its original form. About twenty years ago (ok, thirty year ago), I worked for a company that implemented a company-wide productivity initiative. To their credit, they really did it right. Senior management was very involved and truly worked hard to lead the charge. The program was clearly communicated to the employees. Prizes were given out to the teams that created the greatest company savings. All in all, it was very well done and very successful. A number of business processes were improved, vendor costs were reduced and quality throughout the company was enhanced. An issue that arose was the way they calculated savings, it was left up to each individual teams to decide. Yes, we were given some guidelines, but they were very open to interpretation. So, as you may expect, since everyone wanted to win the prizes and bragging rights for coming in first, everyone was very generous to themselves, regarding the calculated savings. In the first six months, the total savings across all teams was greater than the company’s annual revenue. The result of this poor measurement process was that the program lost credibility and was eventually cancelled; even though from a true productivity perspective, the program was a great success.  I clearly remember this event and the lesson it teaches.  Poorly and/or overly optimistically measurement, even in the best of projects, can lead to their downfall. As a result of this [...]