Audit‑ready procurement: How to spot risks and close the gaps

We’ve all heard stories about organizations spending thousands on software projects, such as Enterprise Resource Planning (ERP), Electronic Health Record (EHR), or Student Information Systems (SIS) that take longer than expected to implement and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, Commercial Off-The-Shelf (COTS) enterprise system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost overruns).

These systems are complex, and implementation efforts impact both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

1. Should we purchase software that similar organizations have purchased?
   As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undefined? One way to identify your organization’s needs—and to avoid costly mistakes down the road—is to identify requirements during the procurement process.

2. What are the functional and technical requirements of the system?Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:
   
   Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses.” Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.
   
   Technical requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be requirements that define what database the system must support. For example, “The system must support use of the client preferred database.” They may also describe security capabilities of the system, the ability to import or export data, or the ease of use and overall end-user interface.

3. Who should help define and document requirements for the new enterprise system?
   
   When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.
   
   Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and those not so eager to change will help build the best system.
    
4. When do you revise enterprise system requirements? 
   It is always important to begin the software procurement process with a documented set of requirements; you need them to identify the best solution. The same goes for the implementation process where vendors use the requirements to guide the setup and configuration of the new system. But be prepared to revise and enhance requirements when a vendor solution offers an improved capability or a better method to achieve the results. The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and often delivers enhanced capabilities.

Be sure to document system requirements for an efficient process

There may be thousands of requirements for an enterprise system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

• Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
• Requirements help determine specific tasks and activities to address during the implementation process. While applications can’t always meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
• Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.

Our experienced consultants have led many software procurement projects and have firsthand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

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 your organization is planning on upgrading or replacing an enterprise technology system.

It can be challenging and stressful to plan for technology initiatives, especially those that involve and impact every area of your organization. Common initiatives include software upgrades or replacements for:

• Financial management, such as Enterprise Resource Planning (ERP) systems
• Asset management systems
• Electronic health records (EHR) systems
• Permitting and inspections systems

Though the number of considerations when planning enterprise technology projects can be daunting, the greatest mistake you can make is not planning at all. By addressing just a few key areas, you can avoid some of the most common pitfalls, such as exceeding budget and schedule targets, experiencing scope creep, and losing buy-in among stakeholders. Here are some tips to help you navigate your next project:

Identify your IT project roles and resources

While most organizations understand the importance of identifying project stakeholder groups, it is often an afterthought. Defining these roles at the outset of your project helps you accurately estimate the work effort.

Your stakeholder groups may include:

• An executive sponsor
• A steering committee
• A project manager
• Functional leads
• A technical team

Once you’ve established the necessary roles, you can begin reviewing your organization’s resources to determine the people who will be available to fill them. Planning for resource availability will help you avoid delays, minimize impact to regular business processes, and reduce the likelihood of burnout. But this plan won’t remain static—you can expect to make updates throughout the project.

Establish clear goals and objectives to keep your technology project on track

It’s important that an enterprise technology project has established goals and objectives statements. These statements will help inform decision-making, provide benchmarks for progress, and measure your project’s success. They can then be referenced when key stakeholders have differing perspectives on the direction to take with a pending decision. For example, if the objective of your project is to reduce paper-based processes, you may plan for additional computer workstations and focus technical resources on provisioning them. You’ll also be able to measure your success in the reduction of paper-based tasks.

Estimate your IT project budget accurately

Project funding is hardly ever overlooked, but can be complex with project budgets that are either underestimated or estimated without sufficient rationale to withstand approval processes and subsequent budget analysis. You may find that breaking down estimates to a lower level of detail helps address these challenges. Most technology projects incur costs in three key areas:

• Vendor cost: This could include both one-time software implementation costs as well as recurring costs for maintenance and ongoing support.
• Infrastructure cost: Consider the cost of any investments needed to support your project, such as data center hardware, networking components, or computing devices.
• Supplemental resource cost: Don’t forget to include the cost of any additional resources needed for their specialized knowledge or to simply backfill project staff. This could include contracted resources or the additional cost of existing resources (i.e., overtime).

A good technology project budget also includes a contingency amount. This amount will depend on your organization’s standards, the relative level of confidence in your estimates, and the relative risk.

Anticipate the need for change management

Depending on the project, staff in many areas of your organization will be impacted by some level of change during a technology implementation. External stakeholders, such as vendors and the public, may also be affected. You can effectively manage this change by proactively identifying areas of likely change resistance and creating strategies to address them.

In any technology implementation, you will encounter change resistance you did not predict. Having strategies in place will help you react quickly and effectively. Some proven change management strategies include communicating throughout your project, involving stakeholders to get their buy-in, and helping ensure management has the right amount of information to share with their employees.

Maintain focus and stay flexible as you manage your IT project

Even with the most thought-out planning, unforeseen events and external factors may impact your technology project. Establish mechanisms to regularly and proactively monitor project status so that you can address material risks and issues before their impact to the project grows. Reacting to these items as they arise requires key project stakeholders to be flexible. Key stakeholders must recognize that new information does not necessarily mean previous decisions were made in error, and that it is better to adapt than to stick to the initial direction.

Whether you’re implementing an ERP, an EHR, or enterprise human resources or asset management systems, any enterprise technology project is a massive undertaking, involving significant investment and a coordinated effort with individuals across multiple areas of an organization. Common mistakes can be costly, but having a structured approach to your planning can help avoid pitfalls. Our experienced, objective advisors have worked with public and private organizations across the country to oversee large enterprise projects from inception to successful completion.

Contact our software consulting team with any questions.

LIBOR is leaving—is your financial institution ready to make the most of it?

In July 2017, the UK’s Financial Conduct Authority announced the phasing out of the London Interbank Offered Rate, commonly known as LIBOR, by the end of 2021¹. With less than two years to go, US federal regulators are urging financial institutions to start assessing their LIBOR exposure and planning their transition. Here we offer some general impacts of the phasing out, some specific actions your institution can take to prepare, and, finally, background on how we got here (see Background at right).

How will the phase-out impact financial institutions?

The Federal Reserve estimates roughly $200 trillion in LIBOR-indexed notional value transactions in the cash and derivatives market². LIBOR is used to help price a variety of financial services products,  including $3.4 trillion in business loans and $1.3 trillion in consumer loans, as well as derivatives, swaps, and other credit instruments. Even excluding loans and financial instruments set to mature before 2021—estimated by the FDIC at 82% of the above $200 trillion—LIBOR exposure is still significant³.

A financial institution’s ability to lend money is largely dependent on the relative stability of its capital position, or lack thereof. For institutions with a significant amount of LIBOR-indexed assets and liabilities, that means less certainty in expected future cash flows and a less stable capital position, which could prompt institutions to deny loans they might otherwise have approved. A change in expected cash flows could also have several indirect consequences. Criticized assets, assessed for impairment based on their expected future cash flows, could require a specific reserve due to lower present value of expected future cash flows.

The importance of fallback language in loan agreements

Fallback language in loan agreements plays a pivotal role in financial institutions’ ability to manage their LIBOR-related financial results. Most loan agreements include language that provides guidance for determining an alternate reference rate to “fall back” on in the event the loan’s original reference rate is discontinued. However, if this language is non-existent, contains fallbacks that are no longer adequate, or lacks certain key provisions, it can create unexpected issues when it comes time for financial institutions to reprice their LIBOR loans. Here are some examples:

• Non-existent or inadequate fallbacks
  According to the Alternative Reference Rates Committee, a group of private-market participants convened by the Federal Reserve to help ensure a successful LIBOR transition, "Most contracts referencing LIBOR do not appear to have envisioned a permanent or indefinite cessation of LIBOR and have fallbacks that would not be economically appropriate"⁴.
  
  For instance, industry regulators have warned that without updated fallback language, the discontinuation of LIBOR could prompt some variable-rate loans to become fixed-rate², causing unanticipated changes in interest rate risk for financial institutions. In a declining rate environment, this may prove beneficial as loans at variable rates become fixed. But in a rising rate environment, the resulting shrink in net interest margins would have a direct and adverse impact on the bottom line.

• No spread adjustment
  Once LIBOR is discontinued, LIBOR-indexed loans will need to be repriced at a new reference rate, which could be well above or below LIBOR. If loan agreements don’t provide for an adjustment of the spread between LIBOR and the new rate, that could prompt unexpected changes in the financial position of both borrowers and lenders³. Take, for instance, a loan made at the Secured Overnight Financing Rate (SOFR), generally considered the likely replacement for USD LIBOR. Since SOFR tends to be lower than three-month LIBOR, a loan agreement using it that does not allow for a spread adjustment would generate lower loan payments for the borrower, which means less interest income for the lender.
  
  Not allowing for a spread adjustment on reference rates lower than LIBOR could also cause a change in expected prepayments—say, for instance, if borrowers with fixed-rate loans decide to refinance at adjustable rates—which would impact post-CECL allowance calculations like the weighted-average remaining maturity (WARM) method, which uses estimated prepayments as an input.

What can your financial institution do to prepare?

The Federal Reserve and the SEC have urged financial institutions to immediately evaluate their LIBOR exposure and expedite their transition. Though the FDIC has expressed no intent to examine financial institutions for the status of LIBOR planning or critique loans based on use of LIBOR³, Federal Reserve supervisory teams have been including LIBOR transitions in their regular monitoring of large financial institutions⁵. The SEC has also encouraged companies to provide investors with robust disclosures regarding their LIBOR transition, which may include a notional value of LIBOR exposure².

Financial institutions should start by analyzing their LIBOR exposure beyond 2021. If you don’t expect significant exposure, further analysis may be unnecessary. However, if you do expect significant future LIBOR exposure, your institution should conduct stress testing using LIBOR as an isolated variable by running hypothetical transition scenarios and assessing the potential financial impact.

Closely examine and assess fallback language in loan agreements. For existing loan agreements, you may need to make amendments, which could require consent from counterparties². For new loan agreements maturing beyond 2021, lenders should consider selecting an alternate reference rate. New contract language for financial instruments and residential mortgages is currently being drafted by the International Securities Dealers Association and the Federal Housing Finance Authority, respectively³—both of which may prove helpful in updating loan agreements.

Lenders should also consider their underwriting policies. Loan underwriters will need to adjust the spread on new loans to accurately reflect the price of risk, because volatility and market tendencies of alternate loan reference rates may not mirror LIBOR’s. What’s more, SOFR lacks abundant historical data for use in analyzing volatility and market tendencies, making accurate loan pricing more difficult.

Conclusion: Start assessing your LIBOR risk soon

The cessation of LIBOR brings challenges and opportunities that will require in-depth analysis and making difficult decisions. Financial institutions and consumers should heed the advice of regulators and start assessing their LIBOR risk now. Those that do will not only be better prepared―but also better positioned―to capitalize on the opportunities it presents.

Need help assessing your LIBOR risk and preparing to transition? Contact BerryDunn’s financial services specialists.

¹ https://www.washingtonpost.com/business/2017/07/27/acdd411c-72bc-11e7-8c17-533c52b2f014_story.html?utm_term=.856137e72385
² Thomson Reuters Checkpoint Newsstand April 10, 2019
³ https://www.fdic.gov/regulations/examinations/supervisory/insights/siwin18/si-winter-2018.pdf
^{4 https://bankingjournal.aba.com/2019/04/libor-transition-panel-recommends-fallback-language-for-key-instruments/
5} https://www.reuters.com/article/us-usa-fed-libor/fed-urges-u-s-financial-industry-to-accelerate-libor-transition-idUSKCN1RM25T

Who has the time or resources to keep tabs on everything that everyone in an organization does? No one. Therefore, you naturally need to trust (at least on a certain level) the actions and motives of various personnel. At the top of your “trust level” are privileged users—such as system and network administrators and developers—who keep vital systems, applications, and hardware up and running. Yet, according to the 2019 Centrify Privileged Access Management in the Modern Threatscape survey, 74% of data breaches occurred using privileged accounts. The survey also revealed that of the organizations responding:

• 52% do not use password vaulting—password vaulting can help privileged users keep track of long, complex passwords for multiple accounts in an encrypted storage vault.
• 65% still share the use of root and other privileged access—when the use of root accounts is required, users should invoke commands to inherent the privileges of the account (SUDO) without actually using the account. This ensures “who” used the account can be tracked.
• Only 21% have implemented multi-factor authentication—the obvious benefit of multi-factor authentication is to enhance the security of authenticating users, but also in many sectors it is becoming a compliance requirement.
• Only 47% have implemented complete auditing and monitoring—thorough auditing and monitoring is vital to securing privileged accounts.

So how does one even begin to trust privileged accounts in today’s environment? 

1. Start with an inventory

To best manage and monitor your privileged accounts, start by finding and cataloguing all assets (servers, applications, databases, network devices, etc.) within the organization. This will be beneficial in all areas of information security such as asset management, change control and software inventory tracking. Next, inventory all users of each asset and ensure that privileged user accounts:

• Require privileges granted be based on roles and responsibilities
• Require strong and complex passwords (exceeding those of normal users)
• Have passwords that expire often (30 days recommended)
• Implement multi-factor authentication
• Are not shared with others and are not used for normal activity (the user of the privileged account should have a separate account for non-privileged or non-administrative activities)

If the account is only required for a service or application, disable the account’s ability to login from the server console and from across the network

2. Monitor—then monitor some more

The next step is to monitor the use of the identified privileged accounts. Enable event logging on all systems and aggregate to a log monitoring system or a Security Information and Event Management (SIEM) system that alerts in real time when privileged accounts are active. Configure the system to alert you when privileged accounts access sensitive data or alter database structure. Report any changes to device configurations, file structure, code, and executable programs. If these changes do not correlate to an approved change request, treat them as incidents and investigate.  

Consider software that analyzes user behavior and identifies deviations from normal activity. Privileged accounts that are accessing data or systems not part of their normal routine could be the indication of malicious activity or a database attack from a compromised privileged account. 

3. Secure the event logs

Finally, ensure that none of your privileged accounts have access to the logs being used for monitoring, nor have the ability to alter or delete those logs. In addition to real time monitoring and alerting, the log management system should have the ability to produce reports for periodic review by information security staff. The reports should also be archived for forensic purposes in the event of a breach or compromise.

Gain further assistance (and peace of mind) 

BerryDunn understands how privileged accounts should be monitored and audited. We can help your organization assess your current event management process and make recommendations if improvements are needed. Contact our team.

While GASB has been talking about split-interest agreements for a long time (the proposal first released in June of 2015, with GASB Statement No. 81, Irrevocable Split-Interest Agreements released in March of 2016), time is quickly running out for a well-planned implementation. With the effective date looming on the horizon, (statement effective for periods beginning after December 15, 2016 unless early adopted), now is the time to start gathering needed information to record existing agreements under GASB 81.

We have learned from GASB’s not-for-profit FASB cousins that irrevocable agreements are rarely where they should be: in the hands of financial professionals. Compiling these agreements will require participation from many stakeholders. Your finance team will likely have to provide some education to avoid a great deal of confusion when asking the “do we have any irrevocable split-interest agreements?” question.

So, where do you start?

1. Have you been tracking this information right along, nicely documented in a folder by your desk? Great! Do a quick check of others in your organization to be sure your file is complete and skip steps 2-5.
    
2. Dig into your general ledger. Have you been receiving regular distributions from a trust? Some of these trust agreements pay out on a quarterly or annual basis and your accounting staff should be able to identify these payors. It may require a quick call to the administrator for the trust agreement to be sure the agreement qualifies under GASB 81.
    
3. Look to your fundraising professionals. Development departments like to keep track of all types of donations. It helps to quantify their good fundraising work. Be clear about what you need from them. Remember, irrevocable split-interest agreements, often trusts or other legally enforceable agreements, are agreements wherein a donor irrevocably transfers resources to a third party to hold for the benefit of the government and at least one other beneficiary —the “split” in “split-interest agreement”!
    
4. Keep talking to your fundraising professionals. Many of the split-interest agreements we find are very old, often created well before your current development software was put into place. Do you have old files that track this kind of information? It may require some digging in the paper files. Remember those?
    
5. All hands on deck. While the finance and fundraising teams are scouring their records, look to others in the organization that might have record of these types of agreements. You know who holds the keys to historical knowledge at your organization, so be sure to include them in your search.

Once the finance department has collected all of the agreements, take one more look to be sure they meet the requirements of GASB 81.“Are they really irrevocable? Or do we just hope they are?” Then you can get down to the business of accounting for them. If you have questions about the accounting for these agreements, please contact me. I would love to chat. And that is irrevocable.

We all know them. In fact, you might be one of them — people who worry the words “go live” will lead to job loss (theirs). This feeling is not entirely irrational. When an organization is ready to go live from an existing legacy system to a new enterprise system, stress levels rise and doubts emerge: What can go wrong? How much time will be lost? Are we really ready for this?

We’re here to help. Here is a list of go-live essentials to help you mitigate stress and assess your readiness. While not all-encompassing, it’s a good place to start. Here’s what you need:

1. A detailed project plan which specifies all of the implementation tasks
   A project plan is one of the most important parts of an implementation. A detailed plan that identifies all of the implementation tasks along with an assigned resource for each task is critical to success. The implementation vendor and the organization should develop this plan together to get buy-in from both teams.

2. A completed system configuration
   New system configuration is one of the most time-consuming aspects of a technology implementation. If you don’t complete the implementation in a timely manner, it will impact your go-live date. Configure the new system based upon the best practices of the system — not how the existing system was — for timely implementation.

3. External system interface identification
   While replacement of some external systems may be a goal of an implementation, there may be situations where external systems are not replaced or the organization has to send and/or receive data from external organizations. And while new systems have advanced interface technology capabilities, the external systems may not share these capabilities. Therefore it is imperative that you identify external system interfaces to avoid gaps in functionality.

4. Testing, testing, testing
   End-to-end testing or User Acceptance Testing (UAT) is often overlooked. It involves completing testing scenarios for each module to ensure appropriate system configuration. While the timing of UAT may vary, allow adequate time to identify solutions to issues that may result from UAT.

5. Data conversion validation
   When you begin using a new system, it’s best to ensure you’re working with clean, up-to-date data. Identify data conversion tasks in the project plan and include multiple data conversion passes. You must also determine if the existing data is actually worth converting. When you complete the data conversion, check for accuracy.

6. End user training
   You must train all end users to ensure proper utilization across the organization. Don’t underestimate the amount of time needed for end user training. It is also important to provide a feedback mechanism for end users to determine if the training was successful.

7. A go-live cutover plan
   The overall project plan may indicate go-live as an activity. List specific activities to complete as part of go-live. You can build these tasks into the project plan or maintain them as a separate checklist to promote a smooth transition.

8. Support structure
   Establish an internal support structure when preparing for go-live to help address issues that may arise. Most organizations take time to configure and test the system and provide training to end users prior to go-live. Questions will arise as part of this process — establish a process to track and address these questions.

Technology implementations can significantly impact your organization, and it’s common for stress levels to rise during the go-live process. But with the right assessment and preparation, you can lessen their impact and reduce staff stress. Our experienced, objective advisors work with public and private sector organizations across the country to oversee large enterprise projects from inception to successful completion. Please reach out to us to learn more about preparing for your next big project.

Recently the Governmental Accounting Standards Board (GASB) finished its Governmental Accounting Research System (GARS), a full codification of governmental accounting standards. The completion of the project allows preparers easy access to accounting guidance from GASB. The overall project, starting from the codification of older pre-1989 Financial Accounting Standards Board (FASB) pronouncements in 2010, was focused on pulling together all authoritative guidance, similar to what FASB had done in 2009.

Here’s what we found interesting.

Poking around the GARS (Basic View is free) I was struck by a paragraph surrounded by a thick-lined box that read “The provisions of this Codification need not be applied to immaterial items.” If you have ever read a GASB or FASB pronouncement, you have seen a similar box. But probably, like me, you didn’t fully consider its potential benefits. Understanding this, GASB published an article on its website aimed at (in my opinion) prompting financial statement preparers to consider reducing disclosure for the many clearly insignificant items often included within governmental financial statements.

After issuing more than 80 pronouncements since its inception in 1984, including 19 in the last five years, GASB accounting requirements continue to grow. Many expect the pace to continue, with issues like leases accounting, potential revision of the financial reporting model, and comprehensive review of revenue and expense recognition accounting currently in process. With these additional accounting standards come more disclosure requirements.

With many still reeling from implementation of the disclosure heavy pension guidance, GASB is already under pressure from stakeholders with respect to information overload. Users of financial statements can be easily overwhelmed by the amount of detailed disclosure, often finding it difficult to identify and focus on the most significant issues for the entity. Balancing the perceived need to meet disclosure requirements with the need to highlight significant information can be a difficult task for preparers. Often preparers lean towards providing too much information in an effort to “make sure everything is in there that should be”. So, what can you do to ease the pain?

While the concept of materiality is not addressed specifically in the GASB standards, by working with your auditors there are a number of ways to reduce the overall length and complexity of the statements. We recommend reviewing your financial statements periodically with your auditor, focusing on the following types of questions:

• On the face of the financial statements, are we breaking out items that are clearly inconsequential in nature and the amount?
• Are there opportunities to combine items where appropriate?
• In the notes to the financial statements are we providing excessive details about insignificant items?
• Do we have an excess amount of historical disclosure from years past?
• In the management’s discussion & analysis, is the analysis completed to an appropriate level? Is there discussion on items that are insignificant?

The spirit behind the box is that GASB was specifically thinking about material amounts and disclosures. It was not their intention to clutter the financials with what their article referred to as “nickel and dime” items. With more disclosure requirements on the way, now might be the time to think INSIDE the box.  

For more guidance on this and other GASB information, please contact Rob Smalley.