The pitfalls of custom software development: Scope

It’s not always easy to find the right software solution on the market for your company or business process. I’m not here to tell you how to choose between a purchase and custom development. Instead, I want to help you understand what’s at stake when you decide that developing custom software is the right solution for your particular issues.

Custom development involves designing software to meet a set of specific needs.

This article will focus on the project’s scope. We’ll have more articles shortly on estimates, the importance of a product owner, budget management and agility vs. project budget.

The scope of a custom software development project

The project’s scope sets its limits, e.g., it specifies what will be included and excluded at delivery. This may seem simple at first glance, but it’s one of the more complex parts of project management. It’s an inevitable step even though it’s a primary source of conflict and dissatisfaction.

“Scope is very difficult to define. This is why Agile projects use a set budget and variable scope, rather than a set scope. With this method, we can deliver one or more features to the client or user to confirm what they need and quickly readjust if necessary. This way, we can increase satisfaction.” – Maël Rieussec, Scrum Master at Askida

There was once a time when we spent days or even months describing the specifications and design of custom applications to be developed for clients in great detail. While there are benefits to this method, like a high degree of precision, in the end we found that the system we developed wasn’t in line with client needs. Because the tech and app market is rapidly changing, we need to be flexible so we can adjust during a project and avoid being inundated with a pile of change requests at the end.

 

Custom development – Don’t skip any steps 

“I know what I want” is by far the most frequently heard statement at the beginning of a project. People know what they want, but do they know exactly? If they don’t take the time to think it over first, the answer is a resounding no! I often use the following example to explain the level of precision needed to develop a custom application.

Client:

“I know what I need. I need a ‘login’ page.”

Supplier:

“OK, I understand. I have a few questions for you.

What will the user code be?

Will it be an email address? If yes, do you only accept business email addresses?

Will it be a word? Any word?

What will the password be?

The length?

Will you require a strength? What will it be?

How will the registration process look from the administrator’s point of view?

How should I communicate with the user?

Will the account be blocked after a certain number of failed attempts? How many?

If it gets blocked, how will the user unblock it?”

 

I’ll stop there, but you get the idea—there’s a set of parameters that need to be discussed to ensure a quality user experience and that the processes are in line with your management style. Even the simplest feature requires a ton of specifications and decisions. You can’t expect someone to know all the technical details that go into custom app development before any work has even been done on the design. As the project progresses, decisions will be made about the software’s different elements.

It’s important to have an idea of the scope ahead of time so that we can determine the technological feasibility, costs, deadlines, size, team, and more.

This is a step we all need to be aware of. We have the experience and expertise necessary to have a good idea of the deliverables the client wants. Before going ahead, we also have to know what needs to be invested in the project. This is a legitimate concern. But is it possible?

 

Estimation in Agile mode

Over the years, our estimation methods have improved and they continue to evolve. Approaches can be subjective, “scientific,” esoteric or realistic. Plus, many tools have streamlined the documentation creation process.

But there’s no methodology to figure out what the client doesn’t know. That’s the biggest issue. According to Rieussec: “That’s why the Agile approach recommends frequent deliveries. We can experiment and fail quicker, so we figure out what we don’t know faster.”

What happens if there are only a few details I don’t know, you ask?

That’s where the butterfly effect can undermine operational success.

Can one small decision, minuscule specification or microscopic change have such a major impact on my system?

Well… Yeah!

You can’t always assess the impact that an action will have on a complex system.

When it comes to service providers and clients, people are quick to look for who’s at fault. Is it a change request? Is it included? This uses up a lot of time and resources without creating any intrinsic value for the project.

This is why we need to be professional and rely on proven methods, up-to-date tools and both parties’ experience to ensure everyone is on the same page about the project.

What are the takeaways?

 

  1. 1. Now you know. It’s going to happen. Have a client-service provider discussion at the beginning of the project.
  2. 2. Don’t take anything that could affect the system lightly.
  3. 3. The product owner shouldn’t ask the developer for even minor requests directly.
  4. 4. Agile methods give you the chance to better manage these situations, which is yet another reason to actually use them!
  5. 5. Don’t point fingers, look for solutions.
  6. 6. Use the minimum viable product (MVP) strategy—the best way to reduce the risk of conflict—by working on the basic features and quickly getting the application to end users.
  7. 7. After delivering the MVP, short iterations should help you quickly identify any scope-related issues.
  8. 8. And please, have a budget. If you don’t have a good budget from the get-go, you’re sure to encounter conflict and dissatisfaction while going way over your spending target.
  9. 9. Build trust.
Image Steeve Duchesne

Steeve Duchesne

PDG à Askida / CEO at Askida