Leading Technology Projects (It’s NOT About Technology) by Gary Gack
Note: there are many general leadership lessons to be gleaned from this article. As the author points out, be sure to read beyond the more technical topics discussed found in the article – and look for ways to can apply the many lessons irrespective of what industry/business you are in.
More and more businesses and government agencies are finding technology, mainly in the form of software and IT, to be crucial to their success and efficiency. From ‘hardware’ products that are becoming software-enabled to enterprise and worldwide information and business platforms – systems of software, technology, and related services drive today’s organizations.
Software is central to your ability to run your business effectively – it’s just as important to your success as are marketing, sales, finance, and operations. Most executives have experienced pain associated with software projects, and many have inadvertently made matters worse than they needed to be. My goal in this article is to focus your attention on several of the key dynamics of software projects and to position you to improve outcomes. We deal here with management and leadership, not technology – no ‘geek-speak’. This topic is developed more fully in my book Managing the Black Hole: The Executive’s Guide to Software Project Risk.
Software projects are risky – failures are common. Less than 1/3 of all software projects (purchased or built) are fully successful. Success means delivered on-time, on-budget, with the intended features and functions. The average software project overruns its budget by around 50% and schedule by around 80%. The average project delivers less than 70% of planned features and functions.
Some may think “We buy almost all of our software – these risks don’t apply to us.” Sorry, the risks really aren’t that much different – many failures occur when purchased software packages are deployed and when custom development is outsourced.
In particular larger projects have high cancellation risk:
* approximately 20% of projects costing $1,000,000 to $25,000,000 fail
* approximately 40% of projects costing $25,000,000 to $200,000,000 fail
Software projects are extremely wasteful – typically only 30-40% of total software cost results in “value-added” – best in class organizations (less than 15%) achieve twice as much value add – 100% more ‘bang for the buck’.
Projects in the high risk group account for around 80 – 90% of total software spending, even though they constitute only around 8-10% of all software projects.
If you are, or may be in the future, a business sponsor or customer for one of these sorts of projects, caveat emptor – forewarned is forearmed. Leaving the solution to these problems solely in the hands of IT specialists has not proven a successful strategy – top management understanding and engagement are required to improve outcomes!
Why So Many Failures? What Can YOU Do About It?
Very rarely do these projects fail because the technical folks are incompetent, but their focus is largely technical, not managerial. All of this vast array of ‘technical’ knowledge is absolutely necessary – but not sufficient.
The two most common reasons for project failures are management issues over which project customers and sponsors can and must exert considerable influence. Leaders need not be concerned with “how” – that knowledge can be contracted or hired. Leaders can, however, focus attention on a few important “whats” in order to reduce failures.
1. Unrealistic Estimates and Plans
We want it all, and we want it now! Wishful thinking is positively an epidemic – leaders at every level fall victim. In my experience, certainly supported by industry data, wishful thinking is a result of a variety of factors, but lack of estimating and planning expertise is the most serious. Machismo plays a part as well – even if no one else has ever done “it” that fast, we can!
Frequently, the software customer is requiring a level of performance that is simply not attainable – often the required schedule has never been achieved for a software product of the size in question.
What YOU Can Do About IT:
* Two fundamentally different estimating and planning methods are applicable to large projects – “top-down” and “bottom-up” – make certain both are used by professionally trained specialists. High risk projects should always use both methods as cross-checks against one another. In general the “top-down” estimate should be prepared by an independent party as a sanity check against estimates prepared “bottom-up” by the project team using an “industrial strength” approach – the Critical Path Method.
* Never commit to going ahead with a large project until a detailed plan has been prepared and reconciled to the independent top-down estimate. Planning might be done in stages, but must be detailed for the near term. An out-of-control project is one that does not have time to plan. Rush now, pay a lot later.
* Never negotiate schedules. A professional estimating process will provide the best estimate obtainable – if you can’t afford it, reduce scope or don’t start. Don’t kid yourself – the 3-minute mile is not going to happen on your watch.
* Hold teams accountable for quality first, schedule a distant second.
2. Inadequate Quality Management
Finding and fixing defects typically accounts for 60% of total software project cost. Few organizations have realistic measures of these costs, yet industry data are incontrovertible – many defects are “inserted” in requirements, architecture, design, and construction, but most are not discovered until testing begins late in the project. Invariably this leads to longer than expected test cycles, delayed deliveries, substantially higher cost than would be incurred had defects been discovered and corrected earlier, and significantly lower delivered quality.
Project status reports also tend to be misleading because they are not “quality adjusted” – i.e., project deliverables are reported to be “complete” yet contain many uncounted defects that will be found and corrected later – substantial rework of items previously reported “complete” will be required at a later date.
What YOU Can Do About IT:
To increase value-add the single most important thing any leader can do is to require an appropriate amount of resource, using appropriate appraisal (defect finding) methods, at every stage of every significant software project. Relying on testing alone is not a formula for success.
In order to gauge the effectiveness of appraisals every software project must count all defects discovered by each appraisal. That count, together with an estimate of the number of defects likely to be present, allows computation of an “appraisal containment rate” – an essential leading indicator of project success. You should expect your software team (or contractor) to provide convincing data that shows they have found and fixed at least 75% of the defects likely to be present in any deliverable claimed to be “complete”. As Deming said, “In God we trust, all others bring data.”
Many will be surprised to find the lowest cost and highest quality actually coincide – it’s always “win-win” when quality comes first. A typical software team can reduce Non-Value-Added by 40% and reduce the number of defects delivered to customers by more than 70% when quality best practices are consistently applied.
A Closing Thought – Morale Matters
Any technology project is people-intensive. If your team feels respected and appreciated, they can and will work wonders. Excessive overtime is a commonplace in technology fields and often leads to burnout. Relations between technology teams and their customers often become contentious.
Effective sponsors and customers will make sure they sit on” the same side the of table” as their technology partners and will go to great lengths to ensure collaboration over contention and avoid fault finding – the blame game is always lose-lose. Effective leaders will help the technology team succeed in the management domain by coaching, cajoling, and educating to encourage realism.
Gary Gack, is the founder and President of Process-Fusion.net, a provider of Assessments, Strategy advice, Training, and Coaching relating to integration and deployment of software and IT best practices. He is the author of a book entitled Managing the Black Hole: The Executive’s Guide to Software Project Risk. LinkedIn profile: http://www.linkedin.com/in/garygack
-What was your biggest takeaway from the previous ideas shared in the article above? Hopefully you were able to get the leadership lessons in it. The lessons to be found in the above article go far beyond those dealing just with rolling out technological projects. What did you think of the ideas shared?