I saw an interesting story on the news today. Jason Wheeler from my local TV station did a story on “Texas Taxpayers Paying Millions More Than Planned For Computer Upgrades.” Great story Jason!
He brought out some interesting facts about the state’s IT projects:
“…many of those IT projects ran millions of dollars over budget. The pattern became so glaring that the State Auditor’s Office just issued a scathing 33 page report. …Of the projects reviewed by the auditor, 67 percent went beyond their estimated completion deadlines and 73 percent went over budget.”
I happen to agree with Karen Robinson, Executive Director of the Texas Department of Information Resources when she states that this is not unique to Texas and “Major IT project management remains a national challenge”.
If you have not worked on government projects (At any level – local, state or federal) then you might not understand some of the rules and contract vehicles that can lead to project failures. I have been called in many times in my career to “turn around” failed government projects. I have seen several patterns over the years that contribute to failed projects. (My definition of a failed project is when either cost, schedule or quality are far out of bounds from the original estimates.
The first pattern I have seen is what I call the “process” of doing procurement. This process is partly to blame for failed projects. The standard procurement process has not changed significantly in over a decade and has some severe limitations in how it sets the vendor and the government up for failure. The basic process is:
- A government agency advertises some type of Request for Proposal (RFP), a Statement of Work (SOW) and some guidelines for proposing
- Bidders are then allowed to ask questions and receive answers
- The agency then receives the proposals
- Through some set of criteria they determine the winner
While this process may seem straight forward and fair, it actually leads to poor requirements and too low a cost. The problem is that when the process leads to driving cost as the primary factor and not quality or flexibility then we get poor project performance and scope dis-agreements. In turn – these lead to problems in cost and schedule.
Because the procurement process assumes that the government knows exactly what they want, that is exactly what the companies propose. Where is the innovation in that? If the project is large and will take many months (or years), how could an SOW possibly accommodate the technology or process changes that are needed in advance?
And with the scrutiny that is placed on the procurement shops, they try to make all procurements just a “commodity” purchase. This makes it easier and takes away any chance of a challenge to the process. So here is my beef – how can you make developing a solution or system with people a commodity? That is like saying I want to hire a painter to paint a picture of a horse and there is little difference in the talent or end product that the painters will propose. Those of us who have been PMs for many years know that any 2 companies can propose on a project two different solutions that appear to give the government the some product. And if the process says that both solutions will yield the same product then price is the final determinant. And there starts the problem.
Ann All wrote a wonderful post on the subject and stated that “Government procurement appears to be a broken process, one in which agencies hamstring even their usual vendors from suggesting different ways of solving problems or achieving goals.”
The second pattern of problems I have seen is in project cost estimating. I wrote another post on that last year (Planning and Estimating Government projects) where I talk about how both government and corporate management want a “low cost” solution.
The third pattern I see in government projects is the lack of collaboration. After the contract is awarded you would assume that all parties (Users, PM, vendors, stakeholders) know exactly what is supposed to be delivered. Wrong – have you ever seen some of the 500 or more page proposals that the government receives? I have often thought that no human could understand what is supposed to be delivered on one of these huge IT projects. In my opinion, too often the lack of communication and collaboration between clients and vendors is the leading cause of project failure. The government wants exactly what the SOW and proposal stated even if there is a better solution and the vendor wants to only deliver the minimally acceptable solution in order to make money on a low-balled estimate. I would love to see procurement try some collaborative contract vehicles. Make the project a teaming agreement with the outcome of the project being aligned with the outcomes desired.
What if an IT system project had the structure and basic outcomes of the project defined but set aside the details of the user interface or process as a bounded effort to be defined? Kind of like building a house where you are given a budget for the floors, lights, paint, etc. You know the basic layout of the house, but can choose the details as you go along. I guess this would equate to more of an Agile type project – and that seems to be very hard for the government to do.
Have you worked on a government project? What do you think – can we improve the success rate of government projects?
Some interesting posts on the same subject:
Why do projects fail? – A government discussion board
Good facts on why Technology Projects Fail from Calleam Consulting
Agile will fail in Government IT projects (I dont agree with this one! But he has some good points)
August 16, 2012 at 6:24 am
You’re right Bruce. As long as Governments keep loving “dear costs” ignoring “doable costs” I don’t think we can expect “kills” from stretching projects. Yah! the procurement process they follow, vendor selection strategy they believe-in need much debate so as to tailor them for changing business perspectives (or ethics,sometimes). Indeed managing a Govt project is a global challenge and the plagues are all prevalent. As a mid level PM I foresee good many thought igniters from PM Gurus 🙂
August 23, 2012 at 4:48 am
I like the link you provided to the article about how Agile will fail in government IT projects as I posted a blog on Gantthead about the FBI “Sentinel” project to electronically manage their cases which when switching over to Agile, finished 80% of the work with 10% of the budget when switching from their horrendously mismanaged waterfall process just as you outlined.
Here’s the blog: http://www.gantthead.com/blog/Agility-and-Project-Leadership/5742/
August 24, 2012 at 11:39 am
[…] Why do Government Projects continue to fail? PartilharTwitterFacebookLinkedInTumblrEmailGostar disto:GostoBe the first to like this. […]
September 14, 2012 at 8:37 am
That’s just the problems with the procurement process. Once the contract is signed then specification creep & budget changes occur & have to be managed.
I think that the fundamental problem is that government & commercial processes are different. If I have a product then I will be desperate to get version 1 out of the door asap in order to establish market visibility. Version 2 will be in development as V1 hits the streets & I’ll have a pretty good idea of what I want in V3.
Governments (i.e. our elected representatives) want to buy a solution only once so that they can put a tick in a box, therefore EVERYTHING goes into the spec. They don’t want to pay again, as they would see it, for V2. As noted above, given the scale of some of these projects, no one can understand the whole thing, nor can the the specification be tested for completeness. So creep sets in, in the rigid world of government that is hard to manage.
Solution – more work on design – not planning or project management. i.e. Make sure about what is needed, both now & later. But that again is not what government is good at.
That’s just my view from 25yrs working in the UK public sector.
August 21, 2013 at 5:07 pm
Can I suggest a related resource? Why Projects Fail is an in-depth book containing suggestions and recommendations regarding failed projects, case studies and analysis.
January 12, 2014 at 10:11 pm
[…] 2. Lack of risk management/poor quality control. Example: Texas State IT Project […]