This is the first of several articles reviewing best practices in software development for community banks and mid-sized credit unions.
You have been asked to approve the expenditure for a material investment to develop a software solution customized for your institution. Given 50-80% of all software projects fail(1), you should be concerned about the likelihood of success for this project. However, your financial institution, commercial bank or credit union, has unique market opportunities. When combined with historical compliance restrictions, your institution needs unique features not included in any of the standard software offerings. If you’re going to retain your market advantage and gain efficiency, you’ll need to heavily customize software.
How can you increase your chances of success and gain positive ROI? You already have formal monthly IT Steering Committee reports, weekly management meetings and an active risk management committee. You’ve completed your risk assessment. You’ve had success in the past with smaller projects, like customizing mobile banking and working on APIs with your core provider. What else can you do to decrease risk and increase your return on investment?
Here are some of the best practices in budgeting, project management and testing proven to increase the likelihood of success.
Budget
The Association for International Product Managers and Marketers (AIPMM) estimates the initial budget for any software development project could vary as much as 4x. Given the initial requirements, understanding needs and estimation tools, your actual expense could be as much as 4 times the original budgeted amount.
If one considers the entire project, 4 times the amount of the initial project starts to sound conservative given, if successful, the need to upgrade infrastructure to store additional data, train users, market the change internally and reward those who have successfully migrated their processes from one solution to another and possibly adjust core software parameters. Additionally, newer technologies may carry with them higher market valuations for your staff members who have mastered new skills. Compare these cost estimates with increased value of your intellectual property, actual efficiencies captured from the new solution and increased customer satisfaction.
Best Practices
- First: The best way to ensure a higher ROI is to design the project to be as small as possible, solving the single most critical need. Using the 60-40 rule, start with a solution solving 60% of the problem. Is onboarding customers taking too many resources and customers drop off? Then focus the solution on the greatest pain points first. Solve this first.
- Ensure reporting, compliance and user training are in place before starting additional development phases. This may mean higher IT development costs to reassemble teams, but your costs will be more predictable and easier to justify.
Minimum Viable Product
The Minimum Viable Product or MVP is the part of the entire solution to be completed for the project to have value to its target users. If you apply the concept of an MVP to your internal projects, you can achieve the same results by understanding and documenting the most important problem(s) to be solved and then design the solution to solve those and only those problem(s). When thinking small, start with the MVP which could be less than 60%. Then build from there until you get to 60% of your problem. This could mean that a key client is not provided the new features at first. By starting small and building team competencies, you increase the possibilities for long-term success. Development should be a journey of many small steps, interspersed with projects that leap forward with new technologies.
Slippage – Your red flag indicator
Assuming you’ve moved forward with the project as a MVP – which includes all of the necessary parts required to succeed, including compliance and reporting, training and documentation, the next thing to look for is slippage. If the development team slips in its early timelines, do not assume hard work, increased resources or minor reductions in scope can bring it back into alignment. As Benjamin Franklin once said, lost time is never found.
The time lost is rarely recovered without significant changes in scope. Hopefully your team will be honest with you as to why the project is behind schedule. Unfortunately, if your development team is an external vendor, contractual and cultural differences may make it difficult to find out why. You’ll need to discern from the various stories what the truth may be. Watch for group think. Be suspicious if there is not a range of opinions as to why the project is delayed. Differences of opinions about slippages indicate healthy communications. Assuming good team dynamics, early slippage can be from a range of issues including: a failed design, wrong vendor, other IT infrastructure issues, confusion from your business owners or a failure to have an effective project manager. It also can be an early indication of bank or credit union resource constraints, signs of an overwhelmed team unable to complete their day to day jobs and take on the new work imposed by the development project.
Early slippage is a gift. Use it to kill the project, get resources or change vendors. Regardless, you’ll need to adjust cost estimates and decide to continue or put the project on hold until the problems causing the slippage can be fixed. Does your contract allow you to cancel the project without no or minimal penalties?
Document Your Objectives – before the project begins
Broad or unclear goals can also create slippage. Or in the desire to justify the project, the MVP wasn’t actually the MVP but fit the desires of the highest paid executive associated with the project. By starting each project with a written project statement including, the goals, high level timeline, people needed, technology risks, budget, communication strategy, training strategy, and contingency plan. With more advance planning, you’ll increase your success for your customized project.
By keeping your projects smaller, tied to clear goals, focused on the highest value, and with honest communications, your investment in custom software will generate a significant positive return on your capital investment.
Testing
The most important and time consuming part of the project is spent testing, designing the test plan, gathering or building the test data, testing and documenting and providing feedback to development. Most development teams use the Agile development method – meaning you’ll receive new code to test frequently, either every other week or every third week. The faster you can run your test data and provide feedback, the faster your solution will be ready. While seeming obvious, for most mid sized projects, this means months of testing – more specifically – months of diverting resources to testing. You’ll need to budget and have assigned testing resources on a schedule unlikely to align with routine work or customer needs. Many financial institutions ask staff to take on testing as part of their regular duties. However most teams do not have as much flexibility in their schedules or enough slack to build test data and complete end to end, main path or the edge testing required to build a reasonably risk free solution.
Testing Resources
One solution is to contract with your software developer to do additional testing. However, generally the developers do not understand banker or customer behaviors well enough to create good test data, let alone detailed testing scenarios. A better solution is to match a subject matter expert with contractors or a contracted subject matter expert with specific domain knowledge for your project with staff members. The first, using an in-house subject matter expert augmented by temporary workers, or testing software, works if your in house subject matter expert is dedicated to the project, understands budget constraints and is focused on launching the product. As an added benefit, you may find future employees in the mix of temporary employees assisting your in house expert.
However, often the in-house subject matter expert is already occupied with servicing clients, supporting the team or meeting other production goals. In this case, hiring a subject matter expert with experience with your business niche, with your core provider or with a history of providing testing experience with financial institutions can fill the gap, extending staff productivity.
When contracting a subject matter expert, you should be concerned about knowledge transfer – not only transferring the information about the application but about the decisions made during development and the reasons behind the decisions. Understanding the decisions and the reasons behind the decisions will help your team plan buy into the solution. It will allow you to budget for future enhancements, for your production staff to design work-arounds and provide support for other operational, audit or customer-facing changes created with the launch of your new software application, be it cloud based or server based.
Testing Design
Testing is hard, time consuming and if not designed correctly and with the correct tools, very expensive. One way to reduce the cost of testing is to build testing plans and data sets as part of your requirements. This means building and documenting test data sets as you define your requirements. As you work with engineering, make sure they understand which data samples are more representative of your customers and which are not. Some development teams will build only to the data sets provided and not to the full requirements.
The decisions having the greatest impact on your budget are made during testing. During testing, you’ll discover exactly how well and under what criteria key features work. Testing is likely to reveal weaknesses in other systems or their data, in the operations of other areas providing data or in your underlying infrastructure. It’s the project manager’s job to keep the team focused on the project’s goals including the requirements for the MVP and financial metrics. Capturing and leveraging the additional value generated from testing can only happen if the testing results are appropriately documented and communicated.
Use Cases and Happy Path
A use case captures the starting state of a set of actions, the actions and the end state. Think of a use case as a scenario or story, starting in the beginning with what’s needed or assumed, actions taken by the user as they journey through the application and the ending point generating the desired result. The story or use case capturing your primary or main flow through the application, called the happy path, should capture the most common and repeated behaviors leading to a positive result. Successfully testing your happy path is the baseline positive test for your MVP.
Once the happy path is materially built and tested, it’s time to concentrate on your exceptions. While some developers prefer to build in the most common exceptions with the happy path, I find many businesses trapped in exception minutia and lose focus. Better to look at each exception as a rarer but profitable type or segment of your business or process. Build as many of these as you need to capture each profitable segment. The final set of exceptions are your worst case scenarios – the rarely but still likely highest number of customers, products, users, etc. For instance if your document allows for 4 signers, the test data set for your worst case should include 6 signers. This type of testing is referred to as edge testing as it tests the boundaries or edges of your application. The goal of edge testing is to document which events or behaviors are outside your application. No application can do it all – nor on your budget should it. Because edge cases can create a fair amount of development work, budget any discovered important edge case as a separate project – or hold them until the end of the project to be prioritized along with other open issues for the remaining project budget. On occasion developers are willing to split the costs for interesting edge cases as these can build capacity or functionality for the developer and increase their market.
Remediation and Management’s Role
In addition to planning for edge cases, many institutions forget about remediation or the work needed to be done when something isn’t right. I recommend building the most common remediation actions into your happy path. Focus again on the most common actions and leave the less likely to occur behaviors to your exception and edge use cases.
Your subject matter expert will need to help engineering understand which edge tests are more likely to occur and which document the boundaries of the application. No application can handle all situations or every use case. Part of testing is to document where the application ends and which use cases should not work.
During edge testing, the Product Manager, with input from the team, will determine which edge use cases are material to the success of the application and which are not financially viable to address. During testing we recommend meeting weekly to review test results to ensure project objectives and to keep you informed as to the development compromises and future investments requirements. As the project progresses, many executives delegate routine project communications then are surprised when high level objectives are not accomplished. If the meetings seem too much in the weeds given your schedule and other commitments, then ask for a weekly one page report highlighting the decisions and items not working. Staff associated with the project will want to share positive news; insist on information on defects and progress toward the MVP.
Product Manager and Product Owner
When using Agile development, many financial institutions separate the roles of Product Manager and Product Owner, using the role of Product Manager to act as the subject matter expert. The Product Manager’s job is to understand the customer, understand the business goals and translate these to engineering. Product Managers work with Product Owners. The Product Owner is usually the person supervising the team who is actually using the software and delivering results to your company. Product Managers may create personas or sample customers with stories to animate and describe underlying data-driven observations. Good Product Owners listen carefully to feedback provided by Product Owners.
Some financial institutions may combine the Product Owner and the Product Manager role. Sometimes, this creates operationally efficient systems but with difficult customer experiences. If you’re lucky and your combined Product Owner and Product Manager is able to build efficient systems with good customer experiences. However, a material development effort is often too much work for one person, resulting in project delays or disenchanted customers. Given a customer focused operation, the project delays become quite common. For the sake of the project and your budget, add consultants to assist your Product Owner during development.
Most companies hiring consultants see a greater ROI as they can launch the software application significantly faster, gaining efficiencies or market faster.
Keep your project small, surrounded with attentive project management and a dedicated product manager or subject matter expert to increase your odds of generating the outcomes you want and the probability you’ll actually achieve your expected ROI while retaining staff will be greatly increased.
(1) Wikipedia software Project Management
Let us be your bank consulting company offering trusted banking solutions. Learn more about our bank consulting services. Stay in touch by joining our newsletter.