Fear No Project Blog – Focusing on the Management Side of Projects

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:

1. A government agency advertises some type of Request for Proposal (RFP), a Statement of Work (SOW) and some guidelines for proposing
2. Bidders are then allowed to ask questions and receive answers
3. The agency then receives the proposals
4.  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:

http://www.arraspeople.co.uk/camel-blog/projectmanagement/so-why-do-many-government-it-projects-fail/

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)