I’ve seen some posts lately that lead off with tales of how difficult software development is. Fair enough — it’s already a tedious and difficult process. But 99% of the time, we needlessly make software development more difficult.
Sure, some may disagree. Maybe they work in a great place that has this all figured out. But for the others, I want to tell you how I’ve seen company after company, client after client, make software development harder than it needs to be.
In this post, I discuss common missteps that cause rework, missed deadlines, and disappointment. I also point out what to do to avoid those missteps.
1. Are you modeling a broken or inefficient process in software?
This can happen whether an application exists already or not. Many leaders mistakenly assume that the process being modeled is efficient enough or can be changed later. Many assume the only thing wrong is inadequate application of technology. Leadership should review and business process way before development begins. Neglecting this step could mean problems down the road.
Here’s an example: BigCo has a procurement process that requires each person in the procurement chain to email the proper documents to the next person in the chain, depending on procurement status. As BigCo grew, this process became fraught with errors. Participants in the chain weren’t sure if they should take action or not. Emails were being overlooked, and the time from request to completed procurement increased by a factor of 3x — and that was for purchases everyone favored. In designing the system, the requirement put in place by the procurement team was for new online forms to be completed and each participant emailed the data on the form, with a link to the online document.
That’s nothing more than an electronic version of the free-for-all that currently exists. The only thing that became more efficient is the time to user frustration.
Always review business processes
In this case, BigCo should take time to talk with people involved in the procurement process, how they’d like to optimize it, and challenge them. Business analysts should also scrutinize and provide suggestions to alter the process. Providing clickable prototypes so that users can experience changes is always helpful. And for those that are wondering, yes, this is important for internal and external users and applications.
Why? Because your internal user experience will affect your external user experience.
Doubt that? In the scenario described above, imagine a need for updated reporting software. Management needed new reports to help make timely decisions and requested a new reporting platform. The technology team already had a development copy and was building out reports in anticipation of the purchase.
Then the procurement process bogged down. Days turned into weeks, into months, and management didn’t have the data they needed to make timely decisions that would affect their customers. But hey, at least the internal process was followed…
I can’t stress this strongly enough: Your internal process will always influence the way your customers experience your company, its service, and its brand.
I know that process is a painful thing to change. But doing something poorly more quickly is never the right answer.
2. Is everyone talking about the same things?
Mis-communication is another area that makes software development more difficult than it needs to be. Technology teams must dig to make sure they understand exactly what the business wants. And business leaders must be explicit when it comes to describing functionality. If there’s anything vague on either side, you’re not going to get what you’re expecting.
Making communication more effective and accurate
Read anything you write from the perspective of who is going to receive it, then from the perspective of anyone to whom they may send it. I started using this rule for sending email about 25 years ago and have found it to work well in most situations. Looking at communication from different perspectives improves clarity and completeness.
The single biggest problem in communication is the illusion that it has taken place. — George Bernard Shaw
Make sure to ask questions when communicating a concept or request. For example, if you’re a compliance lead and drop by the tech lead’s office to mention that a certain encryption standard is going to be required, make sure it registered. Ask about the current standard and if it will take a lot of time to change. Also, find out what projects may be delayed, and what resources impact will be.
Asking questions is engaging. If you’re not getting a response, no one is hearing you.
3. Did You Skip User Research?
Did you undertake enough user research to know if you’re building what your market (internal or external) wants?
Do you really know what your users want or are you assuming you know? Many software development projects take longer than they should because project owners are too anxious to have the team start coding. I’ve seen this improve greatly in the last 10 years, I’m glad to say.
If you don’t conduct enough research to know what your users want (internal or external), you may not know where you’re going.
This is a double whammy combined with an already poor process that isn’t reviewed. Many times, users will say they’re OK with the current process because they’re familiar with it. Question that (see above on communication).
If you’re in this situation, be the challenger. If possible, get an external perspective into the process, how it could be improved. Also, have discussions with your tech team early about how new technology may have changed possibilities.
Software Development Doesn’t Have to be so Difficult
Yes, technology projects are inherently challenging. There’s no need to make it worse by implementing poor processes, failing to communicate clearly, and neglecting user research.
Know other things that teams do to complicate software development? Comment below or let me know on LinkedIn!
Leave a Reply