Friday, November 22, 2024

Can Acquisition be Agile? 7 Steps for Agile Buying

By Brian Reynolds, published in the Summer 2016 FedHealthIT Magazine

Some aspects of complex IT solutions are unknowable and can’t be predicted or planned up-front.

Uncertainty requires agility. Where uncertainty is high, a learning system based on iteration and feedback is required. Agile methodologies provide such a system. Teams that adopt these techniques focus on delivering value, improving quality, and using feedback to ensure products are fit-for-purpose.

Acquisition practices require the same Lean Thinking. Unfortunately, many Government acquisition practices assume scope can be completely defined up-front, when we know the least; that priorities will not change significantly; that innovation can be completed on a predictable schedule; and that all required program expertise can be sourced from a single vendor.

These practices often undermine Agile delivery methods; make it difficult for Government to apply price and performance pressure throughout the lifecycle; require bureaucratic change control processes; and make separating underperforming vendors difficult and disruptive.

Congress’ calendar is rife with bills that promise to reform Federal acquisition laws and regulations to accommodate Agile delivery techniques. But current law already allows for adaption of Agile, even encouraging it in some places. There are seven steps Government can take to adapt existing acquisition practices to support Agile delivery techniques and deliver more value, faster.

Step 1. Use Modular Architecture.

Use modular architecture to define smaller, less risky, more manageable product boundaries that limit dependency on individual vendors, and enable modular acquisition. Shift the role of architecture – from a product development deliverable, produced after product development contract award, to a product architecture and planning deliverable, developed in advance and used to segregate and drive specialized product development contract actions.

Step 2. Segregate Service Requirements.

Most vendors do not have best-in-class competencies that align with all services needed to deliver a complex program. Segregate service requirements to engage specialists to deliver discrete services. Separate architecture and integration services from product development, so that specialists can be engaged to develop discrete products (components) within the architecture.

Step 3. Use Multi-Award Indefinite Delivery Vehicles (IDVs).

Use IDVs to establish a pool or pre-qualified product development vendors so agencies can quickly and conveniently engage competent, qualified, and price competitive service providers to deliver products (within the modular architecture). This provides the flexibility to contract product development services on a release basis and to switch to a new vendor within the IDV pool without significant disruption.

Step 4. Use Streamlined Vendor Selection Procedures.

Use competency, past performance, and rate card evaluations to qualify vendors for admittance to the IDV pool. Select vendors and acquire product development services from the IDV pool by applying streamlined vendor selection procedures that heavily favor competitive prototyping and agency past performance.

Step 5. Base CLINS on Release Plans.

Product Development contracts should be based on a Performance Management Baseline (PMB) that includes a schedule, budget, and technical baselines. A properly defined Agile Release Plan includes each of these components. Use Release-Plans to incrementally contract for product development services and as the basis for defining task order CLINs around mutually approved technical, cost, and schedule baselines.

Step 6. Tie Payments to Working Software.

Contract performance measurement and payment schedules should be focused on what is most important: delivery of high quality software. This is best accomplished when deliverables are defined as working, high-quality software features. Directly tie payments to acceptance of software features. Use the release planning process to define a fixed price payment continuum for delivery of in-scope features and stories.

Step 7. Continuously Measure and Improve.

Use vendor management and rigorous inspect and adapt metrics to drive continuous performance improvements and to monitor vendor performance and progress. Metrics provide early warning signs about vendor performance and the need for preemptive improvements. They also provide a quantitative basis for electing to source delivery of future releases through an alternative vendor and for negotiating performance-based release development CLINs.

These steps comply with federal law and the Federal Acquisition Regulation. But to ensure success, agencies will need a capable team of acquisition professionals. Reports show dwindling experience among procurement practitioners across Government. If benefits of Agile are going to be released any time soon, Government should redouble efforts to prepare buying workforce now.

reynolds_brianAbout the Author: Brian Reynolds is a Principal at Grant Thornton LLP, where he leads the Firm’s public sector Agile and Digital Delivery Service. He helps Federal healthcare and other industry teams use Agile to deliver value, faster. Brian can be reached at brian.reynolds@us.gt.com.

[related-post]

LEAVE A REPLY

Please enter your comment!
Please enter your name here

FedHealthIT Xtra – Find Out More!

Recent News

Don’t Miss A Thing

Subscribe to our mailing list

* indicates required