Frequently Asked Questions (FAQ)
Overview | Schedule | Scope | User Engagement
Data/Structure | Planning | Time Entry | Cost Controls | Detailed System Questions
Note: You can use CTRL/CMD + F to search the questions
- What is F$M?
- F$M = Financial Systems Modernization. The purpose of this multi-year, multi-phased, Lab-wide project was to address the Lab's financial systems (people, processes, and technology), to more effectively provide data, analytical tools, and services for research management needs. For further detail, please see About F$M. Learn more >>
- Why F$M?
- The Lab's prior financial application was designed in 1997 with a primary focus on meeting institutional (e.g., DOE, UCOP) requirements. Subsequently, the Lab grew significantly, business models changed, and a growing tangle of custom workarounds developed in the system to meet the Lab's needs. The result was a network of complex, manual, and duplicative processes, without the ability to leverage functionality in new releases of the system software, PeopleSoft. F$M redesigned the structure of our financial systems to not only address current issues, but to better serve the Lab in the future. Learn more >>
- Who Worked on F$M?
- The F$M project team was a group of experienced Berkeley Lab staff and skilled Accenture staff, in partnership with diverse representation from across all of the Lab’s divisions. Learn more about the team's make-up and organization on The Team page. Learn more >>
- What is meant by "Efficiency"?
- In the context of F$M, "Efficiency" was meant very broadly. F$M transformed the way we execute our day-to-day work, with a goal to making many tasks easier, faster, and more streamlined, and to allow employees and Divisions to devote time to important, higher-level tasks and provide opportunities to learn new skills. While this may mean that employees who leave might not need to be replaced, as with all resource decisions, staffing decisions will continue to be made in the overall context of the Lab's organization, funding climate, and research management support needs.
- What was the F$M schedule?
- The F$M Project was split into two overlapping phases: Phase II-A (01/07/2013 – 11/30/2014), which went live on 10/1/2014, and a potential Phase II-B. For more information, please see the Project Schedule. Learn more >>
- Why was Phase II-A Go-Live concurrent with Year-End Close?
- While launching at year-end close made training challenging, especially for our Resource Analysts, it was determined to be the best option because it minimized costly data conversions. We mitigated impacts in several ways, from providing early exposure to the test environment, to getting people familiar with the system and tools, to extending the major training period through post-launch, to meeting the needs of those whose schedules would not allow them to take training before the year-end close. Learn more >>
- What were the F$M changes?
- The goal of the whole F$M project was to deliver integrated, streamlined, and improved financial service and information solutions. These encompassed all the OCFO end-to-end business process/service areas: DOE & General Accounting, Work for Others, Buying & Paying, Effort Accounting, Travel and Conferences, and Reporting. The goal was to provide consumers of these services with a more consistent experience, reduced cycle times, and easier access to timely and accurate financial information. Although the look and feel of the financial systems did not change significantly, as we stayed with PeopleSoft financial software, the improved systems brought changes to how work is executed, such as inputting and tracking proposals, closing out projects, and generating financial reports. Learn more >>
- Why was the scope of F$M so big? Why not implement a more phased approach?
- F$M's scope actually was broken into phases. Phase I began in 2011 and involved defining the problem and recommending solutions. Implementation was split into Phases II-A and II-B. Since service areas are all very closely related, and modules highly integrated, there were efficiencies and synergies gained by, for example, doing all the design at once. Further phasing would have unnecessarily separated relevant pieces of the project and potentially delayed overall implementation. To provide more tracking and modularity to the project, we built in multiple milestones, with a variety of rigorous project management checks and balances to track progress against scope, schedule, and cost. Please see the About page for more detail. Learn more >>
- What if we find things about the system that we think could be improved? Why can't we use the same system screens we had before?
- Our prior system was highly customized. Customization is costly to maintain, introduces complexity and system bugs, and hinders our ability to take advantage of new functionality. To reduce the long-term system cost to the Lab, we focused customization on areas that had the most impact to users, would provide the most cost-benefit, and/or where Lab's core needs could not be met otherwise (e.g., required monthly transmission to DOE).
We followed a rigorous set of Governing Principles to strike a balance between standardization and customization, leveraging "off the shelf" functionality to meet business needs where possible.
If you have an enhancement request, please submit it through the HelpDesk [fsmhelp.lbl.gov] and choose "Enhancement Request" as the Issue Type. We continue to follow our Governing Principles to prioritize and address requests. Learn more >>
- What were the criteria for moving Phase IIB forward?
- Executing Phase IIb was contingent on Lab leadership’s prioritization of indirect budget formulation. Ultimately, we intend to do all of the Phase IIB scope. The intention was to do all of Phase IIB scope, but start date and duration was driven primarily by Lab budget, and the results of Phase IIA Deployment. Learn more >>
- Why did we stay with PeopleSoft?
- The main problems with our prior financial system were not platform-specific, and the three potential software solutions (PeopleSoft, eBusiness, SAP) did not differ significantly.
Meanwhile, there was a significant benefit to leveraging our existing PeopleSoft licenses and in-house development knowledge to re-implement the most current PeopleSoft release. Learn more >>
- Why didn't F$M Phase IIA include replacing TREX & LETS?
- During the planning Phase of F$M, our external reviewers highly recommended a phased approach to the project.
LETS and TREX, being less integrated with the rest of the financial system, were the sensible choices to separate out into a later phase. Learn more >>
- How was the new system tested?
- F$M Phase IIA involved five months of rigorous testing by technical and functional staff. This included several weeks of User Acceptance Testing, which involved users following instructions to step through a wide range of typical tasks in the new system. However, as for any system, there was no way to simulate the “real world” environment of a full range of production data, fully integrated systems, and hundreds of users executing a highly diverse set of scenarios. Therefore, many bugs and issues were not possible to detect until after go-live. Learn more >>
- What was the Communication Strategy?
- During the initial stages of any project, the Communications team begins by analyzing stakeholder needs, organizational culture, and communications vehicles to create an effective communication and change management strategy. Strategies to reach the broader Berkeley Lab community included: leveraging existing Lab Councils and Leadership meetings, Division and Department meetings, and TABL; maintaining detailed information on the F$M website; circulating flyers; conducting outreach in the Lab Cafeteria and offsite locations; posting banners on key information systems and system emails; and scheduled demos and targeted meetings for high-impact stakeholder groups such as requisition preparers and administrators. Surveys and other feedback mechanisms provided stakeholder input and helped to continuously adjust and tune the strategy to ensure clear messaging was reaching the appropriate stakeholder groups. Finally, a targeted and comprehensive training program helped to prepare users for the new system. Learn more >>
- How did you ensure user involvement in F$M?
- We used top-down and bottom-up approaches, with stakeholder engagement at every level. In particular, our Stakeholder Committee and Working Groups were drawn from customers, process owners, and subject matter experts from across the Lab. Learn more >>
- How did you ensure leadership support and engagement?
- The project had a clearly articulated governance and decision-making framework. Lab Director Paul Alivisatos served as the project's Executive Sponsor, and Chief Operating Officer Glenn Kubiak chaired the Steering Committee. In addition, the project team communicated regularly with Lab leadership at multiple levels. Learn more >>
- How was training administered?
- Training was modular, based on role/tasks performed rather than a one-size-fits-all approach. Training used self-paced eLearning where possible, with scheduled classroom sessions reserved for more complex, targeted training. Early training was made available to everyone in April 2014 on overview topics, e.g., 9.2 Navigation, new Project ID Structure, modified LETS interface. Comprehensive training began in July 2014, including basic training on Reporting Tools. Learn more >>
- What is the system support framework?
- The F$M Team developed a formal Support framework, including an F$M Helpdesk, F$M Experts, and Documentation. A higher level of support was available in the weeks immediately following Go-live, with continued support thereafter. Learn more >>
- What is Financial Data Architecture (FDA)?
- The Financial Data Architecture (FDA) is the overarching data structure that encompasses all of the information that we use for financial reporting and financial decision-making. It includes data fields and attributes, the chart of accounts, and work breakdown structure. F$M Phase II-A included rebuilding the foundational FDA to improve and streamline the way we manage and report financial data. Learn more >>
- Why change the Financial Data Architecture (FDA)?
- The prior FDA no longer met the Lab's business needs, and getting the necessary information out of the financial systems was a costly process requiring a large number of financial staff to mine data. For example, the prior system captured how things were purchased, but did not effectively capture what had been purchased. Also, there was no standard definition for a project, resulting in 25,000 active projects representing activities from multimillion-dollar research projects to small work orders. As a result, we were unable to answer questions such as "how many research projects does the Lab have", or "how much did we spend on microscopes in FY12" without a lot of manual intervention.
The New Financial Data Architecture (FDA) was restructured to provide a more robust chart of accounts, work breakdown structure, and standard data definitions and data models. These allow us to manage and report in a more streamlined and efficient way. While implementing such a change in data structure involved a near-term disruption, the benefits should be sustained. Learn more >>
- Why did we have to change to two-parted, Project & Activity IDs? Why can't we use 'intelligent' naming in our numbering scheme?
- To deliver two major system requirements -- improved reporting and better funds control -- required a restructuring of how we categorize and manage projects in the system.
Divisions can use, and in many cases are using, their intelligent naming in the more flexible, 30-character project and activity descriptions, which are text-searchable in many places, such as LETS. Learn more >>
- Was historical data (prior to FY15) available in the new system?
- No, only open balances were converted into the new system, and into the new Financial Data Architecture (new GL accounts, projects, activities, resources types, resource categories, etc.). Because we significantly changed our data structure, converting historical transactions would have been manual, prohibitively expensive, and minimally accurate. Historical data is available in the old data architecture in the old Financial and Data Warehouse systems.
- Did F$M address problems in the Planning System?
- While a wholesale redesign of the Planning System was not in scope for F$M, modification to the Planning System was necessary because all of the inputs changed with the changes in the new Financial Data Architecture (e.g., project structure, resource category structure, and burden calculation). These changes were intended to ultimately simplify and improve the user experience of the Planning System. Learn more >>
- Did the project include tools to develop proposal budgets?
While not officially part of the project scope, the Planning System was modified to use the new FDA, so that it could continue to be used for more formal proposal development. In addition, the Budget Office developed a Proposal Tool to develop quick estimates. Learn more >>
- Why didn't the project include the ability to do weekly or hourly time recordings?
- Some Divisions had expressed an interest in more frequent/granular time reporting to better manage, for example, work orders. However, changes to time reporting were not a part of the F$M Phase IIA Scope. Learn more >>
- Did the project put controls in place, for example, for who can charge to what project?
- Phase IIA added an approval step for purchases, that can be turned on at the Division level, allowing a PI or PM to approve purchases on their project. In addition, time entry was changed to disallow time charged to a closed project. Learn more >>
- Were there any improvements to phone and electricity pricing?
- While a change in recharge pricing was not in scope, we did change to require more upstream verification of information, which means less downstream clean up.
- See system-specific questions from System Demos
- System Demos