"Without [scope creep], IT's relevancy comes into question. With it comes the adoption of any new deliverable." This quote, from "Coverlet Meshing", in Information Week Global CIO, holds deep meaning for anyone in IT. Though the author is a financial services professional, I firmly believe that, when compared to other industries, government technology projects are far more likely to a) fail, b) do not deliver, and/or c) exceed budget and miss deadlines.
There's a good reason for all this, though. When a government technology project is launched, the timeframe involved is considerably lengthy:
|Investigate business requirements||6 months|
|Assess feasibility||3 months|
|Investigate technology requirements||3 months|
|Write/develop RFP||3 months (conservatively)|
|Run through procurement process||3 months (conservatively)|
|Award and contract negotiation||3 months|
|Project planning/requirements review||3-6 months|
So, at a minimum it takes an estimated two years before a project even gets rolling. Then, most project plans span two years-plus, incorporating review cycles, holidays and vacations. So, let’s fathom a guess at what can happen in a four-year timeframe in government? Elections? Unplanned events? Natural disasters? Retirements? Promotions? Technology advancement? New legislation? Any and all of these things can – and will – happen.
Government needs to be able to make changes to systems continually. The common thread among all of the reasons for failed technology projects is that they take too long to complete and cannot effectively respond to the rapid pace of change agencies face. The trick is to anticipate change from the beginning.
In my new e-book, “Why Government Technology Projects Fail”, I explore not only the primary reasons these projects fail, and how this pitfalls can be avoided; I show how agencies can build more agile systems. In other words, I offer an alternative approach to ensure that scope creep can absolutely be mandatory.