SOFTWARE PROJECT MANAGEMENT—GENERAL LEDGER PRODUCT SELECTION

Part 1 Getting Started

The CFO is a project manager pretty much 100% of the time. The budget, the audit, the monthly financial statements, and the smooth operation of the business office are all projects, so when it comes time to find, purchase, implement, and maintain software, many of the skills you already have will come in handy. You are probably running four or five software programs already.

In this two-part series we will explore the landscape of general ledger software selection, breaking it down into five stages beginning with assessing feasibility and ending with negotiation of a contract.

I have chosen a complex example—general ledger selection—to cover the full range of challenges the CFO, as project manager, is likely to encounter. You may never have to select GL software but will probably be called upon to lead smaller projects.

We will stop short of implementation here because every project is unique at that stage. But the framework I have set out, which includes three core principles of software project management, will provide guidance and moral support for implementation and any other software project you undertake. These principles come from my experience; you may discover your own, but this is a place to start.

A software project starts with the identification of need. QuickBooks has emerged as a giant in the field of general ledger software for small businesses; new nonprofits frequently use QuickBooks to get started. But it is not specifically designed for nonprofits, and as the nonprofit grows past revenues of, say, $1 million, the CFO will be anxious to upgrade to a more sophisticated solution. We will use this scenario for our discussions.

Let’s start out with the principles that emerged from my experience and eventually gave me a reliable guide to software project decision-making.

Software Project Management Principle #1

For the CFO, managing the project must be hands-on.

In the majority of cases the CFO is the liaison between executive management/board, the IT department, the vendor, and the users. You will envision the project, make the decisions, and fix the problems. The participation of the users is essential without a doubt (see Principle #2 below), but almost inevitably, a software project will sink without a strong and determined leader.

Software Project Management Principle #2

Success of the project depends on a collaborative, team approach.

Your core team will be you and the other users of the system plus the IT department. Don’t underestimate the role of the IT department even if they don’t attend every team meeting. Only they can make your new system work within the organization’s infrastructure; they are a critical partner and should be updated and consulted often.

User buy-in is a bit of a cliché these days, but even so, I must stress that the project can only succeed with all-in user involvement. I once witnessed an effective reporting and budgeting software solution be abandoned after implementation because the staff didn’t recognize the need for it and were not given adequate training. I have also seen employees leave a job because they couldn’t overcome their dislike of a new system.

I suggest that to achieve user buy-in you assemble the team early and meet with them regularly, giving everyone the chance to voice their wants and needs. Take their ideas seriously and be prepared to provide the training they will need to love using the new system.

Software Project Management Principle #3

Successful software implementation is almost always more difficult than you expect, and as the complexity increases, so does the risk of failure.

As you move through the stages of software selection you will encounter decision points. The choices almost always break down into the simple way and the complicated way. In every situation both options will have their merits and their flaws. You will be called upon to decide which is the appropriate choice for the situation. Principle #3 will come up often in our discussions.

The Stages of GL Software Selection

We will now look at Stages 1 and 2. We will explore Stages 3, 4, and 5 in Part 2 of this series.

Stage 1: Explore feasibility
Stage 2: Develop the project framework
Stage 3: Product demonstrations
Stage 4: Product evaluation and selection
Stage 5: Negotiate purchase

Stage 1: Explore Feasibility

Document User Workflow

Your success as the project manager (PM) will depend on your understanding of how each person uses the GL software to carry out their responsibilities. Be prepared to ask questions and observe each individual doing their daily work so you can increase your familiarity with all of the tasks and how they fit together. Be on the lookout for how a software upgrade can raise your operations to a new level.

I recommend that you document your processes, whether that involves diagrams, lists, charts, or just narrative—use whatever tools you think are best. Not all CFOs are willing to go into the weeds in this way, but I stand by Principle #1.

Research Software and Develop Rough Cost Scenarios

As you work with the team to document your workflow, some criteria for new software will emerge. Your research into the capabilities of products on the market will give you new ideas about what is possible.

This journey has to start by identifying potential software packages that are suitable for a nonprofit of your size. Do you have one in mind already? If not, perhaps you can ask for recommendations from colleagues at other nonprofits, from contacts you have at local or state associations, or from your auditors. If they have a large nonprofit client base they have probably seen a variety of GL solutions. You might be lucky enough to identify a nearby organization similar to yours that is successfully using a potential solution. If so, ask for an in-person demo. Of course, you can always find products online.

However you arrive at a list of suitable choices, you will want to call the vendors with a short list of questions to find out which products warrant a closer look. Your goal is basic information only—try to avoid getting the sales reps overly excited at this point.

Here are some suggested questions.

  • Does your software provide functionality designed for nonprofits such as cost centers, budget reporting, and distribution of revenues and expenses at the transaction level?
  • Is the software accessed through the cloud or does it reside on the organizations’ server to be accessed by the finance department through the organization’s internal network?
  • What is your experience and commitment to serving nonprofits?
  • Can you give me a general idea of the per user annual cost?
  • And what about the cost of implementation and training?
  • What other costs do I need to consider?
  • If we decide to pursue this software, can you provide references for similar organizations that use your software?

If you have certain hard and fast requirements now is the time to ask about them. For example, distribution of revenues and expenses at the transaction level should be a non-negotiable requirement for a next-level upgrade. You can eliminate any program from consideration that does not offer this capability.

You will also want to get a sense of the pricing structures so you can compare the products to each other.

We are still in the exploratory phase. If you speak to a few vendors, a picture will start to emerge of the features that are commonly offered, the price range for software of this type, and how the software is accessed by users.

Ideally, you are now able to develop a side-by-side comparison of a few products, showing roughly the capabilities and the costs of each. The information is only ballpark at this point. Until you go through the demo process and receive a formal proposal you cannot finalize a budget, but you can gather enough information to get your ED’s approval to move to the next stage of the project.

As you discuss your findings with your ED it is important to present the true picture. Cutting corners to assure their approval is a terrible idea. The last thing anyone wants is to find at every stage that your estimates were too low. I recommend adding a 15% or 20% contingency factor to cover the myriad unanticipated costs that are almost guaranteed to pop up. You and the ED must be of one mind about finding the resources to pay for the project. Postponing it until adequate funding is assured is a better option than charging ahead with unrealistic cost estimates.

Stage 2: Develop the Project Framework

During this critical stage you, the PM, will lead the team in setting the project timeframe and developing the list of criteria for selection.

Setting the Project Start and Go-Live Dates

You need a timeframe to work within. Let’s define the project start date as the day you set the project in motion, i.e., the day you decide to commit yourself and your team to making this happen. The go-live date is the day you start entering transactions into the system.

The ideal go-live date is the first day of your fiscal year, say, January 1. Working backwards, you will identify the project start date. I like to estimate 6 months from start to go-live, but four or five months might be adequate depending on your circumstances. You can be sure though, that with a January 1 go-live date, implementation will take place during November and December. But that activity will collide with your budgeting, year-end close, and/or auditing cycles.

You will have to consider the tradeoff between this approach or a go-live date of, say, July 1 (January 1 project start date) or September 1 (March 1 project start date). Anything other than a January 1 go-live date will mean reporting from both the new and the legacy systems until you reach the end of your fiscal year. Say you go live on July 1. The year-to-date data on your monthly budget-to-actual reports will be drawn from both systems for the months of July through December. This will be inconvenient but may be preferable to implementation during the last two months of your fiscal year. I recommend that you talk this out with the team and take into consideration the demands on everyone’s time in all scenarios.

Developing Criteria for Selection

The majority of your team meetings will be devoted to further developing criteria for the new system. Now is the time to discuss and prioritize your needs so you will be well-prepared for product demonstrations.

Topics will include:

  • Must-have basic elements
  • User interface
  • Feature upgrades
  • Reporting
  • User-defined fields
  • Integration with other products

Must-have basic elements: Start by identifying the functions you need to see in the new system. In addition to general ledger, you will probably need accounts payable, accounts receivable, check-writing, and bank reconciliations, along with other functions essential to you such as 1099 tracking with tax form preparation. As I mentioned earlier, distribution of expenses and revenues to the cost centers as transactions are entered is a must-have for every program you look at.

User interface: Taking the time to learn where your members are comfortable with the current system may go a long way towards gaining their allegiance. The simplest features such as data entry screens, order of operations, or ease of saving and recalling data are the seas that the users swim in all day every day. For sure, they will have to learn to do some things differently in a new system, but there may be choices to make, and the PM’s sensitivity to the members’ preferences can make or break a project.

Feature upgrades: Next look at areas that need improvement and new functionality that you would like to add. Recalling Principle #3, be careful about increasing the scope of your project unless the anticipated rewards outweigh the risks of overcomplicating it. During your initial research you may have come across functionality that you don’t currently have, and the vendor is likely to proudly promote the many features they have to offer.

Some may be truly worth looking at. For example, the ability to download cleared checks and deposits from the bank is a feature that may very well win out by saving time and adding efficiency. Other functions may or may not be appropriate for you, depending on your operations.

Purchase order modules allow you to track a purchase starting with supervisor approvals, then moving through the order, receipt, invoice, and payment phases. You may not have enough volume to make this worthwhile.

Grant-tracking is an important activity, but be wary of claims by vendors that they have the perfect solution. If you have already devised a methodology for tracking and reporting grant revenues and expenses you may opt to stick with that. Specialized software solutions may not be superior to good old accounts and cost centers.

The same goes for budgeting. I have never seen a GL system that could provide full functionality for budgeting. I have always used spreadsheets or dedicated software for budgeting, and I suspect that the chances are high that you will be creating your budgets outside of the GL system. If that is the case you will only need the capability to import your final budget numbers, and, of course, to report budget-to-actual revenues and expenses by month, quarter, and year.

Reporting: You know what your needs are. Consider making a list of the reports you must have so you can be sure they are covered during the demo. Look for drill-down capability. You should be able to drill down to the transaction level from any number in any report.

User-defined fields: Any software designed for nonprofits will provide capability to categorize your transactions by cost center. But many nonprofits want additional, customizable, fields for further categorization. Some day you might want a unique code for each of your fundraisers so you can run a full report on each. Or, a school might want to assign a code to each student. There may be a maximum number of fields, so your software should include an adequate supply of them for future use.

Integration with other products: You may be running stand-alone software programs that could be integrated with your GL, such as fixed assets, dedicated budgeting/reporting, third-party billing, or fundraising/donor management.

Sometimes integration solves a big problem or takes your operations to a new level. On the other hand, software integration projects can be tricky so, again recalling Principle #3, don’t be in a hurry to take them on. If your fundraising/donor management system is working well, do you really need to store the granular data in your GL system? Chances are you can use the fundraising system as your “source of truth,” using reports to sync up totals with the GL. In any case, the team should talk about whether your final selection should have this capability.

In sum: I surely have not touched on every criterion you and your team will consider. But once you think you know what you are looking for it will be time to look at the products themselves to get closer to identifying the capabilities that are the best fit for your organization. Read on as we move to the demo stage.