February 3rd, 2017

Internal Development is High Risk Development

There is a perception sometimes that doing internal software development will lead to a quicker, cheaper, focused outcome. Nothing could be further from the truth.

Internal developments often lead to massive over-spends, poor user outcomes and opportunities foregone.

To help decision makers avoid costly mistakes in this area, we’ve put together a table of items to consider and questions to ask yourself before you decide to take the plunge on coding a new mini-ERP for cash automation.

Cashbook Internal development
Product Functionality
25 years’ experience developing cash management solutions. Cashbook are specialists in this niche. Does my team have any previous cash application development experience?

What is their CV like in successful product developments?

Array of algorithms for auto-matching developed and tested over a decade Does my team have any previous experience developing cash automation technology?
30 different reports on cash processing What reports need to be designed, developed, tested?
200 banking interfaces developed Will need to be developed
Reference customers and visits available No references for an in-house project
Security built-in: access, user roles, transactions, Segregation of Duties Will need to be developed if under consideration
Cash Manager solution with look-up/analysis capabilities Will need to be developed if under consideration
Bank Reconciliation capability with 25 years’ experience and automation Will need to be developed if under consideration
AR Remittance capability with OCR functionality Will need to be developed if under consideration
Automatic integration with Banks Will need to be developed if under consideration
Product Roadmap with on-going improvements and enhancements Not considered beyond basic deliverables
Specialist support backed by an SLA Can my team find time to support and fix the new code?

How will issues be logged, enhancements made?  What is the ongoing cost of these developments?

Budget for hours and costs is known and has specific deliverables Estimates are quickly put together (<1 week).  There is no way in a short period to fully consider all the user requirements.
Development hours specified in Budget Do development hours have a Budget?  Internal resources are never free.
Implementation hours specified in Budget Do implementation hours have a Budget?

Internal resources are never free.

On-going Maintenance and Support cost is known Is there a Budget for on-going maintenance and support? Will resources be available for this?  What happens if the developer or contractor leaves?
Scope and Deliverables defined Scope and Deliverables are likely to change.

Internal pressures will drive the product development often leading to product re-writes and scope changes.

Project documentation includes feedback from workshops and site-visits, Analysis, Design, Specifications, Scope, Deliverables, Project Plan Project documentation will be minimal and may reflect the fact that an understanding of the project is still in its preliminary stages.  Developed on the fly.
Operational requirements for throughput, volumes, scheduling of processes and response times all part of project design beforehand.  Measurement and statistics built into product. Performance will depend on the solution developed, not on pre-defined targets.
Functional and Performance Testing schedule built into project Will depend on the progress of development.
Go-Live dates scheduled in advance according to the customers financial calendar Will depend on the progress of development.
Project resources assigned:

Technical, Services, Support, Project Management

Are resources available to see the development through to completion? Can they support it afterwards?  Do your people have external experiences they can draw on?
Established company with 25 years of experience in the specialist area of Cash Management across 20 different countries and multiple industries. Internal resources with a mix of skills, specialists most likely in own line of business.
Recognised as an expert in Cash Management by multiple ERP’s. Recommended as a Partner solution by several ERPs. Validation from multiple customers and partners not possible for an internal build.
Constantly improving solution based on feedback from 200+ sites Any additional developments must be specified, designed and developed.
Low risk investment


Working with a specialized software company which works to budgets for time and money is the safer option.

High risk investment


For software developments in Cash Automation, the high-risk option is internally developed software.


Standish Group on large software projects from 2003-2012:

–          Successful 6%  (satisfactory)

–          Challenged 52%  (unsatisfactory)

–          Failed 42%  (cancelled/unused)



81% of our 70 failed projects were underestimated; this leads to all sorts of problems in practice…When the customer does not assign enough time to do the requirements…you don’t know what is to be developed…an aggressive schedule that affects the development process, team motivation and team member’s lives. Staff added late to meet an aggressive schedule is still a major factor in project failure.

Live chat