It’s hard to take the time to communicate when in the midst of a huge development effort. My New Year’s resolution is to give updates once a week, so herewith the first:
SurvivalWare.Net* is well under way. In addition to the standard Simple and Fort Knox models, we’ve actually got one customer model running under the new version. I find I hate going back to SurvivalWare 2015. If you’ve been to our website recently (apologies in advance if you have) you’ll notice that you can’t actually buy SurvivalWare off the website. We’re in the enviable position of not taking on new customers at the moment. Our focus is on this major technology conversion and product upgrade. We’re still actively supporting current customers and will provide additional software licenses to them as they need them. But we don’t anticipate taking on new customers until the second quarter of 2016 at the earliest.
There is still a lot to do. Our internal release date is April 2016 – but that could change based on the demands of a certain special client. Next week, I’ll go into more detail about what has been done, and what needs to be done to SurvivalWare.Net.
In the meantime, I have agreed to serve as interim Finance Director for this special client: a 40 person software company with a substantial customer base, and about to experience a spurt of growth. I’m just about done with their budget for 2016 and a highly customized projection model. Their business is complicated – a mixture of Cloud, Premise, and Lease customers – each with their own cash flow and profit profiles. The business is changing quickly, so we have decided to go with a 90 day rolling budget, and update every quarter.
For a software company, the biggest expense and strategic decisions really concern people. I decided early on to come up with an efficient way to forecast salary expense, and to react quickly to changing plans for new hires, terminations, raises, and departmental assignments.
Originally I decided to use the pay-master table exported from our payroll service provider to get the master list of employees, hire date (to determine date of next raise), annual salary, and departmental assignment. I wanted to use it “as is” with no human intervention to keep things efficient, and reduce the opportunity for error. But after the initial round of projections, and a poor attempt to cover new hires as lines in the model, I decided to use the pay-master file as the starting point and modify it slightly. I added new hires to the end, and expanded the number of fields to allow multiple raise dates, and tolerate Dollar Amounts, not just percentage increases. I also added a column for a Termination date – for expected terminations, and as a way to re-assign an employee from one department to another as of a certain date.
I also decided to put in a column for FTE count (set to 1.0 for a full-timer, or some fraction of 1 for a part-timer) instead of importing departmental FTEs from a separately maintained spreadsheet. We have at least one situation where an employee is split between two departments, so for expedience I just copied the employee info to a second line, and cut the salary in half, and set the FTE count to 0.5 for each department.
Going forward, this file will need to be manually maintained, but it shouldn’t be a huge burden – just a handful of changes each month. Also, it is good to force someone (like me) to scrutinize the list each month to make sure the forecast is accurate, and to keep an eye out for salary inequities.
There is an applet that reads this master file, and projects out the salary expense and FTEs by department for the rest of the current year, and for the 12 months of the following year. The applet takes about 30 seconds to run. At this point, 50% to 60% of the expense budget has been done.
It should all be downhill from here, but the devil is in the details. Coming up with a credible revenue forecast is really difficult. It’s going to take a lot of analysis to separate the “predictable” (e.g. monthly subscriptions, maintenance renewals) from the volatile (Premise Licenses, Annual Cloud subscriptions). There is the further complication of needing to defer revenue for Annual Maintenance Contracts, and Annual Cloud billings – and recognize the revenue over the life of the contract (usually one year).
The last 40% to 50% of expenses take some thought – especially for marketing, and technology upgrades. These are the two most discretionary spending categories.
As you have probably guessed, this is an “opportunity of a lifetime” for a financial modeling software developer like myself – to be thrust into the position of power user of my own software in a real world setting. I get to feel the pressures firsthand, experience the challenge of continuing to provide accurate information while building out a series of analysis and planning models, that seem to constantly change. I shudder at the thought of having to do it in spreadsheets. I just don’t have that kind of patience. It wouldn’t be fun. I’d lose sleep worrying about the accuracy of the data I was providing.
Not that there haven’t been hiccups with SurvivalWare. It’s just that as I experience a pain point – or some clumsiness, or drudgery, or a propensity to make mistakes – it makes we think “what can I do to improve this?” or “what would make it less boring and more fun?”
What is shaping up is not just SurvivalWare.NET, converted to a new technology platform. But rather a quantum leap in usefulness and usability – and “fun.” The CEO of my special client has said more than once – “How can anyone get by without this?!” This while we look at projections for 2016 and dug into the assumptions and trends. He is data-driven and loves to see things graphically (my bias as well). We have lively “GoToMeetings” that often raise more questions, and iteratively improve the model and the forecast. It is the process of model customization and continuous improvement that I am trying to get right with SurvivalWare.Net. I feel like I should be paying this client for the privilege, not the other way around.
* SurvivalWare.NET – a conversion of SurvivalWare from Visual Basic 6.0 to the Microsoft .NET platform and VB.Net. The project started in earnest in June, 2015. Models and data files from older versions of SurvivalWare can be used without modification under the new version. We’re hoping to release SurvivalWare.Net in Q2, 2016.