Lies, Damn Lies and Information Technology
John Ladley's Introduction
Occasionally, someone will mail me an article to see if I can assist in getting it published. I am happy to review the articles and forward them to DMReview.com or another venue for review and publication (or return them with scathing comments - so you have been warned).
This article was submitted to me a few weeks ago and, admittedly, I was concerned about sending it "up the line." There are some strong statements made. However, the more I read it, the more I realized while the content is from one person's frame of reference, there are profound truths in the article. Few of us can argue that we have not been in one of the scenarios listed below.
At my request, I persuaded the author to leave his/her name off of the article. This person is currently placed high in an IT-related firm. He/she has also had leadership at several major BI vendors. This degree of candor can be refreshing, but also damaging to one's career.
Why place this article in a BI/information management setting? Why not a more general venue for applications projects folks? The answer to this is simple and overlooked. Our data management/data warehouse projects suffer horribly from a belief they are not subject to regular project management principles. When we see a project floundering or a data management effort that is not fulfilling its promises, we see echoes of the points below. Basic project management 101 is just as important to a data warehouse or repository project as it is to implementing an OLTP package.
Finally, if anyone reading this has additional thoughts, case studies, etc. that dispute or reinforce the points below, send them on in. I fully expect there to be a follow up article on this topic a few months from now.
The purpose of this article is to talk about the root cause of failed information technology (IT) initiatives. By root cause I mean the final source of the failure. For example: I recently had a flat tire and took the tire to a shop. They put it into a tub of water, looked for air bubbles and then discovered a large screw had punctured the tube. In this case, the two-inch screw was the root cause of the flat. Once they found the source of the flat, it was easy to fix. It was interesting to me that their methodology - a tub of water and looking for bubbles - was low tech, inexpensive and easy for anyone to use.
In thinking about IT initiatives I have worked on that have gone flat, I was looking for the screw (the root cause) and for a low tech, inexpensive methodology that anyone can use. In my career I have been near to or on teams where major projects have not gone as well as intended.
I thought of a major software product development project in the Silicon Valley. Every year the product was supposed to be complete and to be breakthrough in its domain. Every year for three years, we promised to deliver a complete and fully tested product, and every year we failed to deliver on that promise, so our salesmen and our customers did not buy. In other words, we lied to our internal customers (salespeople) and our external customers (Fortune 500 companies), and they did not trust us. They did not buy.
I thought of a huge ERP software implementation for a government agency that ended up in litigation because the prime contractor (we were one of the subcontractors) promised month after month that the software would be implemented as promised, under budget, and every month we fell farther behind schedule. Eventually the customer sued the prime contractor for breach of promise - again, there were lies about the status of the project.
I thought of another software company where I was the product manager for a software package that was based upon a powerful idea that could have made a real difference in the way people work. It failed because customers hated our user interface, and we lied internally to ourselves about how important the front end is to customers. Never mind that our front end confuses and infuriates people, we said, the back end and the idea will sell them. We lied about what worked for the customer, and they didn't buy our product.
Then it occurred to me: these projects failed because we lied about them. The Encarta Online dictionary defines a lie as: to say something that is not true in a conscious effort to deceive somebody. Therefore, I submit the following: all of us who have worked in information technology have at one time or another lied about the IT initiative we are associated with. We have said things that are not true in a conscious effort to deceive somebody (including ourselves).
When and how do we lie?
Well, we start early, at the beginning of the project. We say:
A clear measurable business objective is not all that important. We'll figure that out later. Although we don't have an agreed upon, measurable business objective for this project, that's all right. We'll figure that out later. We say this despite having been on any number of projects that failed in the past because of the lack of a clearly defined business objective. But we allow the business to tell us "just get started." And we fool ourselves into thinking we are sooooo good at our work, we can sneak this one on.
A committed, influential executive sponsor isn't really needed right now for this project. We don't have the right executive sponsor for this project, but that's all right. The company will see the benefits of this work once it is in place. Never mind that we know that the lack of an executive sponsor dooms projects from the start.
We don't have the budget (money, time, people) to complete this project as promised, but some miracle will occur and we'll pull it off. It's hard to ask for money, and we don't like to do it, so we'll lie to ourselves and to others about having enough. We will accept unreasonable deadlines, and we lie to ourselves we can't push back, or communicate reality effectively to management.
We don't have a project plan that is organized, complete, detailed and that has the buy-in of the people that have to do the work, but we'll just start coding and figure it out as we go along. Planning is boring and it exposes gaps in our thinking and available resources and it also reveals that this is going to be hard work and take time. Let's put this off and do the interesting stuff.
In the middle of the project we say:
We don't really need daily or weekly or even monthly status meetings attended by every key manager to ask the hard questions about project progress - we have too many meetings as it is. We'll just talk privately or send emails. It's easier to lie in private than in public and I'll believe you if you believe me.
If no one else is going to say the emperor has no clothes, I'm not going to. Everyone knows that project is falling behind, but I'm not going to risk my job or position by saying so.
I know that I've made a mistake, or I'm in over my head, or that I've been fudging my status reports, but I'll make it up by working harder and no one will find out. I tried this in college, by the way and it didn't work there, either.
We thought that the technology or the methodology we chose was going to work, but we're halfway through the project and it's clear we made a mistake - but let's pretend we haven't and put on a good face and hope for the best. Somebody could get fired over this and it isn't going to be me.
At the end of the failed project we say:
When the customers and business users asked for additional features and functionality I was afraid to say no, so I didn't. We would have delivered on time and under budget without the change orders.
I could have told the executives and managers that this wasn't going to work, but I knew they wouldn't listen, so I didn't. Again, we lie to ourselves we can't push back and create a false fact that no one is listening.
Lets make up some new deliverable and declare victory. We deliver something and circle the political wagons.
We delivered on a good deal of what we promised and did the best we could and where we failed it wasn't our fault. Anyway, there's always next year and a new budget.
I could have gone on with the list, but it was depressing. It was clear to me that the root cause of failed IT projects in my experience was that we made a conscious effort to deceive each other about things that were not working and paid the price at the end.
Enough of the Problem, Let's Talk about Solutions
Build a culture that values honesty above looking good. Such a culture begins with executives and managers who are honest about admitting mistakes, asking for help, and telling the truth about the resources and commitment necessary to make IT projects succeed. Hmmm, this may have helped Enron and MCI.
Tell the truth about the fact that we will lie to each other when we don't know, don't want to, and when we make mistakes. Agree to build a culture that plans for and allows for the mistakes good people make when learning how to do things they don't know how to do or don't want to do.
Hold people accountable, from the top down. Don't fund major IT initiatives that don't have an executive sponsor who will be on the line for delivery of the project, as promised, under budget. If the executive sponsor is held accountable, she will hold managers and individual contributors accountable. The lack of business accountability is probably the number one reason IT projects become layers of fabrication
Complete a clear and concise business case for the project authored by the executive sponsor of the project, with measurable objectives and an agreed upon Return on Investment (ROI). This business case should be in place before funding the project.
Have a conservative, clear and complete project plan in place before securing major funding. This plan will be specific about the major deliverables and who delivers them and who signs off on them as complete. Include in the plan reserve resources of time, money and people to deal with unexpected breakdowns and delays.
Plan for the fact that project plans almost always underestimate the amount of time, money and people necessary to complete a project. Secure adequate funding for the project, with a strategy for additional funding as needed to respond to changes in scope and mistakes in planning and budgeting.
Have a clear and complete project governance plan in place before starting the project. This governance plan will include:
- What individual is personally accountable for each major milestone and deliverable
- Who reports to whom
- Weekly status meetings attended by all key executives and managers to report in public on
- Financial status - budgeted versus actual project costs
- Deliverable status - what has been and will be delivered versus the plan
- Risk mitigation - where the project is at risk and what needs to be done
- Resource status - time, money and people that need to be reallocated in light of breakdowns and new priorities
- Overall project status - the overall project executive makes a public, documented assessment as to whether the project will deliver as promised, on time and under budget.
Get experienced people with proven track records for key project positions
Reassign people who cannot or will not deliver as promised and replace them with people who can and will deliver.
See yourself as crucial in being honest about your mistakes and your lack of knowledge - tell the truth and ask for help.
Build a culture that values honesty above looking good.
I repeated myself on the last point because in my experience it is the most crucial condition for delivering projects that deliver as promised, on time and under budget. It is often also the hardest thing to accomplish and requires constant vigilance and work. That's the bad news. The good news is that a culture that values honesty above looking good is the foundation for successful people, projects and enterprises.
The contents of this article are Copyright 2003 by DM Review and KI Solutions. Any use, quotation, re-purpose, duplication or replication of the diagrams, concepts or content without permission of DM Review and the author is prohibited.
For more information on related topics visit the following related portals...
Business Intelligence and
John Ladley is President of KI Solutions (formerly Knowledge InterSpace and short for Knowledge and Information Solutions,) a management consulting firm specializing in knowledge and information asset management and strategic business intelligence planning and delivery. He can be reached at email@example.com. John Ladley presented his keynote address for the dataWarehouse.com Online Conference and Expo. You can hear his keynote at http://www.dataWarehouse.com/tradeshow/.
Provided by IndustryBrains
|Bowne Global - The Language Services You Need!|
We are the leading provider of translation, technical writing, interpretation services & more! We enable you to deliver locally relevant & culturally connected products, services & communications anywhere in the world! Request more information today!
|File Replication and Web Publishing - RepliWeb|
Cross-platform peer-to-peer file replication, content synchronization and one-to-many file distribution solutions enabling content delivery. Replace site server publishing.
|Help Desk Software Co-Winners HelpSTAR and Remedy|
Help Desk Technology's HelpSTAR and BMC Remedy have been declared co-winners in Windows IT Pro Readers' Choice Awards for 2004. Discover proven help desk best practices right out of the box.
|Online CRM solutions from SalesForce|
Online Customer Relationship Management solutions - sales force automation, customer service and support, and marketing automation. All this and no software! Designed for rapid deployment and adoption. Free 30-day Trial.
|Enabling the Dynamic Enterprise with CommerceQuest|
CommerceQuest offers a complete set of scalable enterprise business process management (BPM) software products and business solutions. Click here to learn more and download free white papers.
|Click here to advertise in this space|