Software development is no easy process. It involves a lot of planning, decision making and interpreting of a set of rules and functions that will have to be organised and written into code. It is easy to forget some of the elements that must be involved in the earlier stages. It is even harder to gauge the actual cost and development time at the start of a project.
So, how is a person supposed to get a grasp of the actual development process and timeline? Watch this video to gain a deeper insight into the software development process.
Video Transcript:
Should I use existing technology?
The answer is yes, if you can. It’s going to be faster, it’s going to be cheaper, it’s going to be easier. Building custom software is an effort, you have to have a good reason to do it. I like to do it where there is only a limited amount of tailoring to the product. I don’t do any tailoring to Microsoft Word.
You need to realise that you’ll never be unique when you start on that basis. Unless you do an awful lot of work, you won’t be unique. You’re stuck inside their world view. Their way of doing things becomes your way of doing things and sometimes that’s fine. Sometimes for your business you’re actually really happy to adapt. You might think, I’m a bit uncertain about this, I’ll try something out and I’m happy to adapt to their world view.
Existing software recommendations
You want to have a good reason to write any of these packages. You want to have a very good reason to write a CRM. There are lots of good CRMs. I would argue heavily with you why you’d want to write your own CRM. Planning management tools, accounting, you can read the list. Booking management, content management, data analysis, all these things have been done well by a number of players; writing them yourself would seem a little bit like madness.
Having said that, there are people in the room who’ve written CRMs that have one particular quirk that nobody else has, and they have done really well out of doing it. So it doesn’t mean you shouldn’t write a CRM. Just don’t write a CRM for the masses, you could but you’d need deep pockets.
I’ll give you an example. Linda wrote a CRM for the aged care industry that particularly dealt very well with the fact that the person receiving the care is not the person buying the product. It managed that relationship really well. These players wanted a pretty basic CRM but they wanted to manage that relationship really well. We built her, in CRM terms, what is quite straightforward and it sold very well.
Where custom software wins
Where custom software wins, is where the software is a part of a unique offering, and that is for most of the people in the room. Or it is for important and unique internal requirements, where you’re doing something that is very specific to your business process. Generally if it’s inside your business, I ask myself some pretty hard questions about why I’d be custom developing something. Custom developing is expensive. It’s typically where your offering comes into its own.
Pricing software development
Big and small companies struggle with software pricing, no question about it. This is the hardest thing we do. If you look at the move to lean and agile projects, it’s not true that pricing has been thrown out the window, but effectively they want to deliver early and regularly and there is not the same focus on estimation as there previously was.
Let’s just go through some of the psychology.
This is what a customer thinks. I feel uncertain, really out of control, I hope you’re not going to rip me off and I really don’t want to explain it to someone else because it was a pain explaining it to the first person.
This is what an engineer thinks. We ask engineers to estimate things line by line. Please don’t ask me to quote. I have to. Ok then. If I actually understand what you mean by this line in the quote, then I’d guess three to five hours. But if I’ve misunderstood it, it could take a week. That is the thought process so we’re really trying to make sure they haven’t misunderstood what that line means.
The development company is thinking how many people am I quoting against? Just being selfish here for a moment, it’s a big factor in our world. Quoting takes a lot of time and a lot of energy. You don’t want to quote against ten other firms. You’re not going to invest yourself in the same way as if it was against two or three. Do I want to work with this company? Do I go pessimistic so I’ve got a good buffer or do I go optimistic so I win the job?
A salesperson is thinking (to the salesperson everything is easy). We can do this and we can do this. Just because it is easy doesn’t mean it doesn’t take a bit of time to do.
The project manager is thinking I really wish I didn’t have the confrontation of telling you that thing was out of scope. Project managers hate that.
The CFO just doesn’t want you to do big fixed priced things that turn ugly and they lose lots of money.
Internal estimation process
We take a detailed series of educated guesses with a risk buffer. They’re educated guesses, we talk it through. We are concerned when we don’t have shared and clear requirements. If we’re estimating something and we feel in our heart of hearts that we haven’t got a marriage of understanding between us and the client about what is being estimated; even if we know what we’re estimating on, but we think they’re vague; we’re worried about their vagueness. Then they could come back to us and say, well, you didn’t understand us.
Identified risks. I’m going to give you some big risk software projects, part of the pros and cons of software, the things that typically blow things out. There are some surprises in there.
What our current work volumes are. Services and businesses face the problem that when they’re quiet they’ll quote more aggressively than when they’ve got a lot of work.
The long term prospects. For me, this is the biggest factor. I very much take an approach that Bruce in the room here introduced me to. That is, it’s not the first job that matters. It’s actually what the long term relationship with the client going to be like. We are called Alliance Software for a reason, because we want long term alliances. We’ve had opportunities to quote on jobs where it was a very big job but they were clear, the day you finish it, you hand it over to an internal team. They are far less attractive than something where we can have an ongoing relationship.
Frankly, are they nice people? I know it sounds funny but you’ve got to work with people all day long and you want to work with people you really like.
Known risks
I think you might be surprised about what are some of the risks we look at when we quote on a project.
API integration. Anything that involves taking or pushing data to a third party platform is a risk in our world. I can tell you stories of integrating with some of Australia’s best branded systems, names that everyone in this room would know. Their APIs do not function the way their documentation says. It’s really hard to quote in that environment. In fact, we just won’t do it. You typically want to get in there and do a bit of a test and feel.
PDF printing. This is a funny one. Multi page PDFs take surprisingly long to produce. The reason is when we produce something for a web page, we can just make it scroll down, down, down. When you produce it for a fixed set of dimensions, if the data coming into that is variable, it’s going to blow it out. Trust me, people are surprised. They say, I’ve got one page, “no problems, eight hours”. Two pages? “No problems, two weeks”. How did that happen?
Print based designers. When people come to the design space without an appreciation of the way the web moves, often there can be an expectation that can be challenging, particularly across different browsers. Different browsers will present the same information differently and people from a purely print perspective don’t understand that.
Unseen third party designs. “We’ve got a design company. Build me a website”. “What is the design?” “I can’t give it to you yet, give me a quote”. If I haven’t seen the design, it’s hard to quote.
Data migration. Moving data between systems even if it’s not an ongoing connection, just a one time thing is where it can be a challenge.
Poor client engagement. Just clients aren’t represented well, clients that can’t give you the time you need to actually engage in their world.
Industry pricing models
Let’s have a look at some of the ways the industry prices software.
Time and materials basis
Time and materials basis is really common and in the agile space it is very common. If you’re doing that, you still want to manage towards an estimate.
Risk share (hourly rate with price tiers)
You can risk share. We’ve certainly done that. You say, we estimate it’s going to be $100,000 and the fixed price model we might put a buffer on it and say its $120,000 or $130,000. Or we might say we’re going to do an hourly rate engagement. We might get a slightly higher rate but if it goes bad we’re going to drop back off. So both parties are sharing the risk. What that does is give both parties the incentive to be pragmatic and work towards an effective end.
Fixed price
Certainly you can do fixed price where you’ve got fixed features and agreed price.
A couple of thoughts on fixed price:
- Issue #1 Butt covering – I see a lot of butt covering on fixed price. We butt cover on our end, where we’re trying to protect scope. On the fixed price model you see clients butt covering from the perspective of making sure they’ve got everything that was in their system. Often where that can be challenging is that what you thought you needed upfront, when you’re three or four or five months into a project, things do move. How do you handle the move, how do you handle that change?
- Issue #2 Variation request price gouging – This is not us and I’ll tell you a solution to this problem, but this is endemic. There are lots of people in the software industry who go in cheap and win your job and promise to produce everything your spec requires and they know you cannot fully specify your system. They know you will change your mind and they know you can’t change your mind once you’re six months in. So they can take your one hour request and they can charge you $10,000 for it. People price gouge on variation requests and software development all the time.
The simple solution to this is if you’ve got a fixed price project and you’re working that way:
- Solution #1 Treat it like a bucket – I put something in, I take something out. Have some things that you are prepared to put in and take out.
- Solution #2 Establish an hourly rate – and actually get your variations done at an hourly rate. Under an hourly rate you actually pay a fair price. You pay for the time that was required and if you can negotiate variations at an hourly rate you’re doing all right.
Ongoing engagement models
This is something we’re moving towards. At the moment most people engage with us on an ad hoc by the hour scenario.
Fixed days per month. We’re looking to move to fixed days per month. There are people say, I want the certainty of knowing that I’ve got certain people on certain days of the month. We’re looking to deliver that. Obviously if you have booked people in you have to use them because we’ve booked them in.
Sprint weeks. This is the notion where you say we might have a couple of little pieces around the edges where we need an emergency fix here and there. But what we want to do is build up to a week. We’re going to run that week hard, we’re going to have our developers without any distraction. We’re going to prepare for it and run that week out hard. We’ll essentially have some generally agreed set of outcomes and we roll it through a week at a time. It’s a great way to do it if you’ve got a project you want to put an extended amount of time into for a week and then come back. This is becoming increasingly popular.
Platform updates and maintenance. One thing to be aware of, every platform requires updates. There is no platform out there that doesn’t. The other thing you can have is you can engage on monitoring and patching and bits and pieces to keep your system up to date. There are agreements that can be put in place around that.
It doesn’t take long to realise that most projects are going to involve unknown changes, fixes and updates. The question is whether it benefits you, the developer, or both you and the client to try to agree on a ballpark process and project cost at the start of a task, or stick to an hourly rate to cover each detail in real, tangible figures. Whether software is being created for internal use or for the mass public can have a huge influence on what extra coding and costs are actually involved. This video should help you think through your project and plan towards greater success in the actual development.
Do you have a software project that needs a dedicated team for creation and support? Get in touch with us today.