Youth engagement in child welfare: Supporting the transition to adulthood

There’s a good chance that your organization is in the position of needing to do more with less under the strain of staffing constraints and competing initiatives. With fewer resources to work with, you’ll need to be persuasive to get the green light on new enterprise technology initiatives. To do that, you need to present decision makers with well-thought-out and targeted business cases that show your initiative will have impact and will be successful. Yet developing such a business case is no walk in the park. Perhaps because our firm has its roots in New England, we sometimes compare this process to leading a hiking trip into the woods—into the wild. 

Just as in hiking, success in developing a business case for a new initiative boils down to planning, preparation, and applying a few key concepts we’ve learned from our travels. 

Consensus is critical when planning new technology initiatives

Before you can start the hike, everyone has to agree on some fundamentals: 

Who's going? 

Where are we going? 

When do we go and for how long? 

Getting everyone to agree requires clear communication and, yes, even a little salesmanship: “Trust me. The bears aren’t bad this time of year.” The same principle applies in proposing new technology initiatives; making sure everyone has bought into the basic framework of the initiative is critical to success.

Although many hiking trips involve groups of people similar in age, ability, and whereabouts, for your business initiative you need to communicate with diverse groups of colleagues at every level of the organization. Gaining consensus among people who bring a wide variety of skills and perspectives to the project can be complex.

To gain consensus, consider the intended audiences of your message and target the content to what will work for them. It should provide enough information for executive-level stakeholders to quickly understand the initiative and the path forward. It should give people responsible for implementation or who will provide specific skills substantive information to implement the plan. And remember: one of the most common reasons projects struggle to meet their stated objectives (and why some projects never materialize to begin with), is a lack of sponsorship and buy-in. The goal of a business case is to gain buy-in before project initiation, so your sponsors will actively support the project during implementation. 

Set clear goals for your enterprise technology project 

It’s refreshing to take the first steps, to feel that initial sense of freedom as you set off down the trail. Yet few people truly enjoy wandering around aimlessly in the wilderness for an extended period of time. Hikers need goals, like reaching a mountain peak or seeing famous landmarks, or hiking a predetermined number of miles per day. And having a trail guide is key in meeting those goals. 

For a new initiative, clearly define goals and objectives, as well as pain points your organization wishes to address. This is critical to ensuring that the project’s sponsors and implementation team are all on the same page. Identifying specific benefits of completing your initiative can help people keep their “eyes on the prize” when the project feels like an uphill climb.

Timelines provide additional detail and direction—and demonstrate to decision makers that you have considered multiple facets of the project, including any constraints, resource limitations, or scheduling conflicts. Identifying best practices to incorporate throughout the initiative enhances the value of a business case proposition, and positions the organization for success. By leveraging lessons learned on previous projects, and planning for and mitigating risk, the organization will begin to clear the path for a successful endeavor. 

Don’t compromise on the right equipment

Hiking can be an expensive, time-consuming hobby. While the quality of your equipment and the accuracy of your maps are crucial, you can do things with limited resources if you’re careful. Taking the time to research and purchase the right equipment, (like the right hiking boots), keeps your fun expedition from becoming a tortuous slog. 

Similarly, in developing a business case for a new initiative, you need to make sure that you identify the right resources in the right areas. We all live with resource constraints of one sort or another. The process of identifying resources, particularly for funding and staffing the project, will lead to fewer surprises down the path. As many government employees know all too well, it is better to be thorough in the budget planning process than to return to authorizing sources for additional funding while midstream in a project. 

Consider your possible outcomes

You cannot be too singularly focused in the wild; weather conditions change quickly, unexpected opportunities reveal themselves, and being able to adapt quickly is absolutely necessary in order for everyone to come home safely. Sometimes, you should take the trail less traveled, rest in the random lean-to that you and your group stumble upon, or go for a refreshing dip in a lake. By focusing on more than just one single objective, it often leads to more enjoyable, safe, and successful excursions.

This type of outlook is necessary to build a business case for a new initiative. You may need to step back during your initial planning and consider the full impact of the process, including on those outside your organization. For example, you may begin to identify ways in which the initiative could benefit both internal and external stakeholders, and plan to move forward in a slightly new direction. Let’s say you’re building a business case for a new land management and permitting software system. Take time to consider that this system may benefit citizens, contractors, and other organizations that interact with your department. This new perspective can help you strengthen your business case. 

Expect teamwork

A group that doesn’t practice teamwork won’t last long in the wild. In order to facilitate and promote teamwork, it’s important to recognize the skills and contributions of each and every person. Some have a better sense of direction, while some can more easily start campfires. And if you find yourself fortunate enough to be joined by a truly experienced hiker, make sure that you listen to what they have to say.

Doing the hard work to present a business case for a new initiative may feel like a solitary action at times, but it’s not. Most likely, there are other people in your organization who see the value in the initiative. Recognize and utilize their skills in your planning. We also suggest working with an experienced advisor who can leverage best practices and lessons learned from similar projects. Their experience will help you anticipate potential resistance and develop and articulate the mitigation strategies necessary to gain support for your initiative.

If you have thoughts, concerns, or questions, contact our team. We love to discuss the potential and pitfalls of new initiatives, and can help prepare you to head out into the wild. We’d love to hear any parallels with hiking and wilderness adventuring that you have as well. Let us know! 

BerryDunn’s local government consulting team has the experience to lead technology planning initiatives and develop actionable plans that help you think strategically and improve service delivery. We partner with you, maintaining flexibility and open lines of communication to help ensure that your team has the resources it needs.

Our team has broad and deep experience partnering with local government clients across the country to modernize technology-based business transformation projects and the decision-making and planning efforts. Our expertise includes software system assessments/planning/procurement and implementation project management; operational, management, and staffing assessments; information security; cost allocation studies; and data management.  

Read this if you are a police executive, city/county administrator, or elected government official, responsible for a law enforcement agency. 

“We need more cops!”  

Do your patrol officers complain about being short-staffed or too busy, or that they are constantly running from call to call? Does your agency struggle with backed-up calls for service (CFS) or lengthy response times? Do patrol staff regularly find themselves responding to another patrol area to handle a CFS because the assigned officer is busy on another call? Are patrol officers denied leave time or training opportunities because of staffing issues? Does the agency routinely use overtime to cover predictable shift vacancies for vacations, holidays, or training? 

If one or more of these concerns sound familiar, you may need additional patrol resources, as staffing levels are often a key factor in personnel deployment challenges. Flaws in the patrol schedule design may also be responsible, as they commonly contribute to reduced efficiency and optimal performance, and design issues may be partially responsible for some of these challenges, regardless of authorized staffing levels.
 
With community expectations at an all-time high, and resource allocations remaining relatively flat, many agencies have growing concerns about managing increasing service volumes while controlling quality and building/maintaining public trust and confidence. Amid these concerns, agencies struggle with designing work schedules that efficiently and optimally deploy available patrol resources, as patrol staff become increasingly frustrated at what they consider a lack of staff.

The path to resolving inefficiencies in your patrol work schedule and optimizing the effective deployment of patrol personnel requires thoughtful consideration of several overarching goals:

• Reducing or eliminating predictable overtime
• Eliminating peaks and valleys in staffing due to scheduled leave
• Ensuring appropriate staffing levels in all patrol zones or beats
• Providing sufficient staff to manage multiple and priority CFS in patrol zones or beats
• Satisfying both operational and staff needs, including helping to ensure a proper work/life balance and equitable workloads for patrol staff

Scheduling alternatives

One common design issue that presents an ongoing challenge for agencies is the continued use of traditional, balanced work schedules, which spread officer work hours equally over the year. Balanced schedules rely on over-scheduling and overtime to manage personnel allocation and leave needs and, by design, are very rigid. Balanced work schedules have been used for a very long time, not because they’re most efficient, but because they’re common, familiar, and easily understood―and because patrol staff are comfortable with them (and typically reluctant to change). However, short schedules offer a proven alternative to balanced patrol work schedules, and when presented with the benefits of an alternative work schedule design (e.g., increased access to back-up, ease of receiving time off or training, consistency in staffing, less mandatory overtime), many patrol staff are eager to change.

Short schedules

Short schedules involve a more contemporary design that includes a flexible approach that focuses on a more adaptive process of allocating personnel where and when they are needed. They are significantly more efficient than balanced schedules and, when functioning properly, they can dramatically improve personnel deployments, bring continuity to daily staffing, and reduce overtime, among other operational benefits. Given the current climate, most agencies are unlikely to receive substantial increases in personnel allocations. If that is true of your agency, it may be time to explore the benefits of alternative patrol work schedules.

A tool you can use

Finding scheduling strategies that work in this climate requires an intentional approach, customized to your agency’s characteristics (e.g., staffing levels, geographic factors, crime rates, zone/beat design, contract/labor rules). To help guide you through this process, BerryDunn has developed a free tool for evaluating patrol schedules. Click here to measure your patrol schedule against key design components and considerations.

If you are curious about alternative patrol work schedules, our dedicated justice and public Safety consultants are available to discuss your organization’s needs.

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

This is the second blog post in the blog series: “Procuring Agile vs. Non-Agile Service”. Read the first blog. This blog post demonstrates the differences in Stage 1: Plan Project in the five stages of procuring agile vs. non-agile services.

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

What is important to consider in agile procurement?

Here are some questions that can help focus the planning for procurement of IT services for agile vs. non-agile projects.

Plan Project Considerations for Agile vs. Non-Agile IT Services

Why are these considerations important?

When you procure agile IT services, you can define the scope of your procurement around a vision of what your organization intends to become, as opposed to being restricted to an end-date for a final delivery.

In an agile project, you get results iteratively; this allows you to constantly reassess requirements throughout the project, including the project plan, the guiding principles, and the project schedule. Your planning is not restricted to considering the effect of one big result at the end of the project schedule. Instead, your plan allows for sequencing of changes and improvements that best reflect the outcomes and priorities your organization needs. 

Since planning impacts the people-aspect of your strategy, it is important to consider how various teams and stakeholders will provide input, and how you will make ongoing communication updates throughout the project. With an agile procurement project, your culture will shift, and you will need a different approach to planning, scheduling, communicating, and risk management. You need to communicate daily, allowing for reviewing and adjusting priorities and plans to meet project needs. 

How do you act on these considerations?

A successful procurement plan of agile IT services should include the following steps:

1. Develop a project charter and guiding principles for the procurement that reflect a vision of how your organization’s teams will work together in the future
2. Create a communication plan that includes the definition of project success and communicates project approach
3. Be transparent about the development strategy, and outline how iterations are based on user needs, that features will be re-prioritized on an ongoing basis, and that users, customers, and stakeholders are needed to help define requirements and expected outcomes
4. Provide agile training to your management, procurement, and program operation teams to help them accept and understand the project will present deliverables in iterations, to include needed features, functionality and working products
5. Develop requirements for the scope of work that align with services and outcomes you want, rather than documented statements that merely map to your current processes 

What’s next? 

Now that you have gained insight into the approach to planning an agile project, consider how you may put this first stage into practice in your organization. Stay tuned for guidance on how to execute the second stage of the procurement process—how to draft the RFP. Our intention is that, following this series, your organization will better understand how to successfully procure and implement agile services. If you have questions or comments, please contact our team.
 

Best practices for financial institution contracts with technology providers

As the financial services sector moves in an increasingly digital direction, you cannot overstate the need for robust and relevant information security programs. Financial institutions place more reliance than ever on third-party technology vendors to support core aspects of their business, and in turn place more reliance on those vendors to meet the industry’s high standards for information security. These include those in the Gramm-Leach-Bliley Act, Sarbanes Oxley 404, and regulations established by the Federal Financial Institutions Examination Council (FFIEC).

On April 2, 2019, the FDIC issued Financial Institution Letter (FIL) 19-2019, which outlines important requirements and considerations for financial institutions regarding their contracts with third-party technology service providers. In particular, FIL-19-2019 urges financial institutions to address how their business continuity and incident response processes integrate with those of their providers, and what that could mean for customers.

Common gaps in technology service provider contracts

As auditors of IT controls, we review lots of contracts between financial institutions and their technology service providers. When it comes to recommending areas for improvement, our top observations include:

• No right-to-audit clause
  Including a right-to-audit clause encourages transparency and provides greater assurance that vendors are providing services, and charging for them, in accordance with their contract.
• Unclear and/or inadequate rights and responsibilities around service disruptions
  In the event of a service incident, time and transparency are vital. Contracts that lack clear and comprehensive standards, both for the vendor and financial institution, regarding business continuity and incident response expose institutions to otherwise avoidable risk, including slow or substandard communications.
• No defined recovery standards
  Explicitly defined recovery standards are essential to ensuring both parties know their role in responding and recovering from a disaster or other technology outage.

FIL-19-2019 also reminds financial institutions that they need to properly inform regulators when they undertake contracts or relationships with technology service providers. The Bank Service Company Act requires financial institutions to inform regulators in writing when receiving third-party services like sorting and posting of checks and deposits, computation and posting of interest, preparation and mailing of statements, and other functions involving data processing, Internet banking, and mobile banking services.

Writing clearer contracts that strengthen your institution

Financial institutions should review their contracts, especially those that are longstanding, and make necessary updates in accordance with FDIC guidelines. As operating environments continue to evolve, older contracts, often renewed automatically, are particularly easy to overlook. You also need to review business continuity and incident response procedures to ensure they address all services provided by third-parties.

Senior management and the Board of Directors hold ultimate responsibility for managing a financial institution’s relationship with its technology service providers. Management should inform board members of any and all services that the institution receives from third-parties to help them better understand your operating environment and information security needs.

Not sure what to look for when reviewing contracts? Some places to start include:

• Establish your right-to-audit
  All contracts should include a right-to-audit clause, which preserves your ability to access and audit vendor records relating to their performance under contract. Most vendors will provide documentation of due diligence upon request, such as System and Organization Control (SOC) 1 or 2 reports detailing their financial and IT security controls.
  
  Many right-to-audit clauses also include a provision allowing your institution to conduct its own audit procedures. At a minimum, don’t hesitate to perform occasional walk-throughs of your vendor’s facilities to confirm that your contract’s provisions are being met.

• Ensure connectivity with outsourced data centers
  If you outsource some or all of your core banking systems to a hosted data center, place added emphasis on your institution’s business continuity plan to ensure connectivity, such as through the use of multiple internet or dedicated telecommunications circuits. Data vendors should, by contract, be prepared to assist with alternative connectivity.

• Set standards for incident response communications 
  Clear expectations for incident response are crucial  to helping you quickly and confidently manage the impact of a service incident on your customers and information systems. Vendor contracts should include explicit requirements for how and when vendors will communicate in the event of any issue or incident that affects your ability to serve your customers. You should also review and update contracts after each incident to address any areas of dissatisfaction with vendor communications.

• Ensure regular testing of defined disaster recovery standards
  While vendor contracts don’t need to detail every aspect of a service provider’s recovery standards, they should ensure those standards will meet your institution’s needs. Contracts should guarantee that the vendor periodically tests, reviews, and updates their recovery standards, with input from your financial institution.
  
  Your data center may also offer regular disaster recovery and failover testing. If they do, your institution should participate in it. If they don’t, work with the vendor to conduct annual testing of your ability to access your hosted resources from an alternate site.

As financial institutions increasingly look to third-party vendors to meet their evolving technology needs, it is critical that management and the board understand which benefits—and related risks—those vendors present. By taking time today to align your vendor contracts with the latest FFIEC, FDIC, and NCUA standards, your institution will be better prepared to manage risk tomorrow.

For more help gaining control over risk and cybersecurity, see our blog on sustainable solutions for educating your Board of Directors and creating a culture of cybersecurity awareness.
 

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.  

“The world is one big data problem,” says MIT scientist and visionary Andrew McAfee.

That’s a daunting (though hardly surprising) quote for many in data-rich sectors, including higher education. Yet blaming data is like blaming air for a malfunctioning wind turbine. Data is a valuable asset that can make your institution move.

To many of us, however, data remains a four-letter word. The real culprit behind the perceived data problem is our handling and perception of data and the role it can play in our success—that is, the relegating of data to a select, responsible few, who are usually separated into hardened silos. For example, a common assumption in higher education is that the IT team can handle it. Not so. Data needs to be viewed as an institutional asset, consumed by many and used by the institution for the strategic purposes of student success, scholarship, and more.

The first step in addressing your “big” data problem? Data governance.

What is data governance?

There are various definitions, but the one we use with our clients is “the ongoing and evolutionary process driven by leaders to establish principles, policies, business rules, and metrics for data sharing.”

Please note that the phrase “IT” does not appear anywhere in this definition.

Why is data governance necessary? For many reasons, including:

1. Data governance enables analytics. Without data governance, it’s difficult to gain value from analytics initiatives which will produce inconsistent results. A critical first step in any data analytics initiative is to make sure that definitions are widely accepted and standards have been established. This step allows decision makers to have confidence in the data being analyzed to describe, predict, and improve operations.
2. Data governance strengthens privacy, security, and compliance. Compliance requirements for both public and private institutions constantly evolve. The more data-reliant your world becomes, the more protected your data needs to be. If an organization does not implement security practices as part of its data governance framework, it becomes easier to fall out of compliance. 
3. Data governance supports agility. How many times have reports for basic information (part-time faculty or student FTEs per semester, for example) been requested, reviewed, and returned for further clarification or correction? And that’s just within your department! Now add multiple requests from the perspective of different departments, and you’re surely going through multiple iterations to create that report. That takes time and effort. By strengthening your data governance framework, you can streamline reporting processes by increasing the level of trust you have in the information you are seeking. Understanding the value of data governance is the easy part. The real trick is implementing a sustainable data governance framework that recognizes that data is an institutional asset and not just a four-letter word.

If you’ve been tasked with leading a high-impact project for your organization, you may find managing the scope, budget and schedule is not enough to ensure project success—especially when you encounter resistance to change. When embarking on large-scale change projects spanning people, processes and technology, appointing staff as “coaches” to help support stakeholders through the change—and to manage resistance to the change—can help increase adoption and buy-in for a new way of doing things.

The first step is to identify candidates for the coaching role. These candidates are often supervisory staff who have credibility in the organization—whether as a subject matter expert, through internal leadership, or from having a history of client satisfaction. Next, you need a work plan to orient them to this role. One critical component is making sure the coaches themselves understand what the change means for their role, and have fully committed before asking them to coach others. They may exhibit initial resistance to the change you will need to manage before they can be effective coaches. According to research done by Prosci®, a leading change management research organization, some of the most common reasons for supervisor resistance in large-scale change projects are:

• Lack of awareness about and involvement in the change
• Loss of control or negative impact on job role
• Increased work load (i.e., lack of time)
• Culture of change resistance and past failures
• Impact to their team

You should anticipate encountering these and other types of resistance from staff while preparing them to be coaches. Once coaches buy into the change, they will need ongoing support and guidance to fulfill their role. This support will vary by individual, but may be correlated to what managerial skills they already possess, or don’t. How can you focus on developing coaching skills among your staff for purposes of the project? Prosci® recommends a successful change coach take on the following roles:

• Communicator—communicate with direct reports about the change
• Liaison—engage and liaise with the project team
• Advocate—advocate and champion the change
• Resistance manager—identify and manage resistance
• Coach—coach employees through the change

One of the initial tasks for your coaches will be to assess the existing level of change resistance and evaluate what resistance you may encounter. Prosci® identifies three types of resistance management work for your coaches to begin engaging in as they meet with their employees about the change:

• Resistance prevention―by providing engagement opportunities for stakeholders throughout the project, building awareness about the change early on, and reinforcing executive-level support, coaches can often head off expected resistance.
• Proactive resistance management―this approach requires coaches to anticipate the needs and understand the characteristics of their staff, and assess how they might react to change in light of these attributes. Coaches can then plan for likely forms of resistance in advance, with a structured mitigation approach.
• Reactive resistance management―this focuses on resistance that has not been mitigated with the previous two types of resistance management, but instead persists or endures for an extended amount of time. This type of management may require more analysis and planning, particularly as the project nears its completion date.

Do you have candidates in your organization who may need support transitioning into coaching roles? Do you anticipate change resistance among your stakeholders? Contact us and we can help you develop a plan to address your specific challenges.

Modernization means different things to different people—especially in the context of state government. For some, it is the cause of a messy chain reaction that ends (at best) in frustration and inefficiency. For others, it is the beneficial effect of a thoughtful and well-planned series of steps. The difference lies in the approach to transition - and states will soon discover this as they begin using the new Comprehensive Child Welfare Information System (CCWIS), a case management information system that helps them provide citizens with customized child welfare services.

The benefits of CCWIS are numerous and impressive, raising the bar for child welfare and providing opportunities to advance through innovative technology that promotes interoperability, flexibility, improved management, mobility, and integration. However, taking advantage of these benefits will also present challenges. Gone are the days of the cookie-cutter, “one-size-fits-all” approach. Here are five facts to consider as you transition toward an effective modernization.

1. There are advantages and challenges to buying a system versus building a system internally. CCWIS transition may involve either purchasing a complete commercial off-the-shelf (COTS) product that suits the state, or constructing a new system internally with the implementation of a few purchased modules. To decide which option is best, first assess your current systems and staff needs. Specifically, consider executing a cost-benefit analysis of options, taking into account internal resource capabilities, feasibility, flexibility, and time. This analysis will provide valuable data that help you assess the current environment and identify functional gaps. Equipped with this information, you should be ready to decide whether to invest in a COTS product, or an internally-built system that supports the state’s vision and complies with new CCWIS regulations.
    
2. Employ a modular approach to upgrading current systems or building new systems. The Children’s Bureau—an office of the Administration for Children & Families within the U.S. Department of Health and Human Services—defines “modularity” as the breaking down of complex functions into separate, manageable, and independent components. Using this modular approach, CCWIS will feature components that function independently, simplifying future upgrades or procurements because they can be completed on singular modules rather than the entire system. Modular systems create flexibility, and enable you to break down complex functions such as “Assessment and Intake,” “Case Management,” and “Claims and Payment” into modules during CCWIS transition. This facilitates the development of a sustainable system that is customized to the unique needs of your state, and easily allows for future augmentation.
    
3. Use Organizational Change Management (OCM) techniques to mitigate stakeholder resistance to change. People are notoriously resistant to change. This is especially true during a disruptive project that impacts day-to-day operations—such as building a new or transitional CCWIS system. Having a comprehensive OCM plan in place before your CCWIS implementation can help ensure that you assign an effective project sponsor, develop thorough project communications, and enact strong training methods. A clear OCM strategy should help mitigate employee resistance to change and can also support your organization in reaching CCWIS goals, due to early buy-in from stakeholders who are key to the project’s success.
    
4. Data governance policies can help ensure you standardize mandatory data sharing. For example, the Children’s Bureau notes that a Title IV-E agency with a CCWIS must support collaboration, interoperability, and data sharing by exchanging data with Child Support Systems?Title IV-D, Child Abuse/Neglect Systems, Medicaid Management Information Systems (MMIS), and many others as described by the Children’s Bureau.
   
   Security is a concern due to the large amount of data sharing involved with CCWIS systems. Specifically, if a Title IV-E agency with a CCWIS does not implement foundational data security measures across all jurisdictions, data could become vulnerable, rendering the system non-compliant. However, a data governance framework with standardized policies in place can protect data and surrounding processes.
    
5. Continuously refer to federal regulations and resources. With the change of systems comes changes in federal regulations. Fortunately, the Children’s Bureau provides guidance and toolkits to assist you in the planning, development, and implementation of CCWIS. Particularly useful documents include the “Child Welfare Policy Manual,” “Data Sharing for Courts and Child Welfare Agencies Toolkit,” and the “CCWIS Final Rule”. A comprehensive list of federal regulations and resources is located on the Children’s Bureau website.
   
   Additionally, the Children’s Bureau will assign an analyst to each state who can provide direction and counsel during the CCWIS transition. Continual use of these resources will help you reduce confusion, avoid obstacles, and ultimately achieve an efficient modernization program.

Modernization doesn’t have to be messy. Learn more about how OCM and data governance can benefit your agency or organization.