August 21, 2010 at 5:30 pm #108786
According to a recent article in Fierce Government IT discusses a new model for acquiring technology at DoD, which requires adaptability, flexibility, and increasing end-user involvement.The new acquisition process, mandated by Sec. 804 of the fiscal 2010 National Defense Authorization Act (H.R. 2647, now Public Law No: 111-84) is being adopted, according to Patrick Wills, associate academic dean of Executive Programs, Defense Acquisition University. Sec. 804 is based on Chapter 6 of a March 2009 report (.pdf) from the Defense Science Board. The acquisition process, the report says, “should be agile and geared to delivering meaningful increments of capability in approximately 18 months or less–increments that are prioritized based on need and technical readiness.
The new process design is to include:
- Early and continual involvement of the user;
- multiple, rapidly executed increments or releases of capability;
- early, successive prototyping supporting an evolutionary approach; and
- a modular, open-systems approach.
Can this model succeed? Is it possible to adapt this model across government for all technology acquisitions? What cultural or resource barriers may be present?Has anyone had success implementing technology similar to these approaches that DoD wants to implement?
August 22, 2010 at 5:46 pm #108804
Great concept…hard part is moving to implementation
August 23, 2010 at 12:46 am #108802
Implementation will take years unfortunately. Perhaps if this where done on smaller projects as pilots to show proof of concept.
August 26, 2010 at 11:42 am #108800
Probably won’t have a great deal of success until program managers buy in to the concept (and lip service is NOT going to cut it!)
August 26, 2010 at 12:22 pm #108798
Wholesale cultural change is necessary, beginning with leadership and going down to the program manager who is ultimately responsible for delivery. Everyone has to buy into the concept, which is why I think proof of concept is important to help break those barriers and show how it can be done successfully.
August 26, 2010 at 1:15 pm #108796
Yes, we are doing this now!
One of the most successful IT development programs the VA has had in a long time is the current GI Bill (education benefits, called Chapter 33) that has been lead by SPAWAR (Navy system integrators). I investigated this successful work (and ones that that don’t work) and found that a key to the SPAWAR project is the disciplining framework defined by a small company called SPARC LLC, service-disabled veteran owned too! It turns out that they are combining the “agile development” model with the PASS framework for organizational recursive analysis (one I wrote, which was cool to find out). So, as far as I can tell, DoD is following this model and it is benefiting the VA. Since we have 15 more intiatives set by our Secretary, I assume this same team will take a lead in brining the successful discipline to other projects too.
If you want to read more about the PASS framework, you can find copies at http://slidesha.re/9718hp
In my opinion, and from my study of projects’ root causes of success and failure, I would say it is the lack of a disiciplining framework in the acquistion package – to ensure compliance to rigorous methodologies! If the contract doesn’t specific the rigor of methods, then you get the chaos you paid for.
August 26, 2010 at 1:34 pm #108794
Thanks for the great post and the link. I’ll check it out. As you state, requirements development is critical to successful outcomes for any procurement. Glad to see some success in your organization, in addition to your efforts paying off.
August 26, 2010 at 5:19 pm #108792
August 26, 2010 at 7:48 pm #108790
Training will indeed be vital to demonstrate both how effective these programs can be, but also best practices and methodologies for successful implementation and execution.
August 30, 2010 at 6:04 pm #108788
David (1) any connection between this and the VA’s PMAS process and (2) are there different processes (requirements, reporting, development, assessment, etc.) for the processes impacted by delivered hardware or software, as distinct from how hardware or software are evaluated?
You must be logged in to reply to this topic.