Methodology and the Project

Over the course of this chapter, we will delve into the myriad considerations to keep in mind when beginning an implementation of OneStream Software. We will discuss requirements gathering, along with design considerations, testing methodologies, and the different types of training that can be leveraged.

We will also cover important topics around defining scope, creating a timeline, and supporting your application after the implementation is done. Equally importantly, we will discuss Project Management in general, along with why a project manager is essential. Of particular interest to many will be discussions on different methodologies, such as Waterfall and Agile.

Of course, before any implementation can begin, the formalities have to be handled. That means a scoping session (or perhaps a few) is required to reach an understanding of the goals and deliverables of the project, as well as the conclusion of contract negotiations between the implementer and the customer.

Once the Statement of Work is created and executed between all parties, the project is officially funded and approved at all levels. By this time, there should be project managers for the implementer, as well as the customer, already identified; together, they will drive the project going forward until its completion.

Requirements Gathering

The Project Manager will drive the project after the SoW is executed and will get things started with a Project Kick-off Meeting that officially communicates the project initiation to key stakeholders, introduces the team, disseminates timelines, sets expectations, and generally gets the ball rolling. For OneStream Services and most OneStream partner implementers, this meeting is immediately followed by the Requirements Gathering Workshop.

Gathering the requirements of the system is truly where it all beings. Before a developer can write a single line of code, they have to have a design that they are working towards. However, before a design even begins to take shape, someone has to understand what the system is expected to do when it’s live.

Think of a custom home – a construction worker doesn’t just show up and start pouring concrete for the foundations and throwing up drywall. Before that happens, an architect draws up a set of plans that details every line of wiring, every pipe in the plumbing, and every light switch and fixture.

Before that architect can produce that first draft of plans, there has to be an understanding of what that home is expected to look like when it’s finished. How many square feet? How many bedrooms? Bathrooms? Garages (attached or detached), pool, and so on. Once that understanding is reached about the end-vision, only then can a design begin to take shape. And it’s only then – once the foundations of the design are in place – that a developer can begin to build the metadata, and the rest of the system can take shape from there.

It’s important to emphasize that a totally complete design is not required to start. Back to the custom home example; you don’t have to know what kind of ceiling fans you want in the living room or what kind of carpet you want in the bedrooms on Day One. You can decide that later. However, if you decide you want another bedroom once the foundations have been poured and the framing is up, you’re likely in for a world of extra cost and hassle as the builder tears things down and starts over.

What NOT to do…

It may seem obvious, but we sometimes need to remind customers that OneStream is a software company and not a process advisory firm.

While implementing the software, OneStream Services or other partners can provide guidance based upon experience, but OneStream Software limits its focus solely to the tool itself. There are other consulting firms, including OneStream partners, that can not only help implement the software but ensure the process is engineered for optimal efficiency. That said, we have seen things that drive better (or worse) results when implementing the software. One example is what I call a Lift & Shift implementation.

A Lift & Shift is where the customer wants to take an existing system (typically Oracle Hyperion or SAP’s BPC), lift its metadata (hierarchies, Chart of Accounts, etc.), then shift it over to ‘drop’ it into OneStream. While it sounds like a simple approach that is appealing at the outset, it actually exacerbates problems, many of which may be unknown at the time.

The primary problem with the Lift & Shift approach is that it leverages a legacy design that was created almost 20 years (or more) ago, and immediately ‘hamstrings’ OneStream with those limitations. In doing so, from the outset, the customer has missed out on a significant portion of the latest advances in technology that make OneStream the leading CPM software tool available.

While it’s fine (even advisable) to review what is contained within a legacy system, by no means does OneStream advocate replicating what was done before. Rather, use this new implementation to improve upon what was done previously. Identify pain points within a legacy system that OneStream can resolve as the requirements are captured and the design begins to take shape.

With all that in mind, let’s take a closer look at what is essential to understand and document during requirements gathering.

Consolidations

Implementations involving Consolidations of Actual financial results typically have scope that is better understood and more refined from the outset. That’s because Consolidations are usually crafted to satisfy internal management and external regulatory agency reporting requirements.

The most common (and effective) method to truly understand the core requirements of a Consolidation system is to begin with the end in mind by looking at the reports produced by the legacy (or current) system. Typically, these involve an Income Statement (or Profit & Loss Statement), a Balance Sheet, and a Cash Flow Statement. Upon reviewing these documents, many requirements should immediately become apparent.

Data

The driving questions that will guide the entire project are – what data is presented on these reports, and how is it used? One has to review the reports closely to understand the types of data, as well as the level of detail required, in order for OneStream to eventually produce these reports.

Are the reports limited to Actual results only? To what level are the results reported? Are they by period or only by quarter? What other levels of data are also included in these reports? Is there Department level data reflected as well? What about channel or product? Is Budget or Forecast data presented? If so, is it at a monthly or weekly level? Maybe it’s a rolling Forecast or an Annual Plan that is used to compare Actuals against.

One critical element to consider is prior years of historical Actuals – how many years of historical Actuals will be required in OneStream once the system is live and in use on a regular basis? Most publicly traded companies that report to regulatory agencies require at least three years of historical Actuals in the system. Some prefer additional years of history as well, while some private companies do not even require that much and can only get by with one or two years of history.

Regardless of how much history is involved, one consistent risk that I have observed on-EVERY.

SINGLE. PROJECT.

-is the underestimation of the amount of time needed to validate the historical Actuals in OneStream compared to what was previously reported.

Unfortunately, there is no simple rule of thumb to apply in this situation. There are simply too many variables in play that will drive the time required. For example, how complex is the mapping from the old system to OneStream? How many resources are available to assist with the validation effort? Were there any ‘offline top-sides’ (e.g., adjustments made outside the legacy system prior to reporting that were never captured within the data)? In this case, specifically, validating the data will prove to be very difficult indeed.

What is it? Where did it come from? How will it be used elsewhere?

Chart of Accounts

There are numerous elements to consider when crafting the Chart of Accounts within OneStream. The level of detail required may vary on whether the data is for Actuals or Budget. If Account Reconciliations are required in the future, make sure to allow for appropriate levels of detail and mappings to assist with that solution when it’s time. For that matter, look to see if there are already other Account Reconciliation tools, such as Blackline, Oracle’s Account Reconciliation Manager, or Trintech in use. If so, it would be ideal to load the deepest level of detailed data into OneStream, then map the summary level required for reporting to the Cube. (More to come on this during design chapters.)

Reporting Perspectives

What other reporting perspectives might be required for consolidating the financial results or reporting to management?

Obviously, some form of Entity structure will be required, and there is usually more than one such structure, also known as alternate hierarchies. The most common version is considered a Legal or Company Code hierarchy that would match the company’s legal structure required for reporting to regulatory agencies. However, there could be other hierarchies of the Entity structure that may be required as well, such as: Geographical or Regional, Cost Center, Department, Business Unit or Business Area, etc.

Beyond the Entity structure, what other reporting perspectives will be needed, whether now or in the future? (See Stubbed Dimensions for specifics). Do any of the financial reports contain customer level data? Would this information be useful while compiling Management Discussion and Analysis reporting? What about product-level details or data for segment reporting?

Foreign Currency

Unless the company is 100% owned and operated within a single country, there is a high probability that some form of foreign currency will be needed within OneStream.

Will local currency be loaded into OneStream along with exchange rates and translated into reporting currencies, or will it be loaded into OneStream pre-translated into the reporting currency from the General Ledger? If the former, where will the foreign exchange rates originate? Will there be a need for transactional currency to be translated to reporting currency? Is there a reporting requirement for constant currency analysis where current year results are translated against last year’s rates?

Complex Ownerships

If a company is not 100% owned, or all of its subsidiaries have NCIs (non-controlling interests), there will likely be Complex or Custom Consolidations involved. Depending upon how complex the calculations need to be, there might even be a need to use the Equity Control solution, which is a dedicated OneStream model that handles all ownerships between legal Entities.

For example, if Entity A has a joint venture with Entity B for Subsidiary C, then the Consolidations will likely be pretty simple. Depending upon whether the Equity Method is used, or if OneStream actually needs to calculate a percentage of assets and liabilities, the calculations are still going to be fairly straightforward.

Where it gets dicey is when Entity A owns 20% of Entity B, which owns 37% of Entity A, yet, Entity C owns 15% of Entities A and B. If they were done in Excel, for example, consolidating the Legal Entities would be difficult because the ownership calculations would want to create a ‘circular reference.’ Building this inside of OneStream is typically the best approach, so long as only the ownership percentages or shares change.

Intercompany Activity

What level of Intercompany activity is tracked today? Is Intercompany activity only eliminated at the first common Parent? Is transaction matching required?

Intercompany activity is a simple requirement to address when the source data has both sides of the transaction (the company code and its Intercompany Partner), and the mappings are straightforward. The most important thing to understand for Intercompany activity is the level at which it’s eliminated and the quality of the source data.

What about Intracompany or Intersegment activity? While rare, some customers have required the ability to eliminate activity within a single Legal Entity, but across departments or business areas. That requires a bit more effort during design, but it is definitely something that should be captured as a requirement from the outset.

I once helped manage an implementation on a legacy product at a company that had an enormous amount of Intracompany and Intersegment activity. One business unit sold a lot of product to another business unit, and the results had to be corrected accordingly. But the Entity Dimension was already in use for Legal Entities and the business units were treated as departments in another Dimension. The architect at the time came up with the brilliant idea of using the Entity Dimension to create an alternate hierarchy for departments and using the Entity Dimension to automatically eliminate the Intracompany activity.

Today, OneStream allows for multiple Entity Dimensions or can even create a separate Cube to handle these types of reporting requirements during design. However, the main thing to remember is to surface the need as early as possible, so that it can be incorporated into the design from the beginning.

An interesting footnote – that Architect works at OneStream today and continues to deliver simple but elegant solutions for OneStream customers.

Cash Flow Statement(s)

Cash Flows are a challenge for almost everyone. I’ll let the rest of the team discuss (further into the book) their experiences, but almost every project that I’ve been involved with has faced trouble with the Cash Flow Statement. If not in building it, then in tying it out versus prior reported versions.

When capturing requirements on Cash Flows, the first question to ask is whether it will be by direct or indirect method. What other formats will be produced as well – Free Cash Flow? Is there a specific version of the Cash Flow Statement for internal management versus external? Is the external version solely for GAAP, or is there one required for other reporting purposes, such as Bank Covenants?

Statistical Accounts

Accounts within OneStream are a wide-open playing field. Beyond what is loaded from the General Ledger, OneStream can calculate an endless variety of metrics and allocations as needed. For example, the customer may need calculations for Accounts Payable, Days Sales Outstanding, Accounts Receivable Turnover, Liquidity ratios, EBITDA, or a variety of other statistical or metric calculations.

The most efficient way to capture these requirements is to pore over the most recent reports and pull out those metrics that are commonly used, before creating an inventory of them (along with the logic, point of view, and source data), which can then be passed along to the development team during Requirements and Design discussions. They can raise any questions or delve into details that they find unusual.

Allocations

Allocations are what I consider to be statistical calculations on steroids. They can seem monstrous when first broached, but once they are fully understood and documented, it becomes a matter of coding and testing them.

As with Statistical Calculations, the most efficient way to capture requirements is to fully understand the logic upfront. What is the process around the allocations? Are they using the Step Method, where costs get allocated based upon a sequential process?

What is the basis for allocating the costs? Is it an operational data value, like machine hours? If so, where will that data come from, and how with it be loaded? Will cost be allocated based on headcount? If so, will the Human Resources system allow for access to the database to pull that data into OneStream, or will security requirements require the HR system to export specific data that OneStream will then import from a separate location, such as an FTP folder?

Allocations can definitely be handled efficiently in OneStream, but the development team should be asking these types of questions during requirements in order to understand what challenges await them during design.

Planning

Financial Planning and Analysis (FP&A) projects are where the rulebook gets thrown out the window. That’s because there are no rules in Financial Planning and Analysis.

Budgeting and forecasting other types of analysis are at the discretion of each company. A company may decide to use zero-based budgeting, or it may decide that a driver-based Budget is more appropriate. Business leadership may also decide to use a rolling Forecast of either 12, 18, 24, or 36 months. This is especially true when the business model is so complex that it takes so much time and effort to create a Budget, half the year has passed by, and it is no longer relevant. Or, perhaps the industry involved is so volatile that only six months can be reliably predicted at any given point and beyond that is truly a waste of resources. In either case, it likely makes sense to eliminate the Budget completely and focus resources on a rolling Forecast that is timelier and provides better accuracy.

In the end, it all comes down to what the business leadership team feels is the most accurate way to gauge and anticipate future business.

Financial Planning Areas

What financial components are typically planned, and at what level?

For example, a pharmaceutical company started their Budget by seeding the top 10,000 SKUs at the product level, then moved out into the various functional areas of the company.

Is the workforce planned in detail? Is it by role or by person? Are specific details – such as FUTA, SUTA, and fringe benefits – planned by each person? How are transfers in and out handled in the Planning process today?

Are projects currently planned in great detail? Some larger Oil & Gas companies will plan each and every property or region down to the lowest level of detail, including generators, pump heads, and other significant expenditures.

Does the company plan financial statements besides the normal Income, Balance Sheet, and Cash Flow Statements? Are the detailed plans by department or cost center? Again, the starting point should be what reports are currently used to drive operational business decisions? When looking at those, determine what data is on those reports, where did it come from, and does it add accuracy or value to the process of making business decisions.

Products and Scenarios

There are many other areas to consider when it comes to executing the Planning process.

For example, is there a need to plan on product detail or profitability level? If so, at what level of detail does the product or profitability analysis go down to? Is it down to the SKU level? Or only the product category or class level?

For that matter, what kinds of Scenarios will be required throughout the Planning process? Will there be multiple Forecast Scenarios? Multiple versions for each Forecast? Will they be saved for future analysis to compare the accuracy of the Forecasts versus Actual results? All of these requirements will drive the design in one particular direction or another. For example, say that you want to plan on a weekly basis, and there could be multiple versions for each Forecast. That will likely drive the use of User-Defined Dimensions for the weeks and versions to avoid data explosion in the Scenario Dimension. There will be more to come on that in the design chapters.

Modeling

Because of the many different types of disparate data involved, it could easily make sense to break a Planning process into multiple Cubes. You might have one Cube specifically for physical Net Sales, another for eCommerce Sales, another for SG&A, etc., especially if each of those operational areas goes into great detail within the Accounts or Entity Dimensions. One company has over three dozen models that they replicated within OneStream for their Long-Range Plan. This had to be split into multiple Cubes based upon common Dimensions, which then rolled up into a corporate level Cube for reporting. It was a tremendous amount of work, but they were ecstatic to get out of the world of Excel.

It is critical to get a comprehensive understanding of all the different types of data and reporting requirements involved throughout the Planning process(es). If this is actually done thoroughly, it will provide for a much better long-term design and maximize the opportunity for future growth within the application.

Management Reporting

Much like Financial Planning and Analysis, there are no rules when it comes to management reporting. Beyond the common EBITDA line, there can be no end to the custom requirements put forth by management in order to drive the business successfully.

Rarely, if ever, does management reporting align with generally accepted accounting principles. Obviously, this is because management has one set of numbers to report to external stakeholders, but they need an entirely different perspective of the business in order to make operational and strategic decisions.

OneStream can accommodate essentially all management reporting needs. The challenge is going to be getting a solid understanding of what those needs are likely to be in the system. As with everything else, the best place to start is with reports currently in use by the management team to make their daily business decisions.

In many cases, it can be as simple as an alternate hierarchy within the Entity Dimension or perhaps an alternate rollup of specific Accounts. On the opposite end of the spectrum, the management team may need a Dashboard of specific KPIs, which require data not found in your primary data sources. This might require a different means of getting data into the system, as well as creating custom Cube Views or Dashboards to present the information to the management team.

Account Reconciliations

Reconciliations between what was reported to stakeholders and the source data have become a much stronger requirement over the past 20 years. The market has exploded over that time with different software packages produced by other companies specifically to address the challenge of reconciling Accounts.

For some, this may not be such a major issue because they are only dealing with a few hundred Accounts. However, there are hundreds of companies in the world today that deal with literally tens- or even hundreds of thousands of Accounts that require reconciliations on a regular basis, sometimes monthly or quarterly. It’s these companies that start looking at software packages to help them streamline and maximize efficiencies in their reconciliation process and relieve the burden within their accounting departments.

For OneStream, Account Reconciliations are a natural fit because we have what is called the Stage. To maximize future flexibility, it is best practice to load all of the source data at the lowest level of detail. In essence, it should be loaded exactly as it appears within the General Ledger, including sub-ledgers for things like Accounts Receivable, Accounts Payable, etc. Then, the data is simply mapped via Transformation Rules to reflect what needs to be reported to stakeholders. While a company might have 10 revenue Accounts on their P&L, they might have hundreds in their General Ledger. Load all of the data into Stage and map it with Transformation Rules to only show the 10 Accounts in the Cube. Of course, all of that will be covered further in design chapters later.

As for requirements considerations for Account Reconciliations, one of the first things to think about is whether there should be a centrally controlled process or if it will be decentralized.

Additional considerations would include what currencies are reconciled for source data as well as reporting data, and whether Accounts can contain different currencies. How many reconcilers are there going to be, and how often will reconciliations be performed? Where will the sub-ledger data come from, and will it be within OneStream? At what levels are the reconciliations to be required? At the company level? Perhaps at the Department or Cost Center level?

These are the types of questions that will need to be answered when considering the use of Account Reconciliations for OneStream.

Tax Provisioning

Considerations for tax provisioning during requirements would really focus on dimensionality. If the plan, or even a strong possibility, exists to use OneStream for Tax Provisioning in the future, be sure to include any Dimensions required for that functionality early in the design. It will prevent a ‘bolt-on’ approach later, and allow for a more cohesive design of the application.

Task Manager

Task manager is one of the more straightforward solutions to implement within the OneStream Marketplace.

Before beginning to implement Task Manager, the best starting point is to document all of the processes that you will want to manage within Task Manager at the detailed level. You’ll want to have each task documented on a step-by-step level for the Task Name, Frequency, Start Time, Duration, Location, Task Action, Conditional Formatting requirements, Preparer and Approver (and/or Group), etc.

Are there any task dependencies that you will want to include within Task Manager? Are they inside OneStream, or will they need to be sourced from another system? Is there a need to integrate with other systems to import data or export task statuses? What kind of security will be required for the tasks, their status, and their owners?

As stated at the beginning of this section, Task Manager is normally a straightforward solution to implement. For OneStream Services, we typically allow three to six weeks for installation, configuration, and knowledge transfer to the customer. After that, the customer has all of the knowledge required to continue building out Task Manager for future needs.

Other Tools

OneStream MarketPlace has too many downloadable solutions to mention here. Some of the more popular ones are Analytic Blend, Relational Blending (such as Planning for Thing, Capital, Cash, People, and Projects, as well as Compliance Reporting), and Task Manager.

The top downloads fluctuate from one month to another, but the best approach is to discuss the options with your implementation partner for immediate or future needs.

Designing your OneStream Application

Many people, even those accustomed to legacy systems, still don’t understand that a good design isn’t just about creating good looking reports. They miss the opportunity to allow for future growth, or they don’t consider their stakeholders’ current expectations that will be transferred to any new system, particularly OneStream.

Goals of the Design

As previously stated, it’s impossible to overemphasize the criticality of gathering solid requirements for your OneStream implementation because they will feed directly into – and drive – all design decisions. Even before diving into the details, you need to start by identifying the ultimate goals of the OneStream application beyond any functional requirements. Beyond the types of Reports OneStream will need to produce, or the KPIs that need to be calculated, what other design implications need to be addressed as you’re uncovering requirements?

For example – will it be a global application that has to fit maintenance within a specific timeframe? Are there process windows or service level agreements (SLAs) that have to be met for the business on a regular basis, such as source data loads during month-end close that have to be completed within a one-hour time frame or by a certain time of the day? Do the stakeholders already know of an exorbitant amount of data that might pose a challenge to the application, such as saving dozens of versions of a Forecast for FP&A? These are all high-level goals that should be determined even before detailed functional requirements.

Application Sizing

The size of the application will be driven by many subjective and objective factors, which will be covered in later design chapters. However, you can determine early on if there are potential concerns to address during the design.

One example is the number of Members within Dimensions, particularly the Entity Dimension. A large Entity Dimension will – in turn – drive a very large Data Unit. This will have an impact on calculations, data management jobs, etc. A large User-Defined Dimension, such as products or customers, could also require considerations on the size of the application.

Overall, once you begin to see very large volumes of data and very high Member counts within Dimensions – yet these Dimensions are not all consistently used across functional areas of the company – consider breaking up an application that might grow too large now (rather than later) into multiple, smaller applications.

A case-in-point: an extremely large retail company has global operations, with brick-and-mortar stores, outlets, internet sales, and international business operations. Data volumes were expected to be millions of records per period just for the brick-and-mortar stores. Putting all of that data with drastically differing Dimensions across the different divisions would, in all likelihood, create future application sizing issues. Knowing this requirement early-on, the implementation team split the application footprint into multiple applications rather than one very large one at the outset, preventing a future rebuild in a year or two.

Application sizing also provides additional flexibility to manage the cloud or hardware resources by application. Even though it will still be a single environment, such as Production, having separate applications opens up additional settings for better segregation of resources at the application level. Be sure to check out the chapter on Design, where sizing and the factors that impact it are discussed in more detail.

Processing Times

Another common design goal for the application revolves around processing times. As mentioned earlier, you need to look at the business processes supported, as well as any SLA requirements imposed by the Business Users or IT.

A common process time requirement is where the financial reporting team needs data loaded within one hour of its availability from the source General Ledger. This is a critical goal to know prior to going into design. That alone could drive the decision to use multiple Cubes, or Extensibility, or both.

Along the same lines, if the Business Users are accustomed to a processing time today based upon a legacy system, such as running a data management job to create a new Forecast Scenario, knowing that existing expectation of time is also critical prior to going into design.

Task Automation

Throughout the requirements-gathering exercise, the implementation team should be driving the questions around which components of the process can be automated versus those that should be performed manually.

One example is when initiating a new Forecast Scenario – it should not require a manual step to actualize the new Forecast Scenario by copying all the Actuals for every period up through the most current period. That step is likely an automated task performed after-hours, so it is ready for the Business Users when they sit down at their desks the next morning.

There are literally dozens of tasks that can be automated within OneStream. They can be anything from data management jobs to copying a dataset from one source Point of View (POV) to another, or importing data from source General Ledgers, or even exporting data out of OneStream back into a data warehouse.

I have joked on numerous occasions that OneStream can probably even automate a customer’s coffee maker for them if they can find one that accepts the right commands. While it is indeed a joke, it is not too far from the truth either.

Task and Data Audit

One of OneStream’s strengths revolves around its ability to capture audit information throughout the application. Essentially, almost any task and any change of data can be recorded for analysis later.

As an example, perhaps this system suddenly experiences a drastic degradation of performance for no obvious reason. Because of task audit information, the Administrator can look to see what was happening at that point in time, on what server, who initiated the job, and if it was conflicting with other jobs.

If one particular job is running for an exorbitant amount of time, logging will enable the Administrator to trace a particular Business Rule that is taking too long to execute. Once isolated, the Administrator can optimize this Business Rule, therefore improving performance times.

Another Scenario could involve upper management asking why a particular number changed in the Forecast. Data audit capabilities will permit the Administrator to explain that a specific finance manager added 2% to the number on Wednesday evening.

The best recommendation on task and data audit is to consider prior questions and Scenarios that require significant effort to research. While it is possible to go too far with task and data audit information (which would involve filling the logs too quickly or possibly degrading performance if too intensive), strive to find a balance between capturing enough information versus too much.

Backups and Logs

OneStream has a multitude of options when it comes to backups and logs. For an on-premise environment, customers should discuss Disaster Recovery plans with their IT department. They should also discuss backup requirements from a business perspective, in case there is a risk of catastrophic system corruption during enough critical business cycles.

For cloud environments, such as Azure, backups are typically available on a minute-by-minute basis. Again, it would simply be a discussion with the customer’s IT group as to what those settings should be within the cloud environment.

Regarding logs, it is a best practice to keep logs at the proper level of detail to provide meaningful information to troubleshoot an issue, but not so much detail that the logs fill up too quickly and require too much maintenance.

Another requirement is to consider whether those logs should be sent to Administrators upon a critical failure. For example, when OneStream is attempting an automated data load, but another maintenance job is still running and locks up the tables that OneStream is trying to access, it might be a good idea to send an email notification with the log attached to Administrators, so that they can investigate the issue prior to Business Users discovering that the data load failed.

Testing Methodology and Analysis

Over the past 20 years, the biggest mistake that I see customers perform on an all-too-frequent basis, is when they don’t allow sufficient time to properly test what they’ve just built.

A salty Project Manager told me early in my career that I should allow an equal amount of time for testing as I did for the build. So, if it took three months to build an application, I should allocate an additional three months to properly test it from end-to-end.

When dealing with tight timelines and very limited budgets, that’s a tough stance to maintain. For whatever reason, customers will be willing to spend exorbitant amounts of time and effort testing an ERP, a Point-of-Sale system, or data warehouse, but they feel like an application responsible for reporting the financial results to their external stakeholders or managing the operations of their business should be rolled out with minimal testing.

We at OneStream cannot stress enough the need for good, solid, and thorough testing, as outlined in this section of the chapter.

Unit Testing

Unit testing comprises of the initial test by the developer before a development object is turned over for further testing. In this instance, it could be validating a calculation that provides the same results as an Excel model when given the same sample data. Or, it could be something along the lines of an End-User Report that matches a mock-up provided in Excel or PowerPoint.

Every object developed should be unit tested by the builder before it’s utilized in further development and testing. To do otherwise will cause delays and rework because errors and issues will be found later down the development path.

Integration / System Testing

Integration or system testing involves a complete end-to-end test that starts with the source data system producing the initial data – sometimes in the form of a flat file or triggering a data load in OneStream – which would then be integrated into OneStream. It might also include producing outputs to other systems as required, such as final consolidated Actuals or the latest driver-based Forecast to be loaded back into a data warehouse.

On numerous occasions, I have seen customers and partners push to reach a System Integration Test date before critical development objects are complete. In most cases, this results in a half-hearted system integration test with poor results that misleads the implementation team and stakeholders into a false sense of security. Again, it goes back to the concept of allowing enough time for good, thorough, proper testing, and the analysis of the results.

Data Validation

There is no hard data to back this up, but my estimation is that 8 out of 10 projects hit delays when it comes to validating historical data.

It is such a common risk to the project that OneStream Services actually include the risk warning in all of its Statements of Work when engaging with customers.

Over the last 20 years, I have heard multiple metrics bandied about for how much time to allow for historical data conversion. In one instance, it was one week for each period of historical data, yet in another instance, it became one month. In the end, there is no hard and fast rule. It simply comes down to the amount of data involved, the complexity of changes between the original Chart of Accounts and dimensionality compared to the new versions in OneStream, and the integrity of the historical data compared to what was actually reported at that time.

The integrity of historical data can often be the most challenging aspect of the data conversion process. Ten years ago, I spent six months guiding a customer through validating one year of historical Actuals. The challenge was due to the fact that, even though they had their data in a CPM system at the time, they had no governance on ‘pencil in’ entries prior to reporting them. These were last-minute changes to the financial results dictated by the management team just prior to publishing their reports. Consequently, there were a lot of adjustments that were sitting in an Excel file on someone’s laptop that never made it into the CPM system. Obviously, when my customer merged with another company, it made it very difficult to import the historical data from their system into the other company’s system without creating major discrepancies.

Some critical things to remember when it comes to data validation:

• Data reconciliation helps you build the tools you need to support Users.

  • The effort that comes with data validation drives a higher level of comfort and self-sufficiency with OneStream.

• It will uncover EVERY data issue.

• It is where most projects have cost overruns, stall, and struggle.

• More Data – More Problems…

  • The more history you load, the more problems you will uncover.

• As issues go down, complexity goes up.

  • Most common issues (mappings, hierarchy changes) are resolved early on in the first few periods validated, leaving the more difficult items for research.

• Documentation for Audit.

  • Be sure to confer with Audit to know what documentation they require prior to getting started.

Bottom line – be realistic and pragmatic when estimating how much time data conversion is likely going to require. If not, simply be ready to adjust your timeline once you get into that part of the project.

Centralized Data Validation

Each implementation’s process could be a bit different at the detailed level, but it usually comes down to the simple fact of comparing old data (from the legacy system or source General Ledger) against new data (what’s in OneStream).

Whether it is better to have a centralized validation process (where corporate does all of the work) or a decentralized validation process (i.e., the field or business units do a significant portion of the work) is open to discussion. There are advantages and disadvantages to both approaches, and it simply depends upon the corporate culture, the workloads already on the resources, and the demands of the project timeline. In either case, the process is essentially the same but merely distributed across different workgroups.

Assuming the OneStream configuration is compatible, a common approach is to create data extracts for raw year-to-date (YTD) historical data. OneStream Transformation Rules within OneStream would map the historical data from the source system into the newly created dimensional values within the OneStream application.

Once imported, passed through the Transformation Rules, and then finally loaded into OneStream, the validation process would begin.

Reconciliation Spreadsheets are the primary tool used to support the data validation process by facilitating the comparison of data between the source (the current Consolidation system or the manual Spreadsheets) and OneStream. Each Workbook would contain at least three tabs as follows:

• Tab 1 should contain the historical data from the source system.

• Tab 2 will pull loaded data from OneStream using the Excel Add-in.

• Tab 3 will compare the results of the first two tabs and calculate any differences.

A Test Results Tracker Spreadsheet will be maintained to log any reconciling differences identified during the data validation process. For each reconciling difference, several details should be documented, such as a description of the difference, the name of the individual who identified the difference, a description of the final resolution, how it was resolved, etc.

A Validation Tracker should be used to monitor the progress of the data conversion team by providing an overview of the status (loaded, validated, approved) for each Entity/Time period/ Scenario/Dept ID/product, etc., combination that is being reconciled/reviewed. This Excel Spreadsheet would be used to track the validation process and ensure that progress is being made.

The summarized process regarding historical data would look something like:

• Extract and load the General Ledger data to OneStream.

• Validate OneStream against the current legacy system.

• Load data from other systems or manual Spreadsheets to OneStream, segregating this data on different UD Members to keep it distinct from the General Ledger data.

• Validate OneStream against the Excel Spreadsheets. The process regarding go-forward data would be:

• Extract and load the General Ledger data extracted from the General Ledger to OneStream.

• Validate OneStream against the current legacy system.

• Book any adjustments necessary in the Consolidation system and repeat. Reports and/or outlines may also be used to facilitate reconciliation and validation. The following diagram would represent the Data Flow:

Figure 2.1

Figure 2.2

Validation Steps

The following table shows a typical data validation process:

Figure 2.3

When a period is ready for signoff, the conversion owner(s) should follow-up with the designated approver(s) to obtain a signature signifying that signoff has been completed.

When signoff has been completed by the designated approver(s), the Validation Tracker should be updated to reflect the ‘Signed off’ status of the data.

When signoff is completed, the final data extract, mapping tables, and converted data that has been loaded into OneStream must be saved as a final version. Additionally, the Entity should be locked.

Stub Period

The use of a Stub Period is similar in concept to a placeholder for Pro-forma reporting.

For example, in the case of acquisitions, there might only be a partial year’s worth of data available from the date of the transaction. Yet, you need to see how the company would have looked if the acquisition had occurred on the first day of the fiscal year.

In that case, you would load only the Actual results from the data of the acquisition into the Actuals Scenario. That would prevent skewing the reporting for Actuals in the future. However, then you would create an alternate Scenario, or Stub Period, to hold the extra data prior to the acquisition date. That would allow for a more meaningful analysis, as if the acquired company had been in place for the full year.

Without naming the companies involved, I once had a customer conduct a divestiture on an outdated technology, which is unfortunately still on the market today.

Due to secrecy, they could not even tell us the name, so we just called it “SpinCo” for “Spin Off Company”. We then spent months separating all of their data and functionality from the existing (multiple) applications. We also created a Stub Period Scenario to start tracking their data separately from the remainder of the company to give the Board and Executive Management the ability to see the ultimate results of the divestiture as it occurred.

Validating a Stub Period would follow the same process as any other dataset, such as Actuals. It would simply be a separate Scenario and for a specific time frame.

Local Currency Trial Balance

Usually, the first dataset to be validated is the local currency Trial Balance. That’s because it is the most pristine form of data available within both systems.

The Reconciliation Workbook would have the Trial Balance at the Base level of Accounts and Base level of User-Defined Dimensions by Business Unit or Entity for the legacy system, another worksheet for the new OneStream data, and a variance worksheet to show the differences.

Work through the first two or three periods of data to confirm that the mappings between the source system and OneStream are correct, and data is valid at the lowest levels.

Beyond mapping differences, variances are most certainly going to originate because of ‘pencil-in’ entries, or other data adjustments that never made it back into the original source data. Once the initial two or three periods have been completed, the root causes of these variances will typically either be corrected (such as a mapping update), or they will repeat themselves later in future periods and be easily found. Consequently, the later periods will usually be easier to validate because of known variances. Only truly new variance issues will arise in future periods.

Once the data is validated at the Base (lowest) level, move on to the Parent levels of Accounts and User-Defined Dimensions. There will likely be differences in subtotals, and Excel could be a useful tool to find common levels of sub-Accounts between the source and OneStream hierarchies. Again, once those first two or three periods are identified, and the Validation Spreadsheets are set up, the following periods should be easier.

Be prepared that there will be adjustments and entries to correct the Base level and Parent level data. Accounts or Entities move between hierarchies over time. Key metrics or calculations could have been changed over time, as well. It’s guaranteed that some kind of entries will be required.

The important thing, however, is to maintain focus on how OneStream should be built and configured for future use. Don’t go to great lengths trying to rebuild history within OneStream. It’s called history because that’s exactly what it is – history.

Once the local currency Trial Balance has been validated, moving onto the translated Trial Balance becomes a much easier effort.

Translated Trial Balance

Once the local currency Trial Balance has been completely validated, the Translated Trial Balance should be straightforward, assuming absolutely nothing has changed in the translation methodology. But what if it has?

If methodologies and/or hierarchical structures have changed significantly, it could create more challenges that make validating historical translated data impractical because the variances are too numerous and sporadic. In this situation, it could be simpler to load translated balances for historical data. Since OneStream can turn translation on or off as needed by period, simply disable translation for these historical periods. This should make the data much easier to reconcile.

However, since you’re putting in OneStream, this could be an ideal time to take advantage of a different translation methodology. Because OneStream can base its translation methodology on an Account-by-Account basis, you might vary whether you use a period rate or end-of-period rate based upon the Account. This leads us into Flows.

Flows

Flows are where you would expect to see differences with translations. Balance Sheet Accounts translate using the end of the period rate (month, quarter, year, etc.), but non-Balance Sheet Accounts – such as P&L and Cash Flow Accounts – would translate at the periodic rate. While OneStream can translate using both methods as needed, not all legacy systems can do so, and it could create variances accordingly.

Adjustments

Adjustments will occur. Simply be ready for them and definitely document them. They could occur for a number of reasons.

In many cases, it’s a one-off adjustment to align with a ‘pencil-in’ adjustment that was made to financial statements before reporting the results but which, for whatever reason, never made it back into the source system.

There could also be what are considered Period 13 adjustments; final year-end adjustments that are not attributable to a specific period within the fiscal year but are required before officially closing the books. Because some source systems do not have a dedicated Period 13, these adjustments are typically offline.

Along the same lines, many Accounts are translated at the end of the year rate, so the next year’s opening balance has to use the same value. Other Accounts use historical spot rates for translations, such as dividends declared. These would all require adjustments to ensure the data ties as it should.

Eliminations

Intercompany eliminations could pose unique challenges because of company restructures over time. Acquisitions, divestitures, joint ventures, and other organizational changes could all drive variances with Intercompany eliminations.

KPIs

Key Performance Indicators could reveal variances for a variety of reasons – the most common of which are changes to a Chart of Accounts. In a legacy system, a KPI such as EBIT (Earnings before Income and Taxes) might have changed due to reclassifications above or below the Net Income line on the Income Statement. Perhaps KPI calculations used two years ago were recently deemed irrelevant and are no longer in use. Or maybe the algorithm was altered at some point.

Allocations

Allocations could reflect variances due to the same reasons as KPIs. Perhaps source data or mappings changed, or perhaps the algorithms were modified.

During development, the allocations would have been unit tested based upon sample data or historical data. One method to validate allocations in a detailed manner is to create a separate Spreadsheet specifically for allocations that compares manually allocated amounts (created by using source data and Excel functionality) against OneStream results. In this approach, if there is a variance, it would be easier to trace because all of the data elements feeding into the OneStream would be easily visible within the manually calculated formulas.

Go-Forward Actual Results

Because the go-forward Actuals won’t actually have any historical perspective for comparison, the best way to validate them is via Parallel Testing (covered later in this chapter). In this approach, the OneStream-created results are compared to similar results for the same period produced by the legacy system. Known variances at the detailed level would be accounted for due to prior data validation efforts and known differences between the two systems. Any remaining unexplained variances would then be investigated for resolution.

Centralized vs. Decentralized

As previously mentioned, data validation can be performed via a centralized or decentralized approach. One thing to consider for each approach is the level of knowledge expected by different workgroups.

For example, if Field Users need to be comfortable within OneStream, they should be involved in data validation. That’s because working within the system – e.g., multiple cycles through working within the application, going in and out of OneStream, investigating variances, troubleshooting calculations – will create a comfort level thanks to familiarity with the tool.

Conversely, if the Field Users are going to have minimal involvement with OneStream and only put data into the system with a Form, yet Corporate Users are going to be heavily dependent upon OneStream and need to be intimately knowledgeable on its functionality, then a centralized approach would make more sense.

Either way – consider the primary groups of Users that will need the most training and leverage these resources for data validation. While tedious and time-consuming, it’s difficult to underestimate just how much benefit the hard work of data validation brings through hands-on training.

One other consideration when determining a centralized versus decentralized process is the corporate culture in play. Is it more corporately focused, where most decisions are driven by the main office and pushed out to the various business units? Or are the business units and Field Users more accustomed to various levels of autonomy? Does the corporate accounting office have a significant degree of trust towards the Field Users who will be validating their data? These are all factors that need to be considered when selecting the most efficient and appropriate process for data validation.

Rollforwards in Local Currency for Current Year

Rollforwards in the local currency should be simple to validate. You’re simply looking at the prior period balance sheet versus the current period, and validating the difference at the local currency level.

This can be addressed with a separate Workbook in Excel with those calculations. Since there’s no foreign exchange in play, the calculations should be very straightforward.

Budget & Forecast

Budget and Forecast numbers can be validated in the same manner as Actuals. However, because they’re not typically at the same level of detail as Actual results, a separate Excel Workbook may be required to address the different levels of detail for the Charts of Accounts.

Alternate Exchange Rate Scenarios

Alternate Exchange Rate Scenarios use other Exchange Rates to see the results in different currencies. In the United States, they’re called Constant Dollar Scenarios.

The main purpose is to remove any foreign currency impact from the financial results, thus leaving true operational and economically-driven activity, and not skewing the results due to fluctuations in currency rates.

For those new to the concept, an example of this is a company that has operations in a country with a volatile currency. Reporting Venezuelan operations has been a challenge over the last few years because it is difficult to discern what results were because of the company’s performance versus intense fluctuation in the Bolivar in recent times. By using an Alternate Exchange Rate Scenario, you can put all of the local currencies into a common currency and view the results without any foreign exchange impact.

Validating these Scenarios leverages an Excel Workbook once more. Using an Excel sheet to capture the results in local currency and another to calculate them in the common currency (USD or EURO, for example), you compare the results of the calculated common currency versus the OneStream calculated results. The main concern is to use the same exchange rate methodology and exchange rates in both sets of calculations to remove any variances.

Validation of Outbound Data Integrations with Other Systems

Outbound data integrations for other systems require some ‘out of the box’ thinking, as there is no one-size-fits-all approach.

The main concept is to get to the appropriate level of detail being exported before comparing it to a similar level of detail from a legacy system or data created offline.

For example, if post-consolidated Actual results are exported back into a company’s data warehouse for other reporting needs, use Excel worksheets to compare against a legacy system’s results. The challenge will be getting to a true comparison since, as with historical data, the legacy system will have differences in hierarchies, mappings, etc.

User Acceptance Testing

User Acceptance Testing (UAT) gives End-Users and stakeholders their first comprehensive opportunity to work with the system. UAT scripts should be representative of normal activities that would occur during the business process, such as importing data, validating data within a system, running Reports, putting in adjustment entries, etc. The primary goal of UAT is to ensure the application meets all the functional requirements of the End-Users, and provides them with the opportunity to provide feedback prior to deployment.

The UAT test group should be Users that will use the system on an ongoing basis, with the required functional knowledge. They should have expertise, and be in the best position to determine if the application satisfies the functional requirements.

UAT scripts ensure consistency with the testing and confirmation by the Business Users that they would satisfy the functional requirement. Once completed, they would also serve as documentation for what was tested, considered acceptable, and made ready for deployment.

Defects or issues are captured in an issue log and remediated after UAT is complete, but prior to deployment. Any issues that are considered out of scope or future enhancements should be prioritized for future development and included in a subsequent release.

One common delivery method for UAT is to conduct it in a War Room setting, meaning a conference room where everyone is going through scripts together, allowing the development team to answer questions as needed.

Before UAT begins, the development team should clearly identify and document the entry criteria, dependencies, and exit criteria.

The following entry criteria need to be satisfied to begin Testing:

• Successful completion and sign-off of previous test cycles (Unit Test and SIT). This includes the finalization of any remediation activities.

• If Performance Testing was done, this test cycle has been completed successfully.

• The testers have been identified, contacted, trained, and informed of their roles and responsibilities for the test cycle.

• Test conditions, Scenarios, data requirements, and test scripts (with detailed expected results) have been finalized, cross-validated against requirements, and agreed to by Project Management.

• Test Cycle Control Schedule (including schedule of test script execution) has been completed, approved, and communicated to the test team.

• There is a clear cutoff of application development and data import/validation before UAT begins.

• Historical data has been validated through the period(s) to be used in UAT.

• All Reports that OneStream is responsible for building have been completed, and unit tested. (Recall that only a representative list of Reports was tested during SIT.)

• Strictly enforced change control process to track and assess the impacts of changes to application development and data import/validation versus UAT conditions.

• A representative set of access IDs and passwords for testers have been setup, validated, and communicated.

• Required infrastructure is in place and ready to support test analysts (e.g., desktops, printers, etc.).

• Fully-defined, trained, and approved Issue Management process.

• Access to Test Scripts has been granted for all relevant Users.

• All required test documentation has been loaded into appropriate project folders or testing software.

• Identification of a POV to use for testing (Cube, Scenario, Time, Entities).

Tests should follow the expected activities that Users will perform during a business process, which could include performing the following tasks:

• Update metadata.

• Update Member formulas and Business Rules.

• Create a Test User per Workflow Profile and confirm User’s functionality.

• Run Cube Views, Forms, and Reports.

• Perform data import, validate, and load.

• Input data on a Form.

• Run Reports.

• Open Journal period in OneStream.

• Create, approve, and post Journal Entries.

• Run a Journal Report.

• Run an Intercompany Matching Report.

• Process the Cube to calculate, translate, and consolidate data in OneStream (i.e., run calculations) and test the results of calculations.

• View data using Excel (Cube Views, Quick View). The following is a sample test plan for UAT:

Figure 2.4

Roles and Responsibilities

Below are the roles and responsibilities of the team members:

Figure 2.5

Exit criteria define the successful conclusion of the test cycle. The exit criteria include:

• Each data integration should achieve a minimum of 90% accuracy versus expected results.

• Performing allowed tasks in each Workflow Profile should achieve a minimum of 90% accuracy versus expected results.

• Completed test scripts with notes.

• Source files and screenshots providing proof of testing and results.

• Test scripts related to resolved issues have been retested, and results have been updated.

• All planned test conditions and Scenarios have been executed or determined to not be on the critical path.

• All issues have been documented and assigned.

• Issues that have been prioritized at Critical and High severity levels have been resolved or have a defined action plan for resolution.

• Changes to procedures due to workarounds, etc., have been identified, and process documentation has been updated.

• Test scripts and cycle close memorandum have sign-off, completed by the OneStream testers, Customer reviewers and Test Coordinator, and Project Manager.

Load Testing

Due to proprietary coding within the OneStream Engine, commonly used load testing products such as LoadRunner are incompatible and cannot be used for OneStream implementations.

Consequently, OneStream has created a free solution available on Marketplace called Load Test Suite, which replicates a typical End-User process.

For example, it could consist of a Workflow to import, validate, and load the Cube with data, as well as run a Consolidation. This Workflow can be used to simulate dozens or hundreds of Users on the system at one time.

When considering load testing, be sure to have realistic targets set from the beginning. Define success beforehand in order to understand what is achieved.

Parallel Testing

Users perform tests necessary to take the system live. They continue to operate primarily in the legacy system performing their normal activities, but then repeat the same activities in the new system. Results between the two systems are tied out, and any defects are noted. Scripts are not used for parallel testing.

Entry Criteria / Dependencies

The following entry criteria need to be satisfied to begin Testing:

• Successful completion and sign-off of previous test cycles (Unit Test, SIT, and UAT).

• The testers have been identified, contacted, trained, and informed of their roles and responsibilities for the test cycle.

• Test conditions, Scenarios, data requirements, and test scripts (with detailed expected results) have been finalized, cross-validated against requirements, and agreed to by Project Management.

• Test Cycle Control Schedule (including schedule of test script execution) has been completed, approved, and communicated to the test team.

• Clear cutoff of application data validation activities.

• Strictly enforced change control process to track and assess impacts of application changes versus test conditions.

• All data integrations have been built and tested.

• All historical data has been loaded into the application.

• The customer has completed the validation of all historical data.

• All Reports have been completed, tested, and signed-off.

• All Users have been trained.

• Security testing has been completed, and 100% of End-Users are able to login with appropriate rights.

• All Users who normally work on the Close should have valid IDs and passwords; this information should be communicated in advance, and Users should verify that they are able to logon.

• Required infrastructure is in place and ready to support test analysts (e.g., desktops, printers, etc.).

• Identification of a POV to use for testing (Cube, Scenario, Time, Entities).

• Fully-defined, trained, and approved Issue Management process.

• All required test documentation has been created.

Datasets and Flow Models

Parallel testing requires that a full data load (all Entities) be loaded to effectively simulate an anticipated real Close.

Test Plan

A sample test plan is as follows:

Figure 2.6

Roles and Responsibilities

Figure 2.7

Success / Exit Criteria

Exit criteria define the successful conclusion of the test cycle. The exit criteria include:

• Each data integration should achieve 100% accuracy versus expected results.

• Performing allowed tasks in each Workflow Profile should achieve 100% accuracy versus expected results.

• Test scripts related to resolved issues have been retested, and results have been updated.

• All planned test conditions and Scenarios have been executed or determined to not be on the critical path.

• All issues have been documented and assigned.

• Issues that have been prioritized at Critical and High severity levels have been resolved or have a defined action plan for resolution.

• Changes to procedures due to workarounds, etc., have been identified, and process documentation has been updated.

• Test scripts and cycle close memorandum have sign-off completed by Testers, Customer team, and Project Management.

After parallel tests have been successfully completed, the system can go live. For a month after go-live, OneStream will provide post-implementation support to ensure the success of the go-live.

Training and System Documentation

Training

Training is just as important (if not more so) than the other phases of the project. Even if the design is beautiful, the build of the system went perfectly, and all of the testing was flawless, none of it matters if the Users can’t leverage, or refuse to adopt, the application. The key to ensuring that they do so is training.

Types and Delivery

There are multiple ways to deliver training, which can be outlined below:

• Custom training – involving OneStream or partner-led classes entirely customized for the User audience. Customer Administrators would not lead the training and would answer questions from the User community at most.

• Train-the-Trainer – where OneStream Services or the Partner would teach Customer Administrators or Super-Users to be the trainers for the broader End-User community. Documentation would be produced as needed, as a part of the initial training phases. Typically, the first training class is training the Administrators and the Super-Users on the system, as well as teaching them how to convey the information to the User community. This is by far the most common approach seen on OneStream projects, due to its low-cost approach.

• Combined UAT/ Training – a time and cost savings approach that would combine User Acceptance Testing with training. The rationale is that on certain projects, the same End-Users required for UAT will also be the ones that require the training. It’s an easy way to save at least a week, perhaps more, on the project timeline when you combine UAT and training into a single session, not to mention cost savings as well. Lastly, it is also much easier on End-User schedules because they don’t have to help with separate sessions for UAT and then training.

Given the advances in today’s technology with online meeting services, all of these training approaches could potentially be performed entirely remotely. However, there is a tremendous value in having the Users in a single room with trainers and Administrators walking around and assisting them as they have questions or encounter an issue. While potentially more challenging logistically, it is typically a more efficient and value-added approach.

Audience Determines the Approach

As previously discussed, the audience is (or should be) the ultimate driver for which type of training is most practical.

For intensely intricate systems that involve unsophisticated End-Users, a custom training class led by the consulting team could be a more practical approach, especially if the company Administrators and Super-Users are not comfortable and confident with their teaching abilities and knowledge of the system,

Conversely, more straightforward applications with knowledgeable and sophisticated End-Users should likely leverage a Train-the-Trainer approach. Why spend the additional time, money, and energy to create custom classes if the company Administrators and Super-Users can convey the knowledge to the End-User community?

If time is of the essence and cost is a driving factor, then consider combining UAT with training. This is especially true if people have a difficult time pulling away from their day jobs. It will prove easier getting everyone into a room for a single session of a few days than hoping to coordinate everyone’s schedules for several separate UAT and training sessions.

System Documentation

System documentation can vary depending upon the implementation partner and the requirements of the application. OneStream Services, for example, delivers an Administrator guide at a minimum. There could be other forms of documentation, such as training documentation, rules documentation within the application, data integration documentation, etc.

The main thing to remember is that customers should have sufficient documentation from the implementation partner to be self-sufficient after the project is over. This should be discussed prior to the beginning of the project. Customers should also be sure to get the documentation required prior to implementation partner consultants moving on to other projects. It’s extremely difficult to come back six months after the project is over to write documentation that was forgotten or not needed at the time. It might also be almost impossible if the consultant involved has left the implementation partner altogether.

Managing the Implementation

Identify your Team

Once the software selection process is complete, and the obvious answer reveals itself to be OneStream, the next step is to choose who will help implement the software.

Choosing an implementation partner, as well as the internal company team, are the most critical decisions once the software has been selected. Consequently, each deserves a little further discussion about them.

Choosing a Partner

In the beginning, when OneStream was just emerging onto the market, implementation partners were not as plentiful. Now that OneStream has become a market leader in the CPM space, there are literally dozens of partners available for consideration. But what should you keep in mind when looking at your implementation partner candidates?

To be clear – OneStream places an extremely high value on their partner community. Accordingly, we have made a tremendous investment in the creation of support infrastructure for our partner community. As a member of management for OneStream Services, I can say with confidence – and intimate knowledge – that we have a phenomenal group of partners and any customer of OneStream should feel confident in whichever partner they choose.

Regardless of whether it may be OneStream Services or another partner under consideration, you will want to look at various factors to base your decision upon:

• Partner Certification Level – the higher the certification (Diamond, Platinum, Gold, Silver), the greater the experience and track record of successful projects. However, this successful reputation may come at a premium price.

• Professional Certifications – the better implementation partners will include various professionals within their consulting ranks, such as CPAs, PMPs, MBAs, etc. Seeing professionals within their implementation team shows a willingness by the partner to invest in quality talent within their organization.

• OneStream Practice – a reputable partner will have a dedicated practice of consultants specifically for OneStream. By practice, I mean more than two or three consultants. While there may be very small partners within the community, their smaller size limits their flexibility when resource constraints arise.

• Industry Experience – the better partners will come to the table with a breadth of experience and knowledge across multiple industries. That is simply the nature of the consulting world. Projects will invariably involve retail, services, manufacturing, and a host of other industries. It is specifically for this experience and knowledge that most customers will choose a particular implementation partner.

• Strength of Team – you are choosing a partner to be a trusted advisor, not just do whatever they are told. Your partner should be ready, willing, and able to tell you if something you want is a bad idea. They should also be able to give you alternatives. Do yourself and your company a favor – listen to them.

OneStream Software can certainly offer some suggestions for implementation partners as a part of the software sales cycle. Yet, it is ultimately the customer’s responsibility to make the decision based upon their comfort level and assessment of each partner. Be sure to give it the consideration that the decision is due.

Administrator

Just as with the implementation partner, choosing the company’s Administrator for OneStream is a critical decision – actually more so – since the implementation partner will only be on the project until the system is in production. The Administrator, however, will remain in place for the foreseeable future and be responsible for the maintenance and future growth of the OneStream platform. Obviously, this role is critical for the future of OneStream in each of its customers and there are a few things worth mentioning when choosing one.

• Technical Aptitude – this doesn’t mean that the candidate can program in seven coding languages and understand how IBM’s Watson performs its magic. Rather, the candidate can program in VB.NET or has the ability to learn to do so.

• Business Acumen – conversely, the candidate does not have to be a CPA. However, it will be very helpful for the Administrator to understand the difference between an Income Statement and a Balance Sheet. Also, how does a Cash Flow Statement work? Do they understand when an accountant says that last year’s Net Income doesn’t roll to Retained Earnings correctly? Will they understand the drivers needed in the system to calculate Net Sales for next year’s Budget? It is not an easy skillset to find.

• Problem-solving – An Administrator will also require an analytical mindset that can troubleshoot problems in a structured manner. Invariably, issues will arise: a mapping change is required that was not communicated before data was loaded, a new Account was added in the source General Ledger but not to OneStream, an End-User is frustrated because they cannot understand where data in the system originated. These are only a few examples that an Administrator will chase down when they are responsible for the platform. They will have to have the proper mindset and attitude in order to do so.

Finding a solid Administrator requires an investment in training and a patient attitude. They cannot be expected to become OneStream experts in a one-week training course. Identify the Administrator before the project begins and send them to proper training prior to the Requirements and Design phase. This will allow them to have maximum exposure to the consulting team, as well as the decisions made for the system they will support in the future.

Define the Scope

Properly defined scope (the body of work to be constructed) is one of the core elements of a successful project. There are multiple factors to be considered when determining the scope prior to the start of the project.

Back to the house analogy – you don’t sign a contract for a builder to show up on Monday and begin to pour the foundations, build the walls, add the roof, and pave the driveway. Before all that happens, a general understanding regarding the size of the house, the number of rooms, if it will have an attached or detached garage, a finished basement, along with a host of other decisions, needs to be made.

For a OneStream project, there should be an understanding of what will be built, even if at a high level initially. Is this going to be a Consolidations system to help close the financial books and report to investors? Or maybe a Financial Planning & Analysis system to create next year’s Budget and weekly Forecasts? Perhaps an Account Reconciliation tool or a solution to help plan at the resource level? Should it be all of the above? Let’s dig into that...

Roadmaps

Roadmaps are multi-phased initiatives that lay out a vision for a longer-term program. Rather than a Ready-Fire-Aim approach, where the first phase might be a Consolidation solution, potentially followed by a Planning solution (but not sure whether it will be a Budget or Forecast), a Roadmap actually reviews the business environment and determines a phased approach.

A classic approach with the Roadmap is for an implementation partner to look at all of the business processes and their current states. Afterward, the team will then listen to future business objectives and goals to craft a future state of recommended processes across the functional areas. Finally, a gap analysis will show what will be required to move from the current state to the future state.

This gap analysis will become the program.

Done properly, Roadmaps can provide enormous value. They give business leaders an idea of what they’re signing up for, the resource requirements for the duration, an estimated cost and a specific set of milestones to show progress along the way. Because the team begins the first phase with the future vision in mind, they also minimize the risk for rework because a future requirement was not considered. By having the end state in mind, the implementation team has as much information as possible to properly design the system for future growth and scalability.

Implementation Size vs. Complexity

There are multiple constraints on a project with inverse relationships. This means as one side increases, the other side has to decrease. One such example is with implementation size versus complexity.

There have been countless occasions in the past where a customer wishes to implement a highly complex, very robust, and powerful solution that could include 4, 5, 6, or more solutions within the application. Yet, once that scope has been properly estimated, and they see the size of the implementation, sticker shock sets in.

The bottom line (literally) is that with complexity comes more effort. If a customer already has a well-staffed and highly-skilled OneStream department within their organization, a lot of that effort can be assumed by that team. However, that is rarely the case. Consequently, if the work is to be done, it will have to be done by the consulting team.

If budget is a deciding factor (and it usually is), keep the complexity of the solution in check as scope is defined. Doing so will likely prevent instances of sticker shock later down the road.

Timeline vs. Functionality

There have been multiple instances over the years of the customer who wants to do everything under the sun within the first phase. In essence, they want to ‘boil the ocean.’ If the implementation partner doesn’t put on the brakes, the project team will – for lack of better wording – bite off more than it can chew.

When considering scope, keep it reasonable. Don’t start a project expecting to achieve a Consolidation solution, a Budget solution, Account Reconciliations, and People Planning, where each of those solutions are infinitely complex and require significant resources.

For example, if the timeline available is only four months, it is simply not enough time to put in an extravagant driver-based Budget, with Planning at the resource level, along with Capital Planning, as well as Cash Planning. The timeline is simply too tight.

Instead, focus on what functionality can be delivered within those four months based upon the priority communicated by the stakeholders. Perhaps for this Budget cycle, start with only the driver-based Budget. Another option would be to allow input Forms for Budget numbers at the Base level, which can then be aggregated, and use the extra time to implement Cash Planning.

In the end, the balance must be maintained between what functionality can be reasonably designed, built, and tested within the time allotted.

Stakeholder Involvement

The ultimate key to any successful implementation is managing expectations, especially those of stakeholders.

Stakeholders are the ultimate customer, not just for the consulting team, but for the customer implementation team as well. Within the customer’s organization, the stakeholders are the ones who will ultimately decide if OneStream satisfies their needs.

One of the worst things that can happen on a project is for the team to reach UAT, only to be told by the stakeholders afterward that the system will meet none of their actual needs. The only real way this can happen is if the stakeholders were kept in the dark during the build and test phases. Yet, without their involvement on a regular basis, how can anyone be sure that the project is going to meet their needs at the end?

For OneStream Services, we regularly leverage what we call conference room pilots. These are typically for a couple of hours every three weeks or so. They serve as an opportunity to hold checkpoint meetings with the stakeholders to ensure the implementation team is on the right track, and that the stakeholders continue to feel that the system will meet their needs in the end.

The adage that we often hear is: “Involve the stakeholders early and often.” Over the course of many years, and multiple projects, I have never seen that fail to be successful.

The Holy Triad – Scope, Time, and Resources (Budget, People)

The balance that every project manager in the project team strives for is between three equally important components on every project.

• Time – the overall project schedule

• Resources – people or funding

• Scope – the solution to be built and the work to be performed

The challenge is that if one is increased too much, the other two will begin to suffer.

For example, increasing scope (multiple solutions within a single phase) will either require more time or more resources to achieve those results. By adding the additional work in scope, there is a corresponding need for either more time or more resources to get the work done.

From another angle, what if resources were suddenly to become scarce? Say, two key people left the project team. If the timeline doesn’t change, and no other resources can replace the departing people, then the scope will have to be reduced. It is not realistic to expect a smaller team to deliver the same amount of work within the same timeframe than what was originally expected. If someone were to attempt to force the smaller team to achieve the same results on the original schedule, the most likely outcome will be a substandard work-product, or the team will simply implode.

Always seek a balance between the resources available (either funding or people), time, and scope. In the middle, as shown in the diagram below, is where you will find the best quality.

Figure 2.8

Create a Timeline

A case in point for balancing the holy triad is when it comes to creating a timeline. The timeline can either be driven by scope and resources, or it can drive scope and resources itself.

If scope is the most important factor and resources are fixed, then the timeline will have to be flexible accordingly. However, if the timeline is fixed (for example, an upcoming annual Budget cycle in four months), as is resources, then the scope has to be flexible.

The question to be asked before the project even begins is – is there a specific timeline driving the project? If so, then your timeline is fixed, and you then determine what scope can be achieved within the timeline with the available resources. If there is no fixed timeline, then scope can become the primary driver.

Requirements and Design

Requirements and Design phase can take as little as one week or as much as three months (or maybe even more). It all depends upon the complexity of the solution within the scope.

I was speaking with Mel Lenhardt recently about Requirements and Design, and he put it perfectly. In essence, he said there is both a science and an art to building an application. I would wholeheartedly agree.

The science involves those items that have to be confirmed and documented during Requirements and Design meetings. Things such as:

• Dimensionality

• Extensibility

• Metadata structures

• Workflows

• Data (Inbound and Outbound)

• Other items

All of the above, if they should change significantly half-way through the build, would require significant rework.

For example, imagine the application has been built, data has been loaded, and the team is working on Cube Views when suddenly a new requirement surfaces to add an entirely new Dimension to the application and the Cube. Of course, it can be done, but there will be a lot of rework entailed to rebuild data sources, reimport data, rework the Workflows, etc., etc. Get a firm understanding of those items early on to prevent rework later in the project.

Items that do not necessarily require confirmation from the outset fall more into the presentation area – “The Art” as my friend Mel would put it. These would include:

• Cube Views

• Dashboards

• Forms

• Some calculations

These types of presentation items can certainly be defined at a high level, but do not require a detailed understanding beyond the data that would appear on them.

In summary, it is common to ‘rush’ the Requirements and Design discussions, especially if the timeline is fixed and things seemingly start off a bit late. However, a safer approach is to allow extra time instead to ensure all topics can be thoroughly discussed, key decisions made, and everything documented prior to writing one line of code. If the requirement and design are completed early, then it becomes a pleasant surprise, and now there’s extra time to move into the build. This is a much better situation to handle than the alternatives.

Build

The build itself (creating the app and metadata, creating data sources and importing data, creating Cube Views, etc.) can vary drastically by project. It depends upon a number of factors, such as:

• The number of alternate hierarchies

• Data sources and their complexities

• Calculations and/or allocations

• The number of Workflows and their associated steps

• The number of Cube Views and Dashboards

• Security and other items

Of course, all of this could be a very large body of work that will require significant effort. However, with sufficient resources (people), the work can be divided up, and the timeline accelerated.

Test

There are two distinct areas that are commonly reduced when the budget begins to tighten: project management and the test phase.

A safe approach to most projects is to allocate and budget the same amount of time and effort for Testing that was estimated for the Build phase. Consequently, if it required three months to build an application, plan for three months for Testing. This would include Data Conversion and Validation (covered earlier), SIT (System Integration Testing), User Acceptance Testing, Parallel Testing, potentially performance testing, as well as remediation time for any issues uncovered during the various tests. If that time is ultimately not needed, then the project will finish early and under-budget. That’s better than the alternative.

Keep in mind, the more testing performed, the more errors and issues that can be resolved prior to the End-User community using the system. This will drastically preserve integrity in this system for the User community and increase system adoption.

Rollout

In order to estimate the amount of time required for rollout, you need to consider the efforts required for migration, the amount of training required, and the logistics involved. These three items are the primary efforts during the Rollout phase.

For example, with training, how many Users will require training? If you break those Users into groups of 10 or 12 per class, how many classes will that require? How many trainers will be available? Are they all in a single country, or will there be global travel required – which will need to be scheduled? How much and what type of training documentation will be used (which requires time to create)? All of these questions will drive the training portion of the rollout phase.

When it comes to migrations, this is heavily dependent upon the customer’s corporate and IT policies. Many customers have rigid and formal policies around testing, certifications, and approvals, as well as intricate deployment processes that must be followed before an application is considered in production. Other customers can consider an application in production simply by changing the name of the application.

We have seen some projects with a three-week rolled out phase – two weeks for training and one week for migration. On the other extreme, there have been projects with three months due to extensive training with multiple classes across several countries, as well as complex and rigid migration policies. Like everything else with a complex project, there is no easy answer. All of the factors mentioned above must be considered when creating a timeline for the rollout phase.

Planning to Support Your Application

Great. Awesome. You are now live on OneStream. Yet, how will you maintain it and troubleshoot issues as they arise going forward? Let’s look at some options.

Center of Excellence Model

The Center of Excellence (CoE) model involves a team of core individuals – from various functional areas – managed under a centralized model that is dedicated to the support of the OneStream application.

This team could be comprised of representatives from Finance, Accounting, IT, and Audit, as well as any other functional areas that would be directly impacted by the OneStream application.

The reason that this model can be so effective is because it revolves around a core team that is dedicated to supporting OneStream as their primary responsibility rather than doing it on a part-time basis. Because they are focused solely on supporting OneStream, they will provide thought leadership and best practices across the enterprise.

They can also provide a better ROI by performing research and development to understand how to best maximize the value of OneStream. For example, the CoE will immediately understand and recommend using OneStream when an Account Reconciliation tool is needed, rather than investing in a separate SaaS offering that will cost the company additional money.

IT Support

Other companies prefer to focus on their support solely through the IT organization. This may be a good approach depending upon the resources available within IT. The challenge with a pure IT-support model is that it is heavy on the technical skillset and light on the business knowledge.

Stakeholders will have difficulty explaining the requirements to a code-oriented developer. Make no mistake – a developer with technical skills is essential for the support of OneStream. However, there also has to be some element of business knowledge, as well. If that skillset can truly be provided from within the IT functional area, then this support model has a good chance of success.

Admin/Functional Support

An Administrator model is seen most frequently at OneStream. The Administrator will attend training prior to the start of the project in order to take full advantage of knowledge sharing and learning opportunities during the Requirements and Design sessions.

As covered previously in this chapter, an Administrator should have equal amounts of technical skills and business acumen. As the implementation is underway, they will be learning and absorbing knowledge from the development team that will become essential after the application is live.

For smaller customers – and many larger ones – the Administrator model is the most practical approach to supporting OneStream in the future.

Managing the Project

In my opinion, formed over the last 20-odd years, Project Management is often the most underappreciated aspect of project implementation. During the project estimate, as the business stakeholders want more, the scope increases, and the cost goes up, the initial place that people look to cut costs is within the project manager role. Time and time again, I have seen this come back around later in the project to create more issues and cost more money than if the project manager role been left intact and someone was truly in charge at the outset to minimize risk and address issues as they arose.

Why Use a Project Manager at all?

Whenever I’m asked to justify the need for Project Management, even in a part-time capacity for a smaller project, I typically use a sports analogy. You constantly see professional NFL teams spend millions of dollars on a head coach, and MLB teams will do something similar for a Manager of their club. While they’re not out there on the field – carrying the ball or swinging the bat – they are considered critical to the success of the team. They identify where the game is at risk by anticipating their opponents’ moves, changing players out when they’re tired or underperforming, and capitalizing on opportunities when they present themselves.

Project Managers do the same thing for their teams. A good project manager will see a delay coming days or weeks ahead of time because the circumstances that cause it will formulate well before it actually happens. Developers are typically hyper-focused on writing a complex piece of code (a calculation, transformation logic, or an integration connection) or resolving a performance issue, and are rarely able to look beyond the most immediate deliverable that they’re trying to complete.

A good project manager will also manage scope creep – one of the most common threats to successful completion and an intact budget. It’s truly amazing how frequently a project with a specific set of deliverables will go off track because a business stakeholder asks for just one more Report book, or an additional integration.

Early on in my career, I learned that lesson the hard way because – as I was building an Essbase Financial Reporting Cube – a key business stakeholder came by and asked me if I could include one more reporting element, which wasn’t in the original Requirements and Design discussions. After looking it over, I realized that it would require an entirely new Dimension to the model. Once added, however, it caused the database to explode and performance to go down the tubes. I then spent the entire weekend (for free) rebuilding the application back to where it was prior to adding the new Dimension. In the end, I lost a full week of the timeline and gave up my own personal time because I didn’t want to simply say, “No, I’m sorry. It’s out of scope.” That was a hard lesson to learn.

To summarize, it’s hard to imagine the New England Patriots without Bill Belichick (which I’m sure Peter Fugere will appreciate). While it’s hard to picture the Yankees from the early 2000s with Mariano Rivera, it’s just as strange to picture them without Joe Torre. Now, tell me again why you don’t think a project manager is needed?

Methodology Type – Agile vs. Waterfall

Waterfall versus Agile. Agile versus Waterfall. This is the discussion that has gone on for years and will likely continue for more to come. So, which one is best for a OneStream project? In the classic answer of a consultant – it depends.

Most fans of Agile will admit that it is not necessarily the best methodology when the requirements are known, the design is firmly locked down, and there’s little risk of them changing. This is the type of implementation where the Waterfall methodology is at its best.

Conversely, Waterfall is not an ideal approach when the requirements are not fully understood, or the design is highly subject to change. In all fairness, this is where Agile shows its strengths.

However, Agile cannot be leveraged in its most classic sense, where requirements are at a conceptual level and the details are refined in the middle of a sprint. The reason is, if a fundamental requirement is discovered in a sprint late in the project, such as adding a new Dimension, or changing what data is loaded at the Base level, it will likely set the project back drastically.

As mentioned in the section on Requirements and the Design timeline, it is essential to get the ‘science’ requirements locked down and the design as fully complete as possible. Once those pieces are reasonably final, the subsequent phases of the project can proceed in an Agile manner. In fact, OneStream is on the verge of creating its own version of Agile for future projects, and it may be in use by the time this book goes to print.

Managing Risk and Change

Be honest. Risk is inevitable, as is change. And it typically comes with its own bad news. I have an expression that I picked up years ago that says, “Bad news doesn’t get better with time.”

When something on the project goes awry (and it invariably will), it is critical to communicate to the appropriate parties as soon as possible, after all of the facts are available, and put a mitigation plan in place to address it.

The worst moments on a project are when an issue is brought to the management team that has been a risk for weeks, perhaps months, but never communicated. On top of having to deal with the issue itself, there is the added layer of frustration that comes with the sudden knowledge of, “I could have prevented this had I only known about it sooner.” It’s not an enjoyable situation in which to be.

Finally, as the tone of the preceding paragraphs suggest, be realistic when it comes to risk. There is a 100% chance that things will go wrong. Count on it. The best thing any project leadership team can do is anticipate those risks, plan for them, and keep a very close eye on them.

Effective Communication

The common element throughout most of this chapter centers around the essential need for communication.

Defining scope? Gathering requirements? Managing risk? They all require solid communication.

Throughout the project, ensure that stakeholders and developers alike understand that they have a voice and should use it to convey their ideas, uncertainties, and concerns. If they don’t, they will hesitate to clarify a requirement until it’s about to be tested, or they won’t mention a risk they anticipate because they don’t want to cause problems.

For more formal styles of communication, there are numerous tools, theories, and methodologies available to consider. Yet, things can be simplified to as little as a weekly status Report, a project financials Report, and a project plan. With those three items, you can manage almost any project.

A quick word on project financials – be sure to include a Forecast, also known as an Estimate-to-Complete. It’s shocking how many Fortune 500 companies, who have immense formal processes and policies in place, don’t ask for – or pay attention to – a project forecast. They monitor Actuals closely, looking at burn reports, timesheets, and run rates, but they have no idea if they have enough budget to get them through project completion.

Ensure your OneStream implementation tracks the Forecast at the resource level and by week. That will surface any anticipated overages immediately when someone is working 50 hours per week for two months, or a key resource is extended for six weeks.

Plan for Success

There are several key areas that can be addressed before the beginning of the project that will drastically increase the chances of success.

Train Early

Have your Administrator and, ideally, a backup person, attend training just prior to the start of the project.

This will allow them to take what they learned in class and understand how the implementation team might address their specific requirements during the design sessions. It will also allow them to assist key stakeholders in explaining a requirement in the clearest terms for the implementation team to truly understand it.

Document Processes Prior to Kick-Off

Processes that are not documented in advance will require significantly more discussion during Requirements and Design meetings. It’s truly eye-opening when a simple Forecast process can take a half-day or more to explain to the implementation team. Even worse is when the customer cannot agree amongst themselves what the process is or even should be.

Documenting these processes before the start of the project will prevent that confusion and maximize the efficiency of the requirements in design discussions.

Staffing Before, During, and After Project Kick-off

There will be a heavier demand for key stakeholders’ time before and during the project initiation, specifically for Requirements and Design discussions.

Key stakeholders should be heavily involved in documenting the processes before the project begins, as previously discussed. They should also plan to participate significantly in the Requirements and Design discussions. This doesn’t mean they will be in the meetings all day and every day. For example, Financial Planning & Analysis stakeholders do not necessarily need to attend the discussions that center around consolidated reporting. Conversely, Financial Accounting stakeholders do not need to attend the discussions focused on the budgeting and forecasting processes. Manage their expectations – upfront – regarding how much they’ll be needed.

Beyond the Requirements and Design discussions, there should be periodic meetings to showcase and confirm progress with the stakeholders. They will also participate during User Acceptance Testing and any parallel tests.

It will likely seem like a rollercoaster ride when it comes to the demands on their schedule, but without their participation, there is no assurance that the system will meet their needs.

Quality Assurance

Few things are as painful as moving into a System Integration Test or User Acceptance Test, only to find that the development completed was subpar and doesn’t work properly. When this happens, rework is necessary, timelines suffer, and there are some very tense discussions between the implementation team and customer management.

Continuous Process

Quality assurance should be a never-ending process. Someone on the team, usually an Architect, would be responsible for reviewing the work of other project team members. Anything found to be substandard should be sent back to that developer for rework. In this way, throughout the build phase, mistakes are caught before they have a chance to reach the End-User community and be uncovered during open testing.

Minimize Rework

Project leadership on the implementation team should be checking the work of the development team early when they first begin working on a deliverable. For example, rather than waiting until 20 Cube Views are completed, the Architect should review the initial two or three to ensure they meet standards. The same approach would be appropriate for Workflows, security, Business Rules, data integrations, etc.

Change Management

Promoting the understanding that change is coming, and is a good thing, is no easy task. The vast majority of people are comfortable in their everyday lives with what they’re doing and the tools they have, so they will need some encouragement to make the switch.

Promote User Adoption

The primary goal of change management is to ease the End-User’s anxiety about moving to a new system.

Throughout the project, make every effort to regularly communicate with the End-User community regarding the status of the project, the progress that has been completed, and the new and exciting features that they will receive.

Encourage feedback and questions wherever possible, and leverage executive management to voice similar encouragement when appropriate. Hearing the CEO or President of the company indicate that this new OneStream system is going to make their lives better, and their jobs easier, can truly go a long way toward easing their worries.

Tools to Use

There are numerous tools to assist with change management. Some, but not all, include:

• Town Hall meetings

• Newsletters

• Videogram messages

• Lunch and Learns

The implementation partner should have some ideas and suggestions as well. Be sure to get their input at the beginning of the project to have a change management approach enabled from the outset.

Conclusion

This chapter covered the essentials to be considered before, during, and after the project begins. This includes a multitude of things to consider when determining the initial scope of the project. It also stresses things to keep in mind when choosing your implementation partner and Administrator, along with critical items that will help you plan for success. There are many things to be wary of when going through Requirements and Design, as well as testing what was built, and validating the data (remember, it’ll take longer than you think), not to mention training options and supporting your application after it’s live.

There is no substitute for a knowledgeable and strong implementation partner to guide you on your journey. However, the hope is that this chapter will help you initialize the project in the best possible way, as well as recognize warning indicators should they arise during the course of the implementation.

Epilogue

I realized that I had made the right decision in joining OneStream while at my first Services Summit in October 2016. The excitement of what lay ahead was palpable amongst the team. The energy was unique – even better than ‘the good ol’ days’ of Hyperion Solutions. It truly felt like family. Four years later, I can emphatically say that it still feels that way.

To top it off, we held an event at The New Orleans School of Cooking, with Chef Kevin Belton, where we all learned to make authentic Cajun dishes. I still cook the jambalaya several times a year because of this event.