A few months ago I was referred to the recently published plan to reform the US Federal Information
A few months ago I was referred to the recently published plan to reform the US Federal Information Technology Management. You can read it at:www.cio.gov I found it quite revealing of the needs for change not just in the US Government, but probably in many large organizations.
The study points out that in the last decade, and even after investing more than $600 billion, the US Federal Government is still facing quality and productivity issues. Research has shown that many projects have become obsolete even before being deployed. To some degree, this is not surprising. Big budgets exist because issues are large and complex and involve a myriad of entities and interests. On the other hand, business needs change fast, and technology, faster. So how do you tackle an issue involving many intricate interactions and huge amounts data, when those issues and the technology available to solve them change constantly?
Much of the strategy the plan proposes is related to reducing asset investment and redundancy, by relying on cloud services that can be accessed by many different agencies. Other plan components call for human resources skills improvement in program management and procuring. The component that called my attention had to do with software development.
The language used to describe how a project should be implemented is very familiar to us:
•“… in release cycles no longer than 12 months, and, ideally less than six months, with initial deployment to end users no later than 18 months after the program begins.”
•“…with no more than 3 months dedicated to creating detailed system specifications”
•“Moving resources from one release phase to the next as soon as they complete their work (e.g. the requirements team builds requirements for the next release, while developers build the current release).”
The modular approach the plan puts forward is well known to many of us. It’s a good and much needed step towards being more responsive and productive. It will not be easy to implement. Large agencies are used to the long release cycles so many procurement and project management processes will need updating. So are vendors!
Is this a prelude to a wider introduction of agile project management in the US Federal Government? Will more corporations follow suit? I guess it is hard to say at this point. Furthermore, is agile the best approach for these organizations? Without attempting to answer that question, a couple of things come to mind. First: if I were to think about how to introduce agile, a good way could probably be by moving from a traditional waterfall life cycle to an iterative and incremental model first. Second: it would be nice to be able to go agile when the solution requires it. I would not suggest using agile as a “one size fits all” solution, but having it in the arsenal as an alternative would certainly be useful.Go Back