3 Comments

3 Visible Pillars – Cost, Quality, Schedule

by Phil Smith, Vice President of Operations and Services

Phil Smith Bridge360Searching the Internet for “information technology project failure rates” will provide a wealth of data and information. Data is readily available in depressingly large volumes from studies that indicate that investing in IT projects is high-risk and unwise. There is useful text accompanying the statistics that explains root cause and even classes of failures. I like these sites because the content is well organized and they include recommendations for how to avoid failure.

The sites are:  Why Projects Fail, McKinsey Report Highlights Failure of Large Projects, and Gartner Survey Shows Why Projects Fail.

The Project Management Institute (PMI) was launched in 1984. The PMI material, certifications, frameworks (and everything else offered) are invaluable to any organization that runs an IT project. I applaud the PMI for giving the world of project management context and rigor to not only talk about improvement, but also a way to build methodologies to achieve the improvements.

Yet the statistics available from current studies, over 25 years after the PMI started helping us, are disastrous. According to the Calleam site listed above, a McKinsey & Company survey from 2012 showed that 17% of large scale IT projects fail so badly they threaten the existence of the company.

Again, there is no lack of material or training, even beyond what the PMI makes available, to help our IT industry improve. I often think of the maturity of the IT industry in comparison to the maturity of other industries like medicine, manufacturing, engineering, and construction. History indicates that assuming that customers will continue to invest due to lack of an alternative has turned industries and companies inside out once a suitable alternative becomes available. It is in our best interest to be in control of the revolution.

I know I’ve stepped into a complex dialog here, specifically with the subject of how to get the entire industry to move toward one common set of methods, practices, and cost structures. I argue the absence of common structure creates a gap that is filled by the client’s choice to bring unique and unrealistic expectations for cost, timing, and quality. Most consumers of IT services are well educated and know that writing a line of code only costs as much as the pay rate multiplied by the actual effort, which is not much.  Yes, that is the wrong way to measure cost but it is the way that most consumers elect to measure it in a negotiation, because we as an industry lack structure.  To compare, my recent trip to the doctor cost my insurers over $200, and I only saw the doctor for about 5 minutes.  I’m sure that along with the 5 minutes I was also paying for a lot of staff, infrastructure, insurance, training, equipment, and capability that all came together to make the 5 minutes possible.  And the doctor does not invoice the insurance company for the 5 minutes he spent, instead he associates it to a billable service with a preset fee.  That approach allows him to be there for me when I need him.

In our IT world, individual projects are bound by unrealistic expectations from clients. Referring back to all the sound advice and training available from the above referenced sites, and from PMI, we know that project plans, which incorporate the boundaries of cost, quality, and schedule, must consider everything that is required to deliver an entire solution, not just the individual point in time that an engineer is writing a specific line of code. For example, that line of code, in order to be correct, must be written with an appropriate technology, within an architected solution that is secure, accessible, reliable, tested, and maintainable. Those adjectives are not free.  They are in place because of hard work, training, and process.

The pillars of cost, quality, and schedule are non-negotiable once established. If a project fails, it failed because one or more of these three pillars cracked, or crumbled. Establishing them correctly up front will significantly reduce the opportunity for them to bear pressure during a project. Establishing them correctly requires that we manage expectations that include the teachings from PMI and from the lessons learned in the industry.

In summary, we need to plan for things like validation of requirements with stakeholders. We need to plan for things like training, performance testing, failover, risk management, system documentation, traceability… I could go on. My larger picture argument is that I hope that someday we’ll take this approach as an industry rather than as individual service providers.  We should be differentiated by our ability to deliver rather than win business based on our ability to negotiate ourselves into low cost and inadequate delivery.

Set the pillars in place, build the plan based on the pillars, and deliver to the plan.

Please, share your thoughts and opinions on this topic and let’s see where the dialogue takes us.