The Geek Gap — 7 Ways to Bridge it to Drive Better Business Value

The “Geek Gap” between managers, known as “suits,” and technicians or engineers, known as “geeks,” was growing apparent in 2006 when authors Bill Pfleging and Minda Zetlin wrote The Geek Gap: Why Business and Technology Professionals Don’t Understand Each Other and Why They Need Each Other to Survive. The authors found that the faulty communication caused by the Geek Gap was costing businesses billions of dollars each year in failed IT projects. They reported that in 2003, the Geek Gap resulted in the loss of $55 billion in the U.S. alone, and they predicted that as business became more technology based, the Geek Gap would continue to grow. Now, fast forward a decade, this prediction has held true, and businesses continue to look for ways to bridge the gap between executives and technicians. In their book, Pfleging and Zetl explain that the conflicts arise from the very different viewpoints, agendas, and ideas of how accomplishments are measured. They say suits have numerous pet peeves against geeks. They believe geeks: Don’t understand – or want to understand – anything about the businesses they work in Love technology for its own sake, not considering what new gadgetry might cost Expect that suits understand as much as they do about technology Can never seem to meet deadlines or stay within budgets Think rules shouldn’t apply to them Are bad with people Adding to this, there are several pet peeves geeks have about suits. They believe suits: Refuse to learn anything about technology Don’t understand technology but insist on making technological pronouncements Don’t value technology Only care about money Resist innovation Value image...

Why so Many IT Projects are Challenged, Under Deliver Promised Value, or Outright Fail

For at least the last three decades, members of the C-Suite have been complaining about the frequency with which IT projects are challenged, under deliver promised value, or outright fail, and with good reason. The most recent Standish Chaos report shows that only 32% of projects are successful, 44% of projects are challenged, and 24% fail. The Standish Group defines project success as a project that delivers planned functionality on time, on budget, and includes all planned features. For Waterfall projects, the percentage of challenged projects is actually higher than it was 15 years ago. These low success rates are surprising given the focus over the last 15 years on project management and the push for project management certification. Agile has helped significantly with project success rates as seen in the table below.  According to the 2011 CHAOS report, Agile projects are successful three times more frequently than waterfall projects.The report goes so far as to say, “The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.” Even though the Standish research shows that the chances of success are much greater with Agile than when using Waterfall, there is still a high chance (58%) that a project will be challenged, failed, or cancelled. Many projects that would have been considered successful using the Standish definitions may have another problem in that they deliver little or no business value. Let’s look at some recent industry quotes on this topic. 78%...

Calculating ROI on Information Technology Projects

ROI (return on investment) is a widely used measure to compare the effectiveness of IT systems investments. It is commonly used to justify IT projects, but can measure project returns at any stage and be used to evaluate project team performance and other relevant factors. Definition of ROI The basic ROI calculation is to divide the net return from an investment by the cost of the investment, and to express this as a percentage. ROI, while a simple and extremely popular metric, may be easily modified for different situations. The ROI formula is: ROI % = (Return – Investment Cost)/Investment Cost x 100 Using ROI within IT Projects Comparing the ROI of different projects/proposals provides an indication as to which IT projects to undertake. ROI proves to corporate executives, shareholders, and other stakeholders that a particular project investment is beneficial for the business. A project is more likely to proceed if its ROI is higher – the higher the better. For example, a 200% ROI over 4 years indicates a return of double the project investment over a 4 year period. Financially, it makes sense to choose projects with the highest ROI first, then those with lower ROI’s. While there are exceptions, if a project has a negative ROI, it is questionable if it should be authorized to proceed. ROI may not be useful in every IT project. Below is a list of examples where calculating the ROI may not be appropriate: Expenditure such as IT consumables, replacing broken PC’s Short duration maintenance projects that can be completed in less than 1 month. Projects that do not produce cost...

What is the Real Cause of Failed IT Projects?

The Standish Group conducts ongoing research on the reasons why IT projects fail or succeed.  The original Standish report was completed in 1994, and published as the CHAOS report. The report has been updated many times since. The report divides projects into three key outcomes: Successful Projects – projects completed on time and budget, with all features and functions as specified. Challenged Projects – projects completed, but were over cost, missed the planned delivery date, or lacked originally specified features and functions. Failed Projects  – projects abandoned or cancelled and became total losses. According to the Standish Group, a successful project must be completed on time, on budget, and deliver the promised quality (features and functions).  Anything less is considered either a failed or challenged project.  The disturbing conclusion from the original Standish report is that only 16.2% of projects were successful; 52 percent were challenged or partial failures; and 31% were complete failures.  These numbers have improved in recent studies, but not significantly. It is difficult to believe that the number of failed or challenged projects could exceed 80%, but the numbers could be even worse. I know of many projects where all of the scope of the project was delivered on time and on budget, but users were completely dissatisfied with the solution delivered or where expectations defined in the business case were never met. Perhaps we should define a successful project as one that: Delivers all planned scope meeting cost, quality, and time constraints, Achieve high user satisfaction and Delivers the benefits presented in the business case. Using these criteria, determining success should be clear and...

The Ugly Truth About the Challenges Facing IT

Traditionally, IT has been overly influenced by application vendors. This has resulted in IT architectures that are either application or integration-focused, and not business process focused. Integrating a variety of application architectures from multiple vendors is complex and challenging; integrating with new cloud based offerings will further exacerbate this situation. Because of governance and funding models resulting in long lead times for IT projects, business units have had to do whatever it takes to address their business needs. Not being able to wait for IT, business units have often moved ahead with implementation of many “one-off” or shadow applications that may or may not be integrated into the existing IT architecture.  To make things worse, mergers and acquisitions have introduced new software platforms and to an already fragmented IT architecture. Because of the cost cutting that has occurred over the last five years, IT departments rarely have sufficient resources to manage this complexity and mess.  As a result, often multiple systems that perform the same tasks are deployed within an enterprise or business unit. Redundant infrastructure solutions for authentication, single sign-on, and data marts, as well as applications (packaged and custom) such as sales force automation (SFA), quoting, and order management compound, the complexity and cost for IT. This complex and fragmented architecture has made it nearly impossible—and definitely impractical—to modify the application portfolio to quickly and efficiently reflect a change in a business process or support a new acquisition. In many organizations, IT groups have tried to integrate these siloed systems using a point-to-point or EAI approach that connected the application to both upstream and downstream systems. To...

Requirements – The Missing ITIL Lifecycle Phase (Part 1)

The focus of ITIL is on delivering services to customers. ITIL defines a service as  “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific cost and risks.” Most every organization that has adopted ITIL V3 wants to start by defining their IT services, creating service catalogs. and starting the process of business/IT alignment. Unfortunately, ITIL doesn’t offer much guidance on exactly how to accomplish these things, and many IT organizations stall as they work at defining their IT Services. One of the main reasons so many organizations are stymied at the IT service definition phase is precisely the lack of guidance on how to perform IT service definition. ITIL provides little useful information for defining services and does not help much with developing a sound IT service definition model.  Specifying a service requires an understanding of the environment in which the service is delivered. In particular, it is necessary to define attributes including: who is the service provider; who is the direct customer of the service; and (possibly) who is the “end customer.” Experience shows that answering these queries can be very challenging.  Defining application related services has been even more problematic for organizations. Another major problem is that the ITIL service lifecycle goes from strategy to design, omitting a requirement phase.  Service Level Requirements are a special type of requirement but are not the functional requirements that are needed to define an IT Service. Requirements are needed to define, manage, and deliver IT services. This article is part 1 of a series of articles that will discuss how...