WIXLIB

The business (functional) requirements document identifieswhat the system should be able to do to support your goalsand objectives; it should not specify how to do it becausethat limits the potential solutions vendors can bring back toyou. A first draft of this should have been developed as partof the business case. The requirements may be at a high level(especially early in the process); expect to add additional levelof detail as you get closer to implementation. Practitioners andimplementers recommend clearly understanding your “musthave” requirements versus your “nice to have” wishes to ensureyour primary needs are met effectively. Overall, a well-craftedrequirements document can help to avoid rework, errors andcost, and is worth the investment in time and effort.A use case is a qualitative description of how a user interactswith the current system, applying several requirements toachieve a desired outcome in a manner consistent with overallproject goals. The purpose is to explain to vendors how thesoftware will be used, providing a “day in the life” view of yourspecific department to both business and technical readersand often helping to bridge gaps between the two groups. Theuse case may become the basis for a “proof of concept” to bedeveloped later.Technical requirements describe the functionality andfeatures of the system. For example, performance, includingtime to calculate or refresh; availability, such as uptime;reliability concerns; capacity to handle data; hierarchies;security at various levels; single sign-on to the platform;interoperability; and APIs. They are sometimes called servicelevel requirements or quality of service items. At a high-level,they may be included as part of the RFP process, as theyrelate to the business functional requirements; at a detailedlevel, they may be utilized later for design specifications.ISSUE RFPThe formality of this step will be governed by your RFPprocess. In most cases you will have already contacted thecompanies under consideration during your backgroundresearch; simply forward the document to your contact. Forcompanies with a heavier process, the procurement team willhandle dissemination through approved channels.6WRITTEN EXAMPLESOF REQUIREMENTSThe following are examples ofPOORLY WRITTEN requirements:2“The system must calculate the annualbenefit by multiplying the Final AverageSalary by the Total Years of Service andthe Retirement Multiplier.” True, this doesspecify what the system should do, butthis is actually a business rule, not afunctional requirement.“There must be separate identicalregions for development, test, qualityassurance and production.” This isan implementation requirement.Under different terms or options, thisorganization might elect for fewer—or even additional—regions. Thisinformation does not communicate whatis actually desired of the new system.“The vendor must provide a meetingagenda and any documentation toreview at least 24 hours before eachscheduled meeting.” This is a projectrequirement. It would be nearlyimpossible to track this requirementto completion in large-scale projectsthroughout which hundreds orthousands of meetings would likelytake place.“The system must provide the abilityto merge two accounts/records whereone account is for the same person withan incorrect social security number byallowing the user to click the incorrect,make the changes to the correctaccount, and then delete the incorrectaccount automatically after an accounthas been locked for this purpose.”While the first part of this statementis a proper functional requirement(ability to merge two accounts, onewith the wrong SSN), the second partis a design specification—it specifieshow the system should accomplish aparticular function, not what function itshould perform.—Sagitec BlogAFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software

EVALUATE RESPONSESWhether you started with the system or theimplementer, at some point you will need to evaluatethe software. You can think about this in two rounds:Round 1: The goal is to narrow the universe ofpotential vendors to a shortlist of three to fivecandidates. Round 1 is a weeding out process thatputs a high focus on product diligence to deliver thebase functionality. Your background research shouldbe enough to get you this stage, and the RFP isissued to the preferred companies.Round 2: The competition now requires moreintense consideration and scrutiny. We have provideda scoring matrix available for download, but inaddition, here are a few categories of evaluation:PRODUCT DILIGENCEHow well does the software solve your businessproblems, now and in the future? Keep your goalsand objectives in front of you to resolve manyconflicts and questions that arise. Check referencesfrom business’s with similar requirements andcomplexity, and ask about the full breadth ofcapabilities as well as what is effort and resourcesare required to maintain the system.Plan to have software demonstrations, a glimpseof how you will resolve my requirements. There is arange of interactions with the software throughoutthe process and as you narrow the list of vendors,you will move from left to right in the figure below:Levels of Engagement for Software DemonstrationsCUSTOMER DATAVENDOR DATACANNEDDEMOA basic demonstrationof the software that ispre-made (“canned”)by the vendor.INDUSTRY- ORFUNCTION-SPECIFICDEMOA demonstration of specificattributes, such as industryrequirements (i.e., retail)or needs (sales or HRplanning).PROOF OFCONCEPTShowing customerrequired functionalitywith customer data tosatisfy scenarios (oftenbuilt from use cases);the system is not fullyoperational. Still part ofsales cycle, so generallyno cost to customer. Usean NDA.PILOTThe system is fullyoperational in one partof the company. May bean easy deployment for aquick win, or challengingdeployment to showcapability.AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software7

“Martin Kratky, Group CEOManagility-Acterys Group,endorses a pattern of escalatinginvolvement for both the productand the team diligence: “We seea lot of value in proof-of-conceptsworkshops with vendors wherea prototype is built together withkey members of the project teamon the customer side directlyinvolved in the process and notjust in reviewing the outcomes.It is crucial to get a feel of theactual efforts to get to a solutionto assess, if for example inhousecapabilities can be utilized or ifevery little change will require thesupport of external specialists.”8SOFTWARE VISION:Does the roadmap of future development of thesoftware make sense with your future needs? Arethey committed to the planning space?IMPLEMENTER DILIGENCE:What is the experience and capability of thisimplementer’s team members? How will we worktogether during the process and after “go-live”?What is your process? Vendors report that there are two types ofclients—those who dictate what they want tobe built, and others who seek out a consultativepartnership. Different implementers will fitinto these camps, and you should seek outthe correct fit for your situation. The researchliterature and numerous interviews indicatethe best practice is to form a partnership withyour solution provider. They should be acting aseducator, adviser, consultant, and coach. Havegood conversations. It is critical to have the right fit to becomfortable with the implementation teamsince even short projects require a few months;request the names and biographies of theimplementation team as well as the opportunityto meet them. While the implementer maynot be able to deliver the exact people in theproposal due to timing and other projects, theyshould be representative of comparable skills.FINANCIAL DILIGENCE:Basic evaluation of whether the company is likelyto remain as a going concern for the foreseeablefuture (or purchased by a larger company).CUSTOMER DILIGENCE:What have been the experiences of othercustomers, and what would they recommend thatI do? How responsive is the vendor/implementer?What tradeoffs did they make?AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software

TRADEOFFSWhen you get to end of the selection process,keep your goals clearly in front of you and revisitthe requirements to ensure you can get the criticalfunctionality you need. The tools have differingstrengths, approaches and costs to solving yourchallenges that will require compromises or creativity.Mitch Max, partner at planning systemconsultant BetterVu gave an example of a clientthat found itself at a crossroads: one tool excelledat reporting and the other at model building andcalculations. How to choose? “This client rankedand prioritized what mattered most to themand looked for alternatives to buttress the totalsystem. They created a blended solution thatbrought in another product to handle the businessintelligence piece while maximizing the modeling.”Similarly, customers should consider whethertheir requirements conform to standard, out ofthe box implementations, simple configuration,complex configuration, or a custom build. Forexample, customers may need to trade off whatis in-scope for the solution versus remaining in anoutside model that feeds the solution.Another type of tradeoff is the durability ofthe solution designed. “People want to solve aproblem based on the pain in front of them. Butthe differentiation among product sets is in theopportunity down the road,” Max says. Some “usecase” solutions are narrow and solve a specificproblem, while others are platform solutions thatcan support additional buildouts and growth. Theplatforms will do more, cost more upfront, and bemore complex, but provide greater functionalityand scalability.Philip Peck, VP, Transformation & AdvisoryServices at Peloton Consulting, summarizes thetrade-off discussion as follows: “It is key to balancethe potential complexity of a solution that wouldhandle 100% of all requirements versus a solutionthat will satisfy 90% of the requirements whileminimizing unnecessary complexity and makingthe solution far easier to administer, maintainand support. There is always the danger ofcreating a ‘nuclear powered mousetrap’” that isoverengineered and introduces operational risk.AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software9

NEGOTIATING AND CONTRACTINGThere are likely to be two parties in the process andat the negotiating table. The software costs andimplementation services are negotiated separately,and the key price elements and leverage pointsdiffer. Here are various elements to consider:VENDOR Model a three-year of ownership to understandthe total costs, and negotiate all points as partof the complete package, including:- Pricing options—perpetual, cloud,subscription, unlimited, etc.- Initial and maintenance costs (ask for athree-year pricing outlook)- Review the “terms of use” to understandservice level agreements- Cost per number of users of varying type(hint: sometimes, an unlimited user licenseoption is cheaper and easier to maintain)- Usage cost: data transfer, data storage,data location- Additional modules or connectors neededfor buildout- Training by levels (admin, read write)- Support terms- Potential for hidden fees, ie, contractedprice increases Consider potential impact of quarter andyear-end sales cycles Data ownership. This is especially importantin the event of termination with the vendor;specify upfront how to reclaim and export yourdata to a new provider.10The implementor will need to create a statementof work and may conduct a needs analysis or aproject scoping exercise. The level of detail anddiligence in their questions is an indicator of theirunderstanding of the project and may introduceideas you had not considered.IMPLEMENTATION PARTNER It is challenging to get a comparison ofimplementation costs on an equal basis;some companies trade off up-front costs forchange requests. The statement of work should include detaildesign, data discovery and management,solution build, testing, training and migration.Consider:- Training—admin, read-write levels- Support—what level of resources is ongoing?- Post-go live support—in case some bugspersist after implementation- Resource mix: level of expertise and seniorityon the project, on site vs off-site, onshore vsoff-shore- Define the change management processand costs Cost structure: time and materials versus fixedprice contract, travel expenses KPIs for implementation (objectives,deliverables, benchmarks, and cost structurewith the vendor) Hold back a portion of payments untilfinal deliverable.AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software

Case Study: Shell OilThe Shell Deep Water business’ search for a nextgeneration planning system began at AFP’s 2016conference, where they first started to hear aboutnew cloud players in this space and this nextgeneration of technology, said finance managerCharles Passauer. That would start them on ajourney that bucked tradition and expectationat the 300 billion energy behemoth. Passauerdescribes Shell’s approach below:Structure the process: Shell used a consultingcompany to organize the selection process, runthe demo sessions, and join in the discussionthat narrowed the selection to two vendors.“[The consulting company was] good at theprocess, but less helpful with the selection. Wedetected some bias.”Background research: “We preselectedvendors based on what we heard at conferences,paired with our research through Gartner andForrester.” The field consisted of two largeplayers, two smaller players, and the incumbentsystem that was specifically designed for the oiland gas industry.Evaluation, Round 1: “We had a few weeks ofcalls, followed by two weeks of engagementswith each company; for one, we went to [theiruser] conference and made assessmentsthere.” The engagements were one half dayfor each vendor where they came to Shell andled an interactive demonstration to discuss thefunctionality checklist circulated in the RFP.”Standard demo, not a proof of concept. Theevaluation team used a vendor scoring matrixto create a ranked score for each vendor—eachcategory was rated for importance to Shell andperformance of the vendor. We used a 0-1-3-9ranking method to get separation among themost important aspects of each product.3 The10 members of the evaluation team includedFP&A, economists, engineers, IT, and a sampleof member from other departments who have ahand in the planning cycle.Evaluation, Round 2: The team selectedtwo vendors to move into a more detailedreview. “We looked at functional and technicalrequirements up to now; here we looked intothem commercially.” Procurement conductedinterviews, discussed contracting terms,customer viability, financial viability, (willthey get bought?). We then had a secondaryengagement to clarify additional questions.”Evaluation, Round 3: Next step was to pilotthe new system in one business unit. Thistook five months, although the challengeswere not technical at all. “We were metwith some internal resistance to try out newtechnology and ways of working like trueAgile development. In addition, we needed towork through the process of putting sensitivedata in the cloud, which we had never done.”After six months, the team used a scorecardto assess the success of the project—it wasoverwhelmingly positive.Evaluation, Round X: “We are going to pilotthis in relatable domains, and then move frompilot to pilot to pilot. We have a history of projectsfailing when we have a big centralized rollout. Sizeand complexity are often underestimated in globalrollouts. Our approach is more agile—share thelessons widely, continue learning, and adapt. Weare not ‘pushing’ this solution, but getting ‘pull’requests at an increasing rate.”AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software11

VENDOR VOICESWhat goes wrong in the implementation process that can be helped during thevendor selection process?“CATHY JIRAK - Principal & COO, QueBIT Consulting 12Overly focused on features. Too manyclients just define the features and functionsthat they are looking for, but it’s even moreimportant to define what business objectivesare paramount to the success of the project.Cutting corners. Cutting costs on thingsthat don’t seem important, like testing andproject management, in order to get theprice down. It is also important not to [selectyour implementer] on price alone. Not allimplementation partners are created equal;ask references if they built a true partnership.Confused roles. Understanding who isresponsible for what duties PRIOR to startingthe project. Involve relevant stakeholdersearly on and don’t just make it an IT orprocurement decision. Unclear on offsite support. Not fullyunderstanding the challenges and impactsthat using an offshore partner has on theproject (time differences, scheduling, delaysdue to these factors, etc.) No proof-of-concept. If a client wants toreally understand how the product will workin an implementation, and understand howan implementation partner will work withyou during a project, then make a proof-ofconcept demonstration part of the evaluationprocess. Provide data (plenty of it) andvarious reporting and planning templates forthe vendor to utilize in their demo.AFP GUIDE: Implementing a Planning System: Part 2, Selecting the Software

“NICK BLADES - Senior Director,Consulting Services, OneStream “PHILIP PECK - VP Transformation & AdvisoryServices, Peloton Consulting GroupClient team unavailable. Most of the time wefind issues with a customer over-estimatingtheir ability to provide dedicated resourcesto the project. Be honest and realistic aboutdelivering a client team that can assist withimplementation; the vendor relies on thoseestimates to staff the project and reliablyproject milestonesData, data, data. Underestimating the amountof time to deal with data reconciliation andvalidation. Ensure the team you select hasexperience with this and they push back ontimeframes that are unrealistic.Vendors who agree too easily. Avoid vendorsthat just agree with everything their customersays. Our customers spend a lot of money ontheir implementation partners and are lookingfor our advice a lot of times. We encourageour teams to push back on the customerswhen we believe they are going down thewrong path.Unrealistic expectations. When softwareimplementations go wrong, it’s usually dueto one of several factors: new or unexpectedrequirements being surfaced, unrealisticexpectations of the software, or userresistance to change. Minimize this by gettingall stakeholders involved in the selectionprocess, including executives and key users.Setting realistic expectations about what thenew solution is capable of, and the changerequired of individuals.Skimping on the RFP. Too many times RFP’sare thrown together in a quick fashion to helpmake a selection; however, a clear expectationof the project’s success factors will help todrive more clearly defined RFP responsesfrom vendors. Vanishing sponsor. The executive sponsormay become hands-off to allow thisprocess to play out this person(s) needs toremain highly visible and actively engagedthroughout the life of the project. Cost cannot be the only decision criteria.The choice of the software vendor and theimplementation partner should incorporatea balanced approach, looking at multiplevariables and lenses. Change management. Make sure that youfully understand how the implementationpartner approached these critical activitiesincluding exploring with their references howthis worked in prior implementation projectsand identifying activities in the proposedstatement of work. Data, data, data. Again. Data is typicallythe long pole in the tent when it comes towhat causes probl

are known industry and product reviews: Gartner Magic Quadrant for Cloud Financial Planning & Analysis1, Forrester Wave, BPM Pulse, Nucleus Research, etc. There are multiple ways to meet with vendors before beginning an engagement. AFP's annual conference and its annual FP&A event FinNext both provide an opportunity to speak to multiple vendors.