The Importance Of Trust In Custom Software Development

As we dig into the finer details of coding unique projects, we find that making a great product involves a lot more than understanding the client’s needs. Sometimes the right fit not only has to be able to translate a series of problems into solutions, but they actually need a firm understanding of the business represented. Watch this video, and see how a deep knowledge of the business world and the legal industry made for an incredible software challenge worth taking pointers from.

Video Transcript:

Plexus software development case study – part 3

Ben (Alliance Software, Founder & CEO): When you were assessing Alliance Software, what were some of your hesitations and what made you take the leap of faith?

Andy (Plexus, Managing Director): The first thing is what do you look for in a partner to your business? You could talk about all the technical work and the custom software development and I’m not particularly well placed to answer that question.

The things that are important to me, and that most professional service organisations don’t get, is that most people are trying to solve a business problem. Most vendors; be it an accounting firm, law firm, IT vendor; orientate themselves around a specific technical domain. I look for people who get business and who hopefully get our business.

The second thing is I like dealing with advisers who say ‘do this, don’t do that’ from a base of experience. Law firms are famous for summarising a huge amount of analysis of legislative frameworks and saying here are the pros and cons – off you go. That’s not really valuable. People want to see a lawyer and have him say, I’ve analysed this scenario and this is going to be high risk, this is the way to go.

Then there are the standard things you look for in any relationship: integrity and trust and is there a track record of that?

Part of the reason I went for Alliance was those soft factors. Ben and his team not only came from a business perspective to our problems, but they have businesses they run themselves. Ben was able to say; with Content Samurai, this is what we learnt, this is where we went wrong and what I recommend is doing it this way. That had a bit of credibility.

The track record of being able to demonstrate credibility; I was fortunate, Ben was referred to me by one of my friends who runs a big software business. He said, we’ve dealt with heaps of IT consulting houses over the years and the thing that really impressed him about Ben was they said, this is what we’re going to do in this time frame and this budget and they did it. That was our experience ultimately in the project.

There were some final things. You guys got what we were trying to achieve. You had done some deep analysis on how to achieve it. The thoroughness of the planning prior to getting the work from us impressed us. Some of the other vendors came and said, let me show you some of the other things we’ve done and aren’t we wonderful. But they hadn’t done the analysis on our particular project.

Ben: Let’s fast forward. We won the project. Tell us about the development process and particularly, one of the things we’ve spoken about today is, the amount of time the client needs to invest often in custom software development. That can be bad news. It is going to take a piece of time of all our clients. We got to know Mel really well. It was nine months and four days a week she was in our business and she had a desk.

Tell us about the development process and what your experience was along the way and maybe some lessons that might be shared with others.

Andy: I run a professional service business and I’m sure many of you guys do too. The thing that I learned dealing with clients is that when something goes wrong, it’s always your fault. Sometimes that is justifiably so. More often than not I think it is because the client hasn’t invested in the relationship. The classic thing for a law firm is the client will say ‘I need you to do this’, in a one line email. One of our lawyers with the best of intentions will go and do what they interpret this is and surprise, surprise, the client says; no, that isn’t what I wanted.

I think the reason we had such a successful outcome was, 50% – 60% your team did a great job but the other 40%  is I had two of the best people I have ever worked with on this project. So we resourced it and had (almost on tap) for your guys, really smart people who knew what they were doing and who were really accountable. The first time round I did not have that. I did not have the caliber or the resourcing required to really make sure that we were doing our part of the bargain.

Ben: I should speak to this. It’s not true that every custom software development project requires the extreme amount of input that they’ve had. But you’re dealing in a legal space where the complexity was very high.

So there were two people, as Andy said, who played a role. There was Jess who would turn up once a week and do a project status update. We had to demonstrate and we had those regular check ins. She was keeping a view on that level. On the day to day, the domain itself was so sophisticated that what we ended up doing was putting the developer next to Mel. Mel would do her normal job. She wasn’t spending four days a week on our tasks. But what we did was we shortcut the communication cycles. We really short cut them.

Resmi who did a lot of the work would be working away. He would make one of the cards red. He would block it and he would lean over to Mel and say I just blocked a card. We managed to streamline the conversation really well. You don’t have to do that on every project, but it’s become a model for us. We like clients to come in. Clients can have desks, we have spare room, let’s spend time together. Even if you do other parts of your job, that’s no problem. We like to have you there as much as we can, particularly in that nutty bit where you’re working out the hard parts that are complex.

Andy: It’s one of the things that we say to our clients – when we’re at our best, we’re an extension of your desk.

Ben: Talk to me about visibility through the process. How did you feel you were going? I’m not asking this of Jess, the project manager, I’m asking it of the owner who is sitting separate from Jess. How did you feel in terms of visibility, knowing what was going on, feeling like you had a sense of the progress of the work? How did you feel about that?

Andy: I read a quote recently, which I think is a great one: ‘don’t micro manage, metric manage’. I think the benefit of having an IT consultant/project manager who is the CFO meant that we had metrics and stage gates on every section of the project. I’d hear things and people would ask questions, but only every couple of weeks I’d have a project update meeting and get this beautiful dashboard presented to me. I had great clarity.

At the outset of the project start, I’d just had a son. I said to the guys, don’t mess this up – I want George to get a good education. As it went through, it was amazing. I said, if I didn’t trust you guys so much, I’d think you were trying to pull the wool over my eyes. Every time we were going through we were below budget, on time, below budget and on time. I think it was because of that rigorous approach.

Ben: One of the things I think happened; Jess who is the project manager and is a good friend and is very sharp, comes from a world where she is very used to waterfall development. So she is used to those things we discussed earlier. She is used to a lot of upfront planning and then appropriate execution all the way through.

The challenge we faced was there were a whole bunch of details that changed. If you look at the wire frames, you can see that it is the same project, but there was a whole lot of evolution and we were trying to manage a budget through that process. I think a big part of the reason was that Jess was very pragmatic. She knew which elements of the system, and Mel knew which elements of the system, really mattered. A lot of that was interface elements and bits and pieces.

There were parts that we didn’t deliver because, by mutual consent, we’d agreed to focus on a different thing and so there was a reasonable amount of camaraderie through the project. I felt after two or three months we got to a base of trust where we could do that and we felt like we got some good outcomes in that.

Andy: One of the things from my perspective that really helped that is that from the outset when Ben and I were negotiating over fixed versus time and materials. I said, I get why fixed doesn’t work for you. You probably understand why time and materials is not a great outcome for me, because the incentive is the other way round.

So I said to Ben, the problem with a lot of software projects is scope creep. Scope creep is not your team’s fault, but it’s my team getting too excited about things. So I want to make sure we’ve got alignment here and we create a model that works for both of us. So we both aligned to deliver the best possible outcome at the best possible cost. We structured an agreement in that way.

From my perspective I had faith then that Ben’s team, and they demonstrated this time and again, were aligned about delivering the best possible outcome and not going to get down rabbit holes and say wouldn’t it be great if we could just do this, even if it wasn’t in the scope of the MVP.

Ben:  We ended up on a risk shared arrangement. It was effectively an hourly rate, but if things went pear shaped, there were some penalties and other bits and pieces.

We’ve gone through this development process. Tell us what does the new system look like? What have been the commercial results? Give us the end of the story.

Andy: We had the previous software still in market treading water which was frightening, until Christmas this year. To test the prototype we had a front end with no automation. It was smoke and mirrors there for a while. We called it a concierge service. We spent a lot of legal time on it and made no money. Then we went live.

I think what is interesting is to put it in the context of the legal industry. The legal industry has zero growth, it has about 2% a year. The Net Promoter Score, a customer satisfaction metric is about 12%.

Ben: That is bad, that’s really bad.

Andy: Since we’ve gone live I think we’ve added sixty new clients to the platform, so more than one a week. We’ve been growing our revenue about 10-15% month on month. If you think about it from a SaaS product, a good SaaS product probably adds $2000 of MRR a month. We’ve been doing four or five times that.

The most interesting metrics for me and when we think about the stage gates of the project was; will the concept work, will we get through the technology risk, will we be able to sell it? Will people stick?

What is really transformative for the legal industry is we have a 92% Net Promoter Score. That means on average almost everyone who uses the system says they will refer it to a friend or peer. We have 100% renewal rate and are still maintaining about 10-15% month on month. They are the top line metrics.

If you think about it from a business metrics, we now have one lawyer providing quality assurance on the output. She delivers $950,000 of revenue per annum because it is so technology enabled. To give you a benchmark, a good law firm, for the same level lawyer, is probably doing a rate of $180,000 – $200,000 of revenue.

If you look at all those metrics, I believe it is the best legal service (it’s very niche obviously) in Australia. Things that our clients are very excited about are what else can we do, as soon as they start using it. Not only what else can we do in terms of other products, but a lot of the international clients like L’Oreal, General Mills, PPG, the largest paint company in the world, SpecSavers; they’ve all been at their global conferences and said, you guys better get onto this. I’ve had emails from the GCs of Europe and North America saying can we now buy the service?

Ben: So we’re also excited about that. Because that conversation, about what other products can you do, can become a great conversation that we’d certainly enjoy having and we’ve got other bits and pieces underway.

We’ve had a really good experience with Andy. He is a shrewd business guy, but the process has gone very well both from a commercial output, but also in terms of that development output. Literally all the techniques we talked about, Kanban, close engagement, all of those things; this is a model project for us where each of those have come into play.

As you can imagine, a project that validates the purpose and useful nature of a legal platform driven by software means that everyone has to be on top of their game. Not only does the software design have to be elegant and make sense, it has to translate into processes that work on a legal level and on the user level. This cannot be coded with just any standard developer talent. It requires an understanding of tightly run systems, keeping the team close and engaged and testing the outcome for absolute certainty in the end result.

Are you working on a project that requires the most talented software team possible? Get in touch with us today.

Let’s talk about turning your idea or needs into a smart software solution. + Add to Shortlist