4 Common Challenges Businesses Have When Developing Software

Developing software is hard. 

After all, research shows that anywhere from 15%- 65% of IT projects fail.

So while there are many issues and challenges involved in software development, in this article, I will focus on some common issues that may not be obvious at first but cause big hiccups down the road. And specifically the issues I encounter in my role as a Product Manager.

The issues are;

1. The requirement gathering stage is rushed.
2. Business requirements are defined improperly
3. Prioritization is not done, continuously
4. The language barrier between technology and business personnel

With that being said, let’s get right to it.

Issue #1

The requirement gathering stage is rushed.

This is a really simple issue that has a very simple fix. But I see it happen all the time so I want to start off mentioning this.

Because gathering the requirements for a project are the foundation of any project. Yet, all too often I find that people are antsy to move onto development. Meetings are rushed and the monetary investment into the requirements gathering is pennied and dimed. 

If one was building a house, they would never hire a bad architect and the meetings with him would most definitely not be rushed. After all, how is the building going to look like what one has envisioned if the architect doesn’t understand what is wanted?

But unfortunately for software projects, this is not the attitude.

I had a client once that at the end of our first meeting asked us if we are ready to move on to development?

No. we were not.

We did not start developing after that initial meeting because we did not have the right information to move forward. Many questions needed to be answered and decided upon before starting to develop. And this was for a relatively simple project.

Of course, I’m not saying that an endless amount of time needs to be spent on defining requirements. On the contrary, Agile values working software above all else so we obviously would like to get to development as soon as possible.

But “as soon as possible” does not mean “right this second”. Because without giving enough time and patience to requirements gathering, the results are that the product isn’t developed right

So, lesson #1 is to give the requirements gathering stage its due time and energy. Don’t rush it.

Issue #2

Business requirements are defined improperly

When going through the first step for a software project of defining the business’s requirements, all too often the requirements are gathered as a specific solution versus as a problem/goal.

I’ll demonstrate with an example.

Let’s say there’s a business that provides on-call handyman services to members and they are looking to develop software to optimize their business. One of the problems they are looking to tackle is how to best locate their current handyman and where are the ideal areas to hire additional handymen.

Requirement:

I want to be able to make decisions for how to locate my handyman trucks based on the location of my members

NOT a requirement:

I want a software that will show me all my members on a map as pins, allow me to drag a handyman icon to a location, and then tell me information regarding the distance and driving time from where the handyman is, and therefore allow me to decide where to place my trucks.

At this point, I usually get asked “But why write it the former way? Seemingly the latter description is a more defined explanation of what is looking to be done?”

There are two main reasons why to do it as such.

A) When we have the problem or opportunity properly defined before discussing the solution, that allows us to both validate whether this is a real challenge or opportunity that is worth trying to fix, and when we do ultimately work on the solution it enables us to align that solution with the problem/opportunity instead of creating a “Frankenstein” offshoot of a solution.

In the example mentioned above, by writing the requirement as “I want to be able to make decisions for how to locate my handyman trucks based on the location of my members” it allows us to ask “Do we really need this? Is the way we currently work not good enough? Is the issue/opportunity large enough to invest in solving it?” 

And when we work on the solution, it ensures we do not get stuck on the idea of developing a handyman that can be dragged onto the screen but rather that the focus is on developing the best solution for our handyman location challenge.

B) By defining the goal you are looking to accomplish instead of defining the specific solution, that allows you to use all your resources to define the BEST way to accomplish the goal. 

That means that the developers you are working with can help come up with a solution, and being that they have a better understanding of technology, they may be able to come up with a better or more cost-effective solution.

And the other employees that may be involved in a more hands-on manner can give their insight and perspective, again allowing for an overall better solution.

So, lesson number 2 is to define the business requirements as a problem and goal, not as a solution

Issue #3

Prioritization is not done, continuously

My initial thought was that to bring out this issue of prioritization I should continue the aforementioned example of the on-call handyman service and start talking about the solution.

But as I started writing I realized that this was getting very detailed and therefore a bit of an unenjoyable read.

So let’s move on to another example and talk about things from a higher level!

Imagine there was a business looking to develop a CRM because currently, they don’t have their customer's information organized and are therefore having trouble dealing with client's complaints.

The long term vision is that once the customer’s information is organized, they can then start to leverage that information to access some other possible opportunities or optimizations. 

Potential examples include automatic upsells of products related to the customer’s specific purchase (if they bought an iPhone, offering an iPhone case), automatically following up for reviews or complaints before they turn into negative reviews, etc.

In this scenario, prioritization would mean separating between the business’s immediate goal and long term vision to ensure that the only features that will be worked on initially will be the ones that deal with organizing the client's information so that complaints can be dealt with more effectively. 

But any features that have to do with the optimizations and opportunities down the line, like automated upsells or automated requests for reviews, will NOT be dealt with now. They will be put into the “future features” section and ignored in the meantime.

Prioritization is important because without it the project can become a mess of half baked ideas. From the get-go, the product roadmap can be too full and overwhelming. Trying to build every slightly beneficial feature also means that the most important features that the business needs “yesterday” will be delayed due to other features being worked on.

I find that this example demonstrates prioritization very clearly because the business’s priorities are very clear, they are an immediate need versus down the line opportunities. 

But in many cases, the priorities are not clear at all, with businesses asking for every possible idea under the sun from the get-go. 

Prioritization is therefore about classifying and prioritizing the business’s needs to ensure the focus stays on what is most important.

And while I spoke about this on a high level, a product level the truth is this happens on a detailed level or a task level. But we won’t get into that.

One last thing I will say on the subject of prioritization is that this is not a one time step. Prioritization happens iteratively, as do most steps in agile development. And therefore it is important to put the infrastructure in place to deal with this.

When ideas do come up mid-sprint, what happens? Who decides upon prioritization? When do we reconsider prioritization based on new features? How do we ensure that good ideas don’t get forgotten about? 

All these questions need to have the proper process in place to be dealt with. So setting up that process at the beginning of a project to be able to deal with the constant ideas and issues that come up is crucial.

Lesson number 3, prioritize requirements iteratively ensures the goal is focused on.

Issue #4

The language barrier between technology and business personnel

Something I’ve come to realize from being a product manager and therefore being involved from both a business and technology standpoint is that the business world and the development world speak different languages.

What I mean by that generally speaking is that business owners and other business personnel may not understand how technology works and definitely not how software is built. And on the flip side, developers may not understand how a business “works” i.e. what is important to a business.

Let me expound:

(WARNING: I am generalizing, not all business owners and developers are like this. I am talking about the “stereotypical” business owner and developer)

I often get requests from business personnel to “just develop this feature” and then when they hear the timeline for that feature, they are shocked that it is not going to take 1 second to build.

(My favorite is when I hear things like “Do it the way Google does it” or Facebook, Uber etc. expecting that it will be a simple thing to do because these tech behemoths do it too :)

Point is, business people often don’t understand technology and view the whole thing like waving a wand while shouting abracadabra.

A business executive may request a feature and then get upset when it wasn’t built in a way that fits the business needs perfectly, complaining “But isn’t this obvious? Why wouldn’t they build it this way?” But no, it’s not obvious or simple.

On the flip side, developers often do not think in terms of “how will what I am doing help the business?” 

A common example of that is a developer or development team is asked to build an unimportant specific feature and they then spend days and weeks on this unimportant feature because they were asked to build it without ever considering is there investment worth the return. 

Another common example is spending time creating a “perfect” feature when all the business needs is a basic version. But because they were asked to build this feature so they built it as powerful as possible.

So due to this difference in “language”, there can be many misunderstandings that cause failure, or things to not get done right the first time.

And therefore, lesson #4 is to make sure there is someone with the expertise and experience to act as the “translator” to ensure things do not get “lost in translation”

That's all for now, would love to hear your thoughts on these challenges. 

And as always, if your company needs help with their software project feel free to reach out at [email protected]

(This article was originally published on my website at https://www.meticulousgrowth.com/4-common-challenges-businesses-have-when-developing-software/ )