Skip to Main Content

blogpost

Procuring agile vs.
non-agile
projects in five stages: An overview

By:

Jessica Dill is a consultant in BerryDunn’s Government Consulting Group based in our Phoenix office, focusing on state government clients primarily in the Health and Human Services sector. Jessica provides project management and business analysis support to various client projects including options analysis, system planning and procurement.

Jessica Dill,

Naomi Snodgrass has been helping governmental organizations plan for and procure technology solutions for programs for state and local health and human services. She has supported and led all phases in the procurement cycle from strategizing and defining needs to contract management once a solution is implemented. She is based in BerryDunn’s Phoenix office where she provides services as a Senior Consultant in our State Health and Human Services practice.

Naomi Snodgrass
05.30.19

Editor’s note: If you are a state government CFO, CIO, project or program manager, this blog is for you.

What is the difference in how government organizations procure agile vs. non-agile information technology (IT) services? (Learn more about agile here).

In each case, they typically follow five stages through the process as shown in Figure A:
 

Figure A: Overview of Procurement Process for Agile vs. Non-Agile IT Services

However, there are differences in how these stages are carried out if procuring agile vs. non-agile IT services. 

Unfortunately, most government organizations are unaware of these differences, which could result in unsuccessful procurements and ultimately not meeting your project’s needs and expectations. 
This blog series will illustrate how to strategically adjust the standard stages outlined in Figure A to successfully procure agile IT services.

Stage 1: Plan project
In Stage 1, you define the scope of the project by identifying what your organization wants, needs, and can achieve within the available timeframe and budget. You then determine the project’s objectives while strategically considering their impact on your organization before developing the RFP. Figure B summarizes the key differences between the impacts of agile vs. non-agile services to consider in this stage.


Figure B: Plan Project for Agile vs. Non-Agile IT Services

The nuances of planning for agile services reflect an organization’s readiness for a culture shift to a continuous process of development and deployment of software and system updates. 

Stage 2: Draft RFP
In Stage 2, as part of RFP drafting, define the necessary enhancements and functionality needed to achieve the project objectives determined in Stage 1. You then translate these enhancements and functionalities into business requirements. Requirement types might include business needs as functionality, services, staffing, deliverables, technology, and performance standards. Figure C summarizes the key differences between drafting the RFP for a project procuring agile vs. non-agile services.


Figure C: Draft RFP for Agile vs. Non-Agile IT Services

In drafting the RFP, the scope of work emphasizes expectations for how your team and the vendor team will work together, the terms of how progress will be monitored, and the description of requirements for agile tools and methods.

Stage 3: Issue RFP
In Stage 3, issue the RFP to the vendor community, answer vendor questions, post amendments, and manage the procurement schedule. Since this stage of the process requires you to comply with your organization’s purchasing and procurement rules, Figure D illustrates very little difference between issuing an RFP for a project procuring agile or non-agile services.


Figure D: Issue RFP for Agile vs. Non-Agile IT Services 

Stage 4: Review proposals
In Stage 4, you evaluate vendor proposals against the RFP’s requirements and project objectives to determine the best proposal response. Figure E summarizes the key differences in reviewing proposals for a project that is procuring agile vs. non-agile services.


Figure E: Reviewing Proposals for Agile vs. Non-Agile IT Services 

Having appropriate evaluation priorities and scoring weights that align with how agile services are delivered should not be under-emphasized. 

Stage 5: Award and implement contract
In Stage 5, you award and implement the contract with the best vendor proposal identified during Stage 4. Figure F summarizes the key differences in awarding and implementing the contract for agile vs. non-agile services.



Figure F:  Award and Implement Contract for Agile vs. Non-Agile Services 

Due to the iterative and interactive requirements of agile, it is necessary to have robust and frequent collaboration among program teams, executives, sponsors, and the vendor to succeed in your agile project delivery.

What’s next?
The blog posts in this series will explain step-by-step how to procure agile services through the five stages, and at the series conclusion, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.  

Related Professionals

As your organization works to modernize and improve your Medicaid Enterprise System (MES), are you using independent verification and validation (IV&V) to your advantage? Does your relationship with your IV&V provider help you identify high-risk project areas early, or provide you with an objective view of the progress and quality of your MES modernization initiative? Maybe your experience hasn’t shown you the benefits of IV&V. 

If so, as CMS focuses on quality outcomes, there may be opportunities for you to leverage IV&V in a way that can help advance your MES to increase the likelihood of desired outcomes for your clients. 

According to 45 Code of Federal Regulations (CFR) § 95.626, IV&V may be required for Advanced Planning Document (APD) projects that meet specific criteria. That said, what is the intended role and benefit of IV&V? 

To begin, let’s look at the meaning of “verification” and “validation.” The Institute of Electrical and Electronics Engineers, Inc. (IEEE) Standard for Software Verification and Validation (1012-1998) defines verification as, “confirmation of objective evidence that the particular requirements for a specific intended use are fulfilled.” Validation is “confirmation of objective evidence that specified requirements have been fulfilled.” 

Simply put, verification and validation ensure the right product is built, and the product is built right. 
As an independent third party, IV&V should not be influenced by any vendor or software application. This objectivity means IV&V’s perspective is focused on benefiting your organization. This support includes: 

  • Project management processes and best practices support to help increase probability of project success
  • Collaboration with you, your vendors, and stakeholders to help foster a positive and efficient environment for team members to interact 
  • Early identification of high-risk project areas to minimize impact to schedule, cost, quality, and scope 
  • Objective examination of project health in order for project sponsors, including the federal government, to address project issues
  • Impartial analysis of project health that allows state management to make informed decisions 
  • Unbiased visibility into the progress and quality of the project effort to increase customer satisfaction and reduce the risk and cost of rework
  • Reduction of errors in delivered products to help increase productivity of staff, resulting in a more efficient MES 

Based on our experience, when a trusted relationship exists between state governments and IV&V, an open, collaborative dialogue of project challenges—in a non-threatening manner—allows for early resolution of risks. This leads to improved quality of MES outcomes.    

Is your IV&V provider helping you advance the quality of your MES? Contact our team.

Blog
Leveraging IV&V to achieve quality outcomes

Truly effective preventive health interventions require starting early, as evidenced by the large body of research and the growing federal focus on the role of Medicaid in addressing Social Determinants of Health (SDoH) and Adverse Childhood Experiences (ACEs).

Focusing on early identification of SDoH and ACEs, CMS recently announced its Integrated Care for Kids (InCK) model and will release the related Notice of Funding Opportunity this fall.

CMS describes InCK as a child-centered approach that uses community-based service delivery and alternative payment models (APMs) to improve and expand early identification, prevention, and treatment of priority health concerns, including behavioral health issues. The model’s goals are to improve child health, reduce avoidable inpatient stays and out-of-home placement, and create sustainable APMs. Such APMs would align payment with care quality and support provider/payer accountability for improved child health outcomes by using care coordination, case management, and mobile crisis response and stabilization services.

State Medicaid agencies have many things to consider when evaluating this funding opportunity. Building on current efforts and innovations, building or leveraging strong partnerships with community organizations, incentivizing evidence-based interventions, and creating risk stratification of the target population are critical parts of the InCK model. Here are three additional areas to consider:

1. Data. States will need information for early identification of children in the target population. State agencies?like housing, justice, child welfare, education, and public health have this information?and external organizations—such as childcare, faith-based, and recreation groups—are also good sources of early identification. It is immensely complicated to access data from these disparate sources. State Medicaid agencies will be required to support local implementation by providing population-level data for the targeted geographic service area.

  • Data collection challenges include a lack of standardized measures for SDoH and ACEs, common data field definitions, or consistent approaches to data classification; security and privacy of protected health information; and IT development costs.
  • Data-sharing agreements with internal and external sources will be critical for state Medicaid agencies to develop, while remaining mindful of protected health information regulations.
  • Once data-sharing agreements are in place, these disparate data sources, with differing file structures and nomenclature, will require integration. The integrated data must then be able to identify and risk-stratify the target population.

For any evaluative approach or any APM to be effective, clear quality and outcome measures must be developed and adopted across all relevant partner organizations.

2. Eligibility. Reliable, integrated eligibility and enrollment systems are crucial points of identification and make it easier to connect to needed services.

  • Applicants for one-benefit programs should be screened for eligibility for all programs they may need to achieve positive health outcomes.
  • Any agency at which potential beneficiaries appear should also have enrollment capability, so it is easier to access services.

3. Payment models. State Medicaid agencies may cover case management services and/or targeted case management as well as health homes; leverage Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) services; and modify managed care organization contract language to encourage, incent, and in some cases, require services related to the InCK model and SDoH. Value-based payment models, already under exploration in numerous states, include four basic approaches:

  • Pay for performance—provider payments are tied directly to specific quality or efficiency indicators, including health outcomes under the provider organization’s control. 
  • Shared savings/risk—some portion of the organization’s compensation depends on the managed care entity achieving cost savings for the targeted patient population, while realizing specific health outcomes or quality improvement.
  • Pay for success—payment is dependent upon achieving desired outcomes rather than underlying services.
  • Capitated or bundled payments—managed care entities pay an upfront per member per month lump sum payment to an organization for community care coordination activities and link that with fee-for-service reimbursement for delivering value-added services.

By focusing on upstream prevention, comprehensive service delivery, and alternative payment models, the InCK model is a promising vehicle to positively impact children’s health. Though its components require significant thought, strategy, coordination, and commitment from state Medicaid agencies and partners, there are early innovators providing helpful examples and entities with vast Section 1115 waiver development and Medicaid innovation experience available to assist.

As state Medicaid agencies develop and implement primary and secondary prevention, cost savings can be achieved while meaningful improvements are made in children’s lives.

Blog
Three factors state medicaid agencies should consider when applying for InCK funding

Over the course of its day-to-day operations, every organization acquires, stores, and transmits Protected Health Information (PHI), including names, email addresses, phone numbers, account numbers, and social security numbers.

Yet the security of each organization’s PHI varies dramatically, as does its need for compliance with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Organizations that meet the definition of a covered entity or business associate under HIPAA must comply with requirements to protect the privacy and security of health information.

Noncompliance can have devastating consequences for an organization, including:

  • Civil violations, with fines ranging from $100 to $50,000 per violation
  • Criminal penalties, with fines ranging from around $50,000 to $250,000, plus imprisonment

All it takes is just one security or privacy breach. As breaches of all kinds continue to rise, this may be the perfect time to evaluate the health of your organization’s HIPAA compliance. To keep in compliance and minimize your risk of a breach, your organization should have:

  • An up-to-date and comprehensive HIPAA security and privacy plan
  • Comprehensive HIPAA training for employees
  • Staff who are aware of all PHI categories
  • Sufficiently encrypted devices and strong password policies

HIPAA Health Check: A Thorough Diagnosis

If your organization doesn’t have these safeguards in place, it’s time to start preparing for the worst — and undergo a HIPAA health check.

Organizations need to understand what they have in place, and where they need to bolster their practice. Here are a variety of fact-finding methods and tools we recommend, including (but not limited to):

  • Administrative, technical, and physical risk analyses
  • Policy, procedure, and business documentation reviews
  • Staff surveys and interviews
  • IT audits and testing of data security

Once you have diagnosed your organization’s “as-is” status, you need to move your organization toward the “to-be” status — that is, toward HIPAA compliance — by:

  • Prioritizing your HIPAA security and privacy risks
  • Developing tactics to mitigate those risks
  • Providing tools and tactics for security and privacy breach prevention and minimization
  • Creating or updating policies, procedures, and business documents, including a HIPAA security and privacy plan

As each organization is different, there are many factors to consider as you go through these processes, and customize your approach to the HIPAA-compliance needs of your organization.

The Road to Wellness

An ounce of prevention is worth a pound of cure. Don’t let a security or privacy breach jump-start the compliance process. Reach out to us for a HIPAA health check. Contact us if you have any questions on how to get your organization on the road to wellness.

Blog
How healthy is your organization's HIPAA compliance?

A year ago, CMS released the Medicaid Enterprise Certification Toolkit (MECT) 2.1: a new Medicaid Management Information Systems (MMIS) Certification approach that aligns milestone reviews with the systems development life cycle (SDLC) to provide feedback at key points throughout design, development, and implementation (DDI).

The MECT (recently updated to version 2.2) incorporates lessons learned from pilot certifications in several states, including the successful West Virginia pilot that BerryDunn supported. MECT updates have a direct impact on E&E systems—an impact that may increase in the near future. Here is what you need to know:         

Then: Initial Release

In February 2017, CMS introduced six Eligibility & Enrollment (E&E) checklists. Five were leveraged from the MECT, while the sixth checklist contained unique E&E system functionality criteria and provided a new E&E SDLC that—like the MECT—depicted three milestone reviews and increased the Independent Verification and Validation (IV&V) vendor’s involvement in the checklists completion process.

Now: Getting Started

Completing the E&E checklists will help states ensure the integrity of their E&E systems and help CMS guide future funding. This exercise is no easy task, particularly when a project is already in progress. Completion of the E&E checklists involves many stakeholders, including:

  • The state (likely more than one agency)
  • CMS
  • IV&V
  • Project Management Office (PMO)
  • System vendor(s)

As with any new processes, there are challenges with E&E checklists completion. Some early challenges include:

  • Completing the E&E checklists with limited state project resources
  • Determining applicable criteria for E&E systems, especially for checklists shared with the MMIS
  • Identifying and collecting evidence for iterative projects where criteria may not fall cleanly into one milestone review phase
  • Completing the E&E checklists with limited state project resources
  • Working with the system vendor(s) to produce evidence

What’s Next?

Additionally, working with system vendors may prove tricky for projects that already have contracts with E&E vendors, as E&E systems are not currently subject to certification (unlike the MMIS). This may lead to instances where E&E vendors are not contractually obligated to provide the evidence that would best satisfy CMS criteria. To handle this and other challenges, states should communicate risks and issues to CMS and work together to resolve or mitigate them.

As CMS partners with states to implement the E&E checklists, some questions are expected to be asked. For example, how much information can be leveraged from the MECT, and how much of the checklists completion process must be E&E-specific? Might certification be required in the near future for E&E systems?

While there will be more to learn and challenges to overcome, the first states completing the E&E checklists have an opportunity to lead the way on working with CMS to successfully build and implement E&E systems that benefit all stakeholders.

On July 31, 2017, CMS released the MECT 2.2 as an update to the MECT 2.1.1. As the recent changes continue to be analyzed, what will the impact be to current and future MMIS and E&E projects?

Check back here at BerryDunn Briefings in the coming weeks and we will help you sort it out.

Blog
Check this: CMS checklists aren't just for MMIS anymore.

This site uses cookies to provide you with an improved user experience. By using this site you consent to the use of cookies. Please read our Privacy Policy for more information on the cookies we use and how you can manage them.