In 25 years, you learn a few things! KRS has built up an enormous amount of business knowledge and IP over our quarter century of writing systems, thanks to some superb collaboration with various clients. I wanted to write down some of the key things we have learned – maybe they will help you in developing your next critically important system.
The main considerations for building or buying systems are usually cost and functional fit, but there are many more important issues to think about. Here are the top 5, from our experience.
Internal Business Expertise
The primary one is business knowledge. It can be very difficult to find one “super user” in a business who has the breadth and depth of business knowledge to define exactly what the new system should do. A team approach is generally the answer, with the concomitant higher levels of communication that are required.
The most successful Agile projects have a Product Owner from within the business, who is able to co-ordinate the many users’ requirements, and make final decisions on what functions to include in a new system. The Product Owner is ideally a dedicated position (certainly for medium to larger projects). The time commitment required from the business is sometimes overlooked – if your software team or software provider only has technical skills then all the business input has to come from your business team. Do not underestimate this!
Systems Thinking
KRS encounters many business users who are experts at their jobs, but are unable to translate their expertise into systems thinking. Consider how you handle the critical interface between software people and business people. A Business Analyst (BA) was traditionally used to bridge this gap, but with many possible poor outcomes.
If the BA is too far removed from either the users or the development team, interpretation errors will arise (broken telephone issues). Traditional BA’s wrote copious specifications upfront, which seldom stood the test of time. A fast paced business is unlikely to want a system developed from a 6 month old specification.
An Agile approach will bring the users and development team closer together, and reduce communication issues (with or without the BA). It will also insist on just-in-time specifications that ensure that features are relevant when they are developed. And Agile will help all parties to focus on why features are required, prioritizing by the value they deliver.
External Expertise
Bringing in an external development partner can provide a number of benefits, especially if the partner can add relevant expertise, and brings fresh thinking to the new system design. I hesitate to say “best practice” because this is such an over-worked term, and KRS believes it often implies that the provider has no idea why they do something, except that everyone else does! Not the best route to a competitive advantage through your IT systems…
KRS has 25 years of business IP across a number of industries. We really know our way around Debtors and Collections, which is hugely important in these recessionary times. We have also implemented low level communications systems, from alarm monitoring to SMS gateways. And many more areas, too numerous to detail here. We share this knowledge with our clients, and question habitual practices, to the benefit of the system’s final design.
Wastage
The two biggest wastes in building software are:
- Building the wrong thing;
- Building something too complex due to unnecessary extra features.
Einstein’s famous quote “A design should be as simple as possible, but no simpler” is extremely relevant is software development. Agile is a great help in insisting on small iterations that deliver value, especially if supported by good design practices like Domain Driven Design.
There are statistics that assert that almost 30% of the code in most systems is unnecessary! This is an enormous waste of time and money that could have been better spent on features that the business really needs.
Our best recommendation here is to be ruthless about asking why a feature is needed, and quantifying the value it will add to your business.
Team Dynamics
Extra development capacity is always required to build new systems. This capacity can be found internally by throttling development in other areas of the business, by hiring new staff, or by using a 3rd party company to provide the extra resources.
Third party resources tend to fall into the contracting category (you buy hours and nothing more) or the turnkey systems category (your provider takes responsibility for value delivery).
If you are just looking for extra resources, remember that a group of people does not immediately make a team. Treating people as resources only works on paper – in reality they need to learn to understand and trust one another before they become a fully functioning team. The best solution is to be able to develop your new system by using an established (and hopefully well-performing) team.
KRS has always provided much more than just extra development hands, and prefers to take responsibility for delivering the required system. We build and nurture high-performing teams, and can provide a ready-to-run team for new systems work.
Will you build or buy?
An innovative business is unlikely to find a packaged solution that will exactly fit their requirements. Owning your own software, and being able to change it as your business grows, is incredibly valuable. And business value is what it’s all about!
About the Author
Lorraine Steyn is a founding Director of Khanyisa Real Systems. KRS is fully committed to Agile principles on all projects: it brings out the best in our teams, and improves value for our clients.