4 remote work benefits that should not be overlooked
- Jamie Black
- Efficient, Effective and Reliable
- minute(s)We work with finance & budget departments in organizations of all sizes. Even in very large organizations, these teams tend to be small (and getting smaller). The apparent trick for small groups is how to enable them to do more with less, do it better and do it faster. It can be challenging to think of creative ways to drive these efficiency gains. Our firm feels this pressure too. Our whole company is small. The skills we require of our professionals are hard to find, develop, and maintain. It's a special combination of accounting, technology and extensive finance department business process understanding, earned by decades of experience working IN public sector finance. We are always looking for ways to increase efficiency. Nearly a decade ago we implemented a remote work strategy for our company with this aim in mind. We invested heavily in technology to enable it: all meetings & training sessions are conducted online and recorded, we host the recordings of our meetings/training so clients can play them back at will, we use transcription services to facilitate easy searching of recorded meetings, we use online project management tools to keep our clients apprised of project status at all times, all of our systems (servers, phones, etc.) are remotely accessible. Today we are a 100% remote work organization and our team is spread out across North America. In the last few years we have seen articles about companies reversing the trend of allowing remote work (Yahoo, Bank of America, Aetna —and, most recently, IBM). For us, the last 10 years have only served to increase our belief in remote work. Why? Here are 4 big benefits. 1) Flexibility Benefits for our Team: From spending a month at the beach in Mexico or Gulf Shores, Alabama to a few weeks in Japan, relocating temporarily does not necessarily mean you are eating into your vacation. As long as you have good office space and excellent internet, the world is your oyster. Further, permanently relocating for your family (for example my wife recently took a new job on the other side of the country) does not mean having to leave a job you love. We hear from our teammates regularly how much they appreciate the flexibility. Here are some pictures of what our teams work environments have looked like over the last year. Benefits for our Clients: Being remotely enabled means we can quickly jump from helping one client in Florida at 9 am to one in Oregon at 11 am and then provide 4 hours of training to clients from Ontario in the afternoon. Here's what our client, Washington County had to say about working remotely with us to automate their budget book: 2) Efficiency Every organization cares about maximizing output. We REALLY care. It is what we help our clients do everyday after-all. Even though there's a lot of evidence for increased general productivity, with remote work, consider the time savings from commuting alone. The average commute time to the office in Canada and the US is about 26 minutes. You could reasonably expect similar results on the trip home. It's a waste to you personally as there are a lot better things you could be doing with 52 minutes a day (working out, walking the dog, playing with your kids, sleeping, we could go on forever here). Further, it's a waste to the economy in general and the organization you work for in particular: At an average of 26 minutes each way to work, five days a week, 50 weeks a year, that works out to something like a total of 1.8 trillion minutes Americans spent commuting in 2014. Or, if you prefer, call it 29.6 billion hours, 1.2 billion days, or a collective 3.4 million years. With that amount of time, we could have built nearly 300 Wikipedias or built the Great Pyramid of Giza 26 times -- all in 2014 alone. Washington Post February 25, 2016 Clearly not all the time savings from the commute are a gain for the organization. But if even 10% accrues to our company, that is an extra 20+ hours per person each year, and that is a great benefit. 3) Happiness Think of the frustration that traffic causes. The stress of being late and rushing. Rushing to work, rushing home to make dinner or take kids to after school sports. For example, as I write this' I am watching my kids jump through the sprinkler on our front lawn. This benefit is not just anecdotal either. Longer commutes are linked with increased rates of obesity, high cholesterol, high blood pressure, back and neck pain, divorce, depression and death. At the societal level, people who commute more are less likely to vote. They're more likely to be absent from work. They're less likely to escape poverty. They have kids who are more likely to have emotional problems. Washington Post February 25, 2016 Now it should be said that there can be other challenges related to remote work. The primary ones being burnout and loneliness. For us, the loneliness component is partially mitigated as we are working together on projects for clients continuously. We have a full staff meeting online weekly with webcams turned on catching up, discussing requirements, deadlines, and providing training which results in lots of human interaction. Finally, we attend, speak and teach at a dozen or more conferences per year. Usually, several of us attend and have a chance to spend in-person time with clients and other teammates. 4) Recruitment If we were a traditional, office-locked company, we would recruit in our city and be largely constrained by the talent pool available locally. Or we would need to convince a candidate to relocate. Unlike some of our competitors, we can avoid these twin constraints. We have the luxury of drawing from a much larger pool (the world) and have no need to upset anyone's life with relocation. The geographic constraints of hiring is an often overlooked problem and can lead to selecting less qualified candidates from a pool of neighbors, friends, or, god-forbid, family. As we expected, the strategy has been paying off for years. This year alone we were approached by 2 CPAs with decades of experience in government and the auditing of governments who were looking for a change. One is located in a small town in Ontario. He loves where he lives but was looking for a more challenging, rewarding career. The other is located in the mid-west US with the very same goals. These new hires give our small company an out-sized competitive advantage that allows us to do better work for clients. We understood that in order to grow and thrive, we needed to think differently. Remote work was one of our strategies and it continues to provide exceptional ROI for us, enabling us to stay far ahead of the competition and provide the best service to our clients.
Finding ways to improve finance & budget department efficiency is challenging. We implemented a remote work option for our team. Here are 4 big benefits.
READ MORE
How to prepare a better solution requirement list for IT project ...
- Jamie Black
- Efficient, Effective and Reliable
- minute(s)Many of our articles address factors related to IT project success and the significant rate at which these projects fail. There are many causes for failure; first among them is choosing a solution that does not meet the needs of your organization. Typically, selecting an IT solution begins with the Request For Proposal (RFP) process. The process seems logical—state your needs and ask vendors to supply a price to meet those needs. If you're buying a commodity with little differentiation among options, developing a list of requirements is important. But if you're buying an intangible like an IT solution, with unlimited variables and options, that list becomes absolutely critical. Unfortunately, it is very common to see software requirement lists for Comprehensive Annual Financial Report Automation or Continuous Controls Monitoring (CCM) systems with requirements: That are very broad Derived exclusively from a vendor's list of features Copied from another, theoretically similar organization's RFP To see the error in this approach, imagine buying an expensive suit. After seeing it hanging in the store and being impressed with what you see, the next step is always to try it on. Why? It is the only way to guarantee it fits you. Even though the tag says it's your size, that is no guarantee of fit, is it? Take that suit home without trying it on and it might fit exactly (unlikely); it might need some alterations, or it might be completely wrong for your body. Why do so many organizations have such ill-defined requirements? The most common reasons include: The team disagrees that implementing a new IT system is like buying a suit; they see it as more like the purchase of socks—one size fits all. The team did not have time to formally document their needs, but felt that a good compromise was to use someone else's. The team did not have a clear idea of how to document their needs, so they chose to leverage those published by vendors or peers. How to document your needs If you fall into the third category above, you can improve the probability of your IT solution's success by applying these seven steps: Document your current business processes. Start by writing down each step. Visit the people who perform each step and ask them what they do, in what order, and why. Be prepared for some surprises. There will be steps you did not know about and shortcuts you never imagined. The benefits of this documentation process can go beyond selecting the right new system. For example, it can be the critical first step to updating your internal controls risk assessments or training materials. Prepare process diagrams. There are many ways to create this material, but we firmly recommend modeling your business process graphically. Business process diagrams (or models) are excellent at displaying process gaps or errors in understanding in a way that descriptions like those gathered in Step 1 will not. We recommend swimlane diagrams like this: Many applications can be used to create these diagrams. The most commonly used is Microsoft Visio but we also like Lucid Chart and Creately. Gather copies of any inputs (forms, authorizations, etc.) or outputs (reports) of your business processes as attachments to your documentation. Be sure to label the diagram to show where in the process they apply. Consider what could/should be improved: What is difficult today? What takes a long time with the current process? What would the value to the organization be if you could eliminate or shorten this time? Are all steps necessary? Could we remove some of them and still achieve our desired results? Often these opportunities will jump out at you in the diagram. They may appear as many steps that loop back on top of themselves, for example. Create new diagrams of the optimal future process, incorporating the items identified in Step 4. This improved process is a better representation of what you want your new system to support. Transform the steps in the business process into a requirements list. For example, if a step in your diagram is, "Batch email statement," the need might be, "Ability to email statements to all accounts that have an outstanding balance without any manual intervention." Finally, now is the time to consider vendor feature lists or the needs documented in other, similar organizations to see if there are any items you may have overlooked. By applying these seven steps, you can tailor your software requirements list to your organization, and more likely find the solution that provides the greatest value.
Follow these 7 steps when preparing a technology requirement list to ensure your next solution meets your needs.
READ MORE
7 Steps to Avoid the Cheap IT Solution Selection Trap
- Jamie Black
- Efficient, Effective and Reliable
- minute(s)According to information technology research firm Gartner, between 50 and 75 percent of IT projects fail. We've written a number of articles offering guidance for achieving better outcomes through the solution selection and implementation processes, but there is one trap we haven't addressed—and we see clients succumb to it all the time. Price Clouds Everything Consider the Canadian government's recent Phoenix payroll software debacle. They elected to have a payroll system custom developed by IBM and have had nothing but problems with it. According to one assessment: "... the Harper government put so much emphasis on saving money that it undermined efforts to ensure that the system would function well...instead of saving the government 70 million Canadian dollars this year, as promised, Phoenix has cost the government an extra $50 million (about USD$ 37 million), including $6 million in additional fees paid to IBM to fix it." When participating in an IT system evaluation, if you find your team leaning toward the low-cost choice instead of the high-value solution, beware. No one wants to pay more for something than they need to. In government in particular, you may even have the obligation to choose the low-cost solution. This default preference/requirement is understood by IT solutions sales representatives and is often relied upon to accelerate the sales cycle and "close the deal." Even if you're not being exploited by sales teams, the Phoenix case shows how this low-cost bias can lead to dysfunction. Here are two questions to ask yourself to avoid a bad deal when considering the "cheap" IT solution: 1) Is it truly cheaper? In one respect it is obvious; if the number at the bottom of the RFP response or quote is lower, then it's the less expensive option. While technically true, that is only a valuable assessment if you are comparing apples to apples. Before you look at the price, you need to know whether you'd be getting the same thing for the money. With an intangible product like software, it can be difficult to ensure you're making an apples-to-apples comparison. If you bought the Chevette above based solely on the price, you could be stuck with the wrong car if acceleration and top speed are necessary features. Alternatively, you might decide you do not need a Corvette, that a Chevette will do. The point is, they have different features and capabilities, and comparing the two options based solely on price obscures those differences. RECOMMENDATION: Before assessing products, explicitly and formally define your needs/requirements and evaluate your choices based on fit first. Don't allow the price to hijack the process. Use ROI instead of price to select among solutions that fit some/all of your requirements. 2) Why is it cheaper? There's no such thing as a free lunch. - Milton Friedman You've assessed the options based on fit. Then you calculated ROI. The cheaper solution comes out on top. What now? RECOMMENDATION: Treat the low-cost solution with extreme suspicion. This is your warning sign to bolster your due diligence. We recently watched one "low-cost" vendor in the reporting automation industry cease operations and advise their existing clients that they are on their own. For some of these folks, this happened while they were implementing the software. The Action Plan: 7 Steps to Better Due Diligence Double-check fit-assessment. If you have any doubt, have the low-cost vendors re-demo the product to confirm it meets your needs. Double-check standard pricing variables: Modules/features Number of users Number of people being trained Duration and extent of support period These are all variables that might account for significantly reduced cost. Remember, you want to compare apples to apples. Also, recall that skimping here may cause cost overruns later when you determine you did need more training or support. Assess the vendor track record. How many clients do they have? How many times have they solved the problem(s) you have? Ask about failed implementations and what caused them to fail. Be suspicious of anyone who says they don't have any. Closely assess their implementation team. Does the vendor have in-depth knowledge of not only the tool but your business process? Have they been "on your side of the table"? Have they been an HR manager or comptroller or auditor or finance officer and done the tasks that their tool addresses? Contact numerous clients that are currently using their product. Spot check the specific features you are counting on using to see if the reference is using them. We have seen vendors provide references that did not even use the product being evaluated! If the vendor can not provide an extensive list of clients who use the product, or they do not have extensive experience solving your exact issue, determine whether your organization is prepared to be a guinea pig. We have seen numerous organizations stuck in limbo for years while their vendor tries to build what was promised. Go back to the expensive vendor(s) and ask why they are so expensive. Do they charge a premium because on their brand? Did they consider something the others didn't? Was there an error in one of the pricing variables (point 2 above)? Assess the low-cost vendor's stability. One way to do this is to consider their financial health, if possible. If the company is publicly traded, have they ever shown a profit? Do their financial statements look like those of a stable, successful company? If the vendor provides their software as a service (SAAS), there may be other considerations for evaluating performance. You can find some interesting articles on SAAS performance here and here. If the company is not publicly traded, it can be hard to perform this analysis, and you may need to rely more heavily on steps 1–6 above. It's a good idea to follow these steps even when there is no major pricing disparity. They become absolutely essential when you're presented with what seems like a sweetheart deal, and you want to avoid the cheap solution trap.
During selection of a new IT system beware of defaulting to the low-cost solution. 7 easy steps steer you away from project failure.
READ MORE
How to Improve IT Project Success with One Calculation
- Jamie Black
- Efficient, Effective and Reliable
- minute(s)Information Technology projects can be the most complex and high-profile you will encounter as a finance team member. Perhaps you have read about the trouble with the Phoenix payroll system implemented by the Canadian public service. Or maybe you have direct experience with severely compromised IT investments at your place of work. There is no shortage of such examples. So, what can finance do to help? In October of 2016, the Auditor General of British Columbia made some suggestions in their report "Getting IT Right: Achieving value from government information technology investments." A 60-Second Overview Regardless of your industry, the report is a valuable read for accountants, and we recommend reading it in full. Here is a quick summary of its major points: IT is important because "every aspect of government depends on IT." Only 29 percent of IT projects globally are rated "successful." Success is defined as: On Time On Budget AND Value Success depends on: People Planning Consultation Governance The report is an absorbing read, but it fails to elaborate on a significant element: What is "value" and how do you calculate it? What about "Value"? The report uses the word "value" 57 times without defining it explicitly. The only comment on how to achieve it is to assess: Alignment of the project with the organization’s specific needs, priorities, and strategies Contribution to the organization’s desired outcomes Cost Level of risk While these are good points, they provide no particular direction to those attempting to assess a project's value or measure the success of a project during or after completion. ROI to Assess Value Before & After Perhaps it's because we believe that numbers are the key to all universal truth (no really, we do), but we argue that finance should calculate proposed and achieved value for IT projects. The accountant in us is very comfortable with Return on Investment (ROI) calculations: This type of calculation should be used to determine optimal use of your organization's investment. But in our experience, these calculations are rarely utilized when considering IT solutions, particularly in the public sector. Why? There are at least two problems with the word "profit" in the context of public sector IT projects. Public sector organizations typically do not think in terms of profit. Even if you work outside the public sector, you may reasonably ask, "How does an ERP system (for example) generate profit for any organization?" "Profit" (and therefore "ROI") may seem like a non-starter. But with a minor change in terminology—replacing "profit" with "calculable benefit"—the concept is applicable to the public sector. The "calculable" part is important; you don't want this exercise to dissolve into imprecise speculation about intangible benefits. Those may also warrant a discussion, but you should not give up the important quantitative analysis. You should focus on those aspects to which you can assign a real dollar value. There are two broad categories of calculable benefits that you should consider: Efficiency of Staff Resources Your staff spends their entire working lives involved with IT systems. A more efficient, convenient, and highly automated solution will help them do their work faster, more reliably, and with less cross-checking and manual review required. If you estimate the hours that a new IT system might save, and multiply it by your staff's hourly cost, you can measure the economic impact of those time savings. Reduction or Avoidance of Direct Expenses There are many direct expenses that a new IT system can help reduce or eliminate. You pay fees to an external accountant—would those fees be reduced if you automated a significant portion of the work they performed? What if your new system could help avoid late payment of invoices and thereby reduce your late fees and penalties to vendors? Perhaps a new system would provide a reduction of ongoing annual maintenance and support costs. An Example Consider a scenario where your current ERP system is no longer supported. You determine that the risk level of continuing with an unsupported system is unacceptable. You have identified three possible solutions and are working through the selection process. You have seen demonstrations and received fee estimates. You have contacted references and determined each option's strengths and weaknesses. Clearly, there are many considerations (some of which are intangible). But don't underestimate the value of performing an ROI calculation. Calculable Benefit: How much money will we save with each solution? For example, estimate the following separately for each solution: Hours of staff time saved by reduced data processing Hours of staff time saved by automating report creation Estimate avoided late payment fees to vendors due to improved A/P processing abilities Decreased finance costs due to accelerated AR collections Cost: What is the cost of each solution including all features/modules etc. necessary to facilitate the above benefits over a 5 or 10 year period? 3 Advantages of This Approach 1) Forces Detailed Assessment: All too often we see clients who have only a general understanding of how a particular system will help them. Vendors often do little to help, aside from offering marketing double-talk: "Work Smart", "Improve Productivity", or "Improve Efficiency." These aspirational comments are great, but you need measurable results. 2) Easy Comparison of Alternatives: You can immediately begin to see some interesting relationships between the options that were hard to see at first: Solution 3 is four times as expensive as Solution 1, but it provides 4.5 times the value. If all else is equal, and the organization can find the $100,000 budget, Solution 3 is the better choice for your organization. Solution 2, while more expensive than Solution 1, does not provide a commensurate increase in benefit. Thus, if the budget did not allow for $100,000 investment, the next best option is Solution 1. 3) Clear Monitoring of Performance: Another advantage of this approach is that your team has identified very specific, measurable goals to monitor the project and assess success. For example, you estimated a calculable benefit value based on specific time savings in report creation and data entry. These time savings should be measured to determine whether you achieved the benefit. Moreover, if your vendor is confident in their abilities to deliver these time savings, you can attempt to include attainment of the advantages into the contract. "IT-enabled projects aren’t just about technology—they involve substantial changes to an organization’s culture, business processes, and customers. These projects are really IT-enabled business change. A successful project improves services and allows for more effective use of taxpayer money. And their success or failure is about more than just being on time and on budget, it’s also about achieving expected value." –Carol Bellringer, FCPA, FCA Auditor General, British Columbia In sum, ROI calculation is an important tool that allows finance teams to estimate, measure, and demonstrate the value of their IT project.
From replacing your ERP to implementing a new payroll system we illustrate just how powerful ROI is for setting & measuring IT project success.
READ MORE
Is Self-Implementation right for you?
- Jamie Black
- Efficient, Effective and Reliable
- minute(s)For government finance officers looking to make the most of tight budgets, efficiency is key. The RIGHT tools and technology can significantly improve efficiency, provided you can muster the resources to purchase and implement them. Many of our clients are looking to implement technology as inexpensively as possible. Some consider self-implementation. How do you know when this approach is right for your finance or budget department and when it is a mistake? This article examines the criteria that determine whether you are likely to succeed in self-implementing a new finance-related system (ERP, payroll, Comprehensive Annual Financial Report (CAFR) or financial statement automation etc.). Over the past 20 years, we have implemented hundreds of technology solutions for clients—CAFR and financial statement automation systems, custom-designed mobile applications, ERP systems, local and wide area networks, servers, and, of course, continuous monitoring systems. During the course of these implementations we have tried any number of models: 100% delegation of implementation tasks to client's staff 100% retention of implementation tasks by our team Every task-sharing split possible We have achieved successful outcomes with each of these options. But frankly, we have also had some disappointments. Our wealth of experience has informed the following guidelines for determining the right approach. Self-implementation Requirements: When you engage consultants/vendors to help with implementation, there are really two major benefits that they provide: relevant expertise and time to dedicate to the project. As you consider whether your organization can self-implement a particular system, assess your team to see if you have the "right stuff" in these categories. 1) Expertise: An objective assessment of your team's expertise is critical to ensure you are capable of taking on the implementation yourselves. Technology: The initial configuration of some systems requires considerable technological knowledge, at a level not necessary for day-to-day operations. Server setup, database configuration and optimization, and development of custom code for integration with existing tools, are a few common areas of expertise required for initial setup. Do your team members have this expertise already? If not, you should carefully consider whether it is wise to invest your time and money to develop this expertise internally in order to self-implement the project. On the other hand, some systems do not require such sophisticated technological expertise about support systems. Perhaps all that's necessary for self-implementation is strong knowledge about that particular application and its day-to-day features. In some cases, a strong user of Microsoft Windows and Microsoft Office could have all the technological expertise required to self-implement. Questions for the software vendor: What technology does your system rely on? Are there servers to set up or databases to administer? Is there any programming or scripting required to implement this system? Specific subject-matter: The level of subject-matter expertise required depends upon the system you are implementing. If you are implementing a new ERP system, are you expert in the functioning of your current system? Have you worked with many different systems? Have you ever been responsible for administering a new ERP system? If you are considering self-implementing a year-end reporting automation tool (CAFR/financial statements), does your team have ample experience preparing these reports today? Do you understand how these balances come together and know what G/L accounts get grouped into each number on your statements? Or perhaps this your first year-end cycle, and you do not have the support of those who prepared prior year reports? Questions for the software vendor: What subject-matter skills do you require of your implementation consultants? What experience is essential for a successful implementation? When you have seen implementations fail, what skills were implementation team members lacking? Project management: The size and complexity of the project will determine how sophisticated your project management skills will need to be. For example, if the project requires collaboration across a large team, over many months/years, with many individual milestones, lots of complexity and great risk should the project fail, you will want a very seasoned, professional project manager. On the other hand, if the project will only involve one or two people, is reasonably straightforward, and you have a great fallback plan in the event of delay or failure, basic project management skills may suffice. At a minimum, we recommend assigning project management duties to someone who exhibits great attention to detail and strong organization and communication skills. For some systems, this approach might be sufficient to guide self-implementation. Questions for the software vendor: How long and complex is a typical implementation project? Do you offer project management services if we decide they're necessary? What guides or checklists can you offer us to assist in managing a self-implementation? 2) Staff Availability: One of the many reasons organizations pay for professional implementation is not due to a lack of expertise but a lack of available staff time. Being short-staffed or just overloaded with work likely means that you will not be able to prioritize required implementation tasks and you will wind up with a system that is never fully/properly implemented. For many systems, considerable time is required to successfully implement the tool. The tasks may or may not be complex from either a technology or subject-matter perspective, but they may take considerable time. You need a clear understanding of how much time is required of your team and how much time your team has available. Consideration should also be given to how frequently you will need to break off from the project to tackle your other duties. The more frequent the interruptions, the more difficult it will be maintain momentum, remember training, etc. Questions for the software vendor: How much time would you allow for your consultants to implement this system for our organization? How much more time should we allow, given we do not have your level of experience? Should we multiply the vendor's time estimate by 2? By 3? Measure Your Options As you obtain answers from your vendor, score and plot the responses on a graph like the one pictured here. Projects that fall into the green zone are obvious "self-implementation" candidates. If you plot your project in the yellow or orange zones, the demands of the project are higher and careful consideration of your availability and/or expertise is warranted. Should you determine that the project falls into the "red zone" it usually means that it would be wise to abandon self-implementation and investigate other options. Joint Implementation The decision between self-implementation and fully outsourced implementation is not an all-or-nothing choice. Another option to consider is sharing the workload with the vendor in a joint or guided implementation. You may be able to do large portions of the work yourselves, which will yield significant fee savings and make strategic use of the vendor team's expertise and time. Use their team to provide oversight, remedy any expertise weaknesses, or cover any resource availability issues you may have. By balancing the use of your time, your expertise, and your budget for external services, you can often develop an implementation plan that provides the highest return on your technology investment.
To implement technology as inexpensively as possible many governments consider self-implementation. How do you know if this is right for your organization?
READ MORE
