- “Project has gone off the rails - again.”
- “I.T. Department is getting re-structured.”
- “C.I.O. replaced / resigned.”
- “Outsourced!” “Off-shored!” “Realigned!”
- “Heroic effort from contract Project Manager and team brings in project - 6 months late and 200% over budget.
- “Millions lost during system failure.”
If IT news publishers were actually publishing IT news then you will read more of the above in the media. You don’t, because it is no longer newsworthy. It is happening too often to be of interest to readers. It is better to write about new products, innovation, or the latest round of telecommunications deregulation than it is to report on IT service failures. Still, we all know about the frequent disasters.
Be in the industry and you are all too familiar with the skeletons, trail of decay and destruction behind the IT departments, IT projects and the millions spent on grand and empty promises of business value, return on investment and purported strategic advantages.
Depending on who you read, you will find that up to 40% of IT outsourcing deals fail to meet expected results and benefits. The chances of getting an IT project right the first time is less than 20%. If it is a software project on new technologies, it is even less.
Why can we not get it right? Why can IT departments and service providers not get themselves sorted out?
I am sure you have enough bad news at work, and don’t need more. This Blog entry devotes some time and thought to some basic principles in IT management, that if we get it right, we can make a fundamental change to the bad news that follows IT where ever we go. Let’s see if we can find a solution to the problem.
More of the Same
Einstein is quoted as saying: “Insanity is doing the same things over and over again, and expecting different results.” This is an overused quotation. Yet, it rings so very true.
By now, it should be obvious that some common practices in IT just doesn’t deliver. Some of these practices include:
- Replacing management over and over in failed IT departments or failed projects. If management is the problem, why not get it right first time around, instead of intervening when the project is late and over budget or the department is costly and non-responsive. The number of IT department restructures is alarming, and worse of all they are becoming more and more frequent - almost an annual event in some companies. A clear indication of a company or department that doesn’t know how to organize themselves is their affinity for restructuring.
- Assigning an IT Professional to multiple (and sometimes totally non-related) roles. For example: expecting an Designer Implementer (Analyst Programmer) to do the analysis, design, development, testing and production releases all equally well. Even more alarming is expecting a Designer Implementer to also Project Manager or do the Systems Administration. Firstly, these are all distinctly specialist roles, and the more experienced an IT Professional become, the more specialized they become. These roles also align to personality strengths, and therefore you will find that analysts are better listeners than designers. Designers are better problem solvers than analysts, etc. Secondly, Henry Ford has demonstrated at the turn of the previous century that there is significant gain in productivity, quality, lower cost, and more, when labour is divided into a production line. The Japanese has shown that even more gains can come from allowing specialization and innovation within these functional labour divisions.
- Attempting to capture a bespoke software development’s scope upfront. Then, trying to deliver it over a lengthy three month plus single phase project. The rate of technology development and change is accelerating, which makes most of what we deliver out of date by the time that it is delivered. You are starting with a disadvantage the moment you start. Plus, customers learn more about their solution as they see more of it being created, and this results in scope changes, requirement changes, business changes, all happening frequently and often while the project tries to deliver a scope that is behind, out of date, and only relevant to old business problems. Business moves faster in their learning and requirements than we can deliver change to that learning, and they know IT can just not keep up. One standard comment comes to mind: “IT is consistently failing to meet expectations.”
- Multiple projects on a single product or platform. In our attempt to deliver change to solutions that keep up with customer demand, we sometimes attempt multiple projects, with different teams to change a single solution or infrastructure. It often happens that these projects fall over each other, override each other’s delivery or simply break what is working. Then we are not even mentioning the resource contention. Increased capacity to deliver faster and more change on a single solution in IT does not come from multiple projects, but from improving delivery throughput by eliminating bottlenecks in a single work stream. In the past, user’s adoption of a solution was slower than the IT team’s capacity to introduce change and improvement. Recently, with web user interfaces, and advances in usability, users hardly require any adoption time, and they are impatient with the slow rate of response from IT. We should deliver more faster, and multiple work streams on a solution is not necessarily the answer.
- Software is never finished. We no longer have the luxury to design, build and deliver a finished solution that will last for three or more years. Simply put. we find more and more that I.T. solutions appear to never be finished. Generation builds on generations. Although we have architectures that last for many years, we find that we are constantly modifying, changing, improving, integrating and rectifying solutions. Over time this rate of change can decrease depending on the maturity of the solution, but never make the mistake that it will stop completely. The day it stops, is the day that you can switch off the solution and no one will miss it. When we realize that what we build and implement today will be the foundation for change for the next three plus years, we will definitely make things simpler, look for more flexible solutions, and lastly find ways to build a team that will continue to live with the solution. The total cost of ownership for a solution heavily leans on the cost and ability of change allowed by the solution. Less flexible will mean very expensive solutions.
- Doing it like we did last year. Technology innovation is accelerating exponentially. Not only is Moore’s law more true than ever, but similar trends can be identified for customer demand, technology adoption, bandwidth, processing capacity, software innovation, and others. However, we still think that the way we managed IT last year and the year before, the assumptions and conclusions, and skills are valid today. We still assume that it is better to buy than build. We still assume that packages are less risky and costly than bespoke development. We still think that the IT vendor will be around next year, and that the platform will be supported in five years time. IT Professionals are still sourced, employed, managed organized and rewarded the way it was twenty years ago. One constant we are confronted with each day is “change”. I am afraid that we have not yet really realized to what extend this constant imposes on our daily IT Professional lives. We are challenged to rethink and innovate our work practices daily and managers and organizations cannot keep up with this phenomenon.
- Experience makes up for lack of common sense. Whenever I engage with hiring managers, one of the main criteria they use for hiring IT Professionals is experience. Somehow, we assume that because a Professional claims that he has done it before, means he knows how to do it. Experience is in some situations a simile for mistakes. Granted, people learn through their mistakes, however, the chances for learning are becoming less and less the faster the world of IT moves. Software is shipped before it is finished. Customers design solutions on the fly and interactively. We should start to raise the priority of finding Professionals that can think and innovate over those that necessarily have more experience. Your ability as IT Professional to innovate without costly experience learning cycles will be more of value to the future IT organization than experience was in the past. Learn how to learn without making mistakes. Structured innovation methods like PDCA, SixSigma, Prototyping and TurboSigma should become standard tools in the make-up of every IT Professional.
- It is different, but is it better. Yes, things are changing, and yes we have to change with the times. There is one qualifying question we often forget to ask: “When we change it will be different, but will it be better?” This question pre-supposes that we know why we change, that we know how the end or outcome will look, and that we are clear on the value of the change. If change is better, then nothing should hold us back to innovate a better future. But change for change’s sake makes no sense.
What Needs to Change
Einstein also said: “The significant problems we have, cannot be solved at the same level of thinking, with which we created them.”
One cannot help but notice the paradox. What worked before, no longer applies. In fact, in most cases quite the opposite applies. Consider the following suggestions and let me know what you think.
- Instead of replacing manager after manager or department after department in the hope that it will go better, why don’t we define and innovate the model, then refine and grow the people in the model until it meets our and our client’s requirements? Then, we develop, measure and grow our managers and IT Professionals so that they meet this model’s objectives. Why don’t we define the model IT Organization, the model Analyst, the model Designer or Administrator, and allow our professionals to focus on meeting the model requirements and then improving this model? This way, instead of replacing expensive incompetent resource with other expensive incompetent resource, we have the ability to grow and actually become better at what we do. The more capable we become, the more we can refine the model to the point where the industry matures into a self renewing organism adapting to our ecosystem of client demands and expectations. ITIL, RUP and Profile-IT are on their way already, but they need your help. Instead of being a spectator, start to contribute in this participative society. Your contribution will make a difference.
- Become the best you can be in your area of IT Role speciality. It doesn’t help to be the best there is in JAVA or .NET because the chances are good that tools like JAVA and .Net will be replaced by something else in the near future. This will leave you without a job and the expensive need to re-skill, like the factory worker being made redundant by the machine that is replacing it. However, the chances of Project Managers, Analysts, Administrators and Designers being around ten years from now is a lot better. The tools may look different, but the professional competencies will only be more refined. Again, I am calling on you to contribute and mentor others. Stake a claim on what constitute the best Analyst, Designer or Manager and make yourself the best you can be in your IT Professional Role.
- Be ready to innovate your innovation. Your customer expects you to make today’s deliverable better than it is. He expects it tomorrow, and will expect an improvement on that the day after. Thank you to this wondrous business of IT we find ourselves in, it is possible to make it smaller, faster, better, more accurate day after day, week after week and year after year. It is an innate human trait to learn and innovate, and we are on the forefront of this glorious life purpose. Let us not be tripped by our inability. Let innovation in everything we do as IT professionals be not only an unconscious drive, but a conscious decision we take with everything we do. How can I do this better today, than we did before?
Hendrik van Wyk
Post a Comment