– Overpromise and Underdeliver?

Information Technology Projects

Why do we consistently promise too much and then fail to deliver on information technology and other government projects?

The project mantra is clear: “scope, schedule, budget”. But how we actually do the planning, estimating and getting approval to start a project … well that’s the horse of a different color.

We promise the moon – “Project Widget will be the best thing for this department since sliced bread – it not only will slice bread, but will knead the dough and grow the yeast and self-bake itself”. Then, of course, instead of delivering sliced bread we might end up delivering half-a-loaf, or maybe an electric knife or perhaps a chopped salad. This problem: getting the project’s scope right.

Then there is schedule. Of course every project is a “priority”. We’re going to get it done in the “next nine months”. Why “nine” months? Because that’s less than a calendar and budget year, but it is longer than saying it will be done tomorrow, which is patently ludicrous. But nine months is also ludicrous for anything other than incubating a baby – and even babies usually take years of planning and preparation. Furthermore, in the public sector almost every procurement has to be done by RFP, and preparing a request for proposals alone, plus contract negotiations with a successful vendor, cannot be done in less than a year. And the schedule needs to include minor components such as business process discovery and the work of executing on the project.

Then there’s budget. Generally we’ll make a pretty good estimate of the actual real cost of the project. The usual mistake is for someone (fill-in-the-blank – “department director”, “Mayor”, “county commissioner”, “state legislator”, “grand phooba”) to say “we only have x number of dollars”. So, as the next step, the project budget shrinks to the magic budget number, while scope and schedule are left unchanged. And generally the “magic budget number” is determined by some highly scientific means such as the amount of money left over in a department budget at the end of a fiscal year, or the amount of money the City of Podunk Center spent on a similar project, or the size of a property tax increase which voters might be reasonably persuaded to pass.

Why do we plan projects this way in the public sector?

First, we are largely transparent and accountable in government. That’s really good news, because we – government – are stewards of taxpayer and ratepayer money. Oh, I suppose we can hide some small boondoggles, but there are too many whisteblowers and too much media scrutiny to hide a major failure. That’s not true in the private sector, where projects costing tens or hundreds of millions of dollars are failures or near failures, often hidden from public or shareholder view, with wide-ranging and sometimes near catastrophic economic effects. Some public examples include Boeing’s 787 Dreamliner or the Microsoft Courier tablet (gee, will anyone every produce a Windows tablet?) The federal government’s project failures are paramount examples of both poor project planning/execution and admirable transparency with an eye to reform.

Here are my top reasons for project mis-estimation:

• Lack of rigorous project management. Project managers are crucial. But good project managers are also expensive. Government doesn’t grow or pay PMs well. Too often we assign project managers as the “last man standing” – whoever is left over when everyone else is doing the work. And we are woefully short on training – usually training and education are the first things cut from public budgets during recessions.
• Eagerness to please. Everyone in a project is eager to please a boss – the County Executive, the Governor, a legislator, a department director. How often do we invoke “the Governor is really interested in … (fill in the blank related to the current project)”. Projects need to stand on their own for business value, as well as be of interest to the elected official presently in office.
• Jadedness. Knowing the budget process described above, we’ll often pad estimates – make the budget larger and the schedule longer, knowing they will be cut. Then, of course, decision-makers and leaders can also play that game, figuring there is padding, and therefore cut all the deeper.
• The constraints of the budget and election cycles. Typical budget cycles in government are one year. Election cycles can be two years, and at most four years. Unless elected officials and department directors really take a long-range view, these facts lead to short-range think and results, just as stock price and quarterly profits drive the private sector.

And here are my top cures:

• Hiring professional project managers. Frankly, this means, for large projects, we should usually hire professional PMs or firms from outside government. As a side benefit, such outside firms can also help train, mentor and grow government employees so they become good PMs.
• Good executive sponsorship. The executive sponsor for a project needs to be the government official with “skin in the game” – the owner of the “business”, whose job may be on the line if the project fails, as well as the official owning the business. A smartgrid project’s sponsor will be the electrical utility’s director of distribution and generation networks. A computer-aided dispatch system’s sponsor will be the Assistant Fire or Police Chief in charge of the 911 center and dispatch.
• External quality assurance. QA is essentially a “watchdog” on projects, speaking truth to power, and highlighting areas of risk and opportunities for improvement as the project proceeds.
• Small projects and quick wins. If possible, any large project should really be a series of small projects with quick wins. In the case of a computer-aided dispatch system, for example, the smaller projects could include installing computers in police vehicles, implementing automated vehicle location, implementing a records management system, and implementing the CAD software itself. Of course there is no way to build a sewage treatment plant serving a city of half-a-million as a series of small projects, but most IT projects can be decomposed.
• Transparency. Perhaps the most important component is openness and honesty for everyone involved – project managers being honest with sponsors, technical staff being honest about their workloads, department directors looking at their portfolio of projects and putting the lower priority ones on hold so the higher priority ones have the resources for success. The federal government leads the way in transparency, with its public “dashboard” for information technology spending and projects.

What’s amazing is that, despite everything I’ve said above, we get an amazing amount of great projects completed. At the City of Seattle, we’ve tracked all our major projects. Since 2006, we’ve tracked 77 project through 2,071 project dashboard reports. We’ve found that, when they are completed, 75% of them are within budget. Of those 77 projects, 32% have been on time and 57% have delivered the scope they promised (i.e. a whole loaf of sliced bread). Clearly this record reflects our priorities – budget is the most important consideration, with scope second, and schedule lowest.

Not a bad record when compared with Standish group project failure statistics, but plenty of room for improvement.