If you have ever managed or worked within a team that’s delivering a digital project then you’ve probably come across the frustration of meeting the deadline and controlling software development costs. We certainly have and there were many reasons why we encountered problems, but we learnt from our mistakes.

Why do teams struggle or fail?

There can be many reasons, such as bad communication practices within the team or an inappropriate project management methodology for the nature of that particular product or team. The possibilities are endless because every organization has different structures and processes, and each product has different requirements and levels of complexity.

So let’s leave the ambiguity aside and focus on a more concrete example.

Let’s say that you are part of a team that is developing a hospitality and network application. You have an idea of how it should look and work, and you know that to validate the concept of the app it needs to be released as soon as possible. So, what do you do?

Choose the right methodology to develop your digital product

Here at Setapp, we use Scrum. If you work in IT, you probably already know that many teams work with this framework when they want to develop sophisticated products. However, the Scrum Guide does not state the prerequisites for starting a new project or what things you need to have ready for the first iteration. The result?

Projects being kickstarted prematurely without all the necessary knowledge or resources in place. This can result in team members being overworked and demotivated, and stakeholders feeling disappointed.

Frequent mistakes in digital project development

Some mistakes are made time and again. It doesn’t matter whether you’re experienced in project management or a complete rookie. Here are six common mistakes we at Setapp have experienced that you should avoid when starting a new project:

1. Having no shared vision (or sense) of the project

Let’s say you understand your product entirely – you know the project’s goal, objectives, and functionalities. However, is everyone in your team aware of them? More often than not, teams know the list of requirements and functionalities they have to design or to code, but they don’t understand why.

“Why are we building this booking application? Who is going to use it and why would they need something like it?”

Everyone has to understand the purpose of the project. To be able to kickstart your project on the right foot, everyone should work towards the same goal and share the same vision of the product. A team will be much more motivated in what they are building if everyone is on the same page.

2. Not understanding the details of your product

“I want to create an app that will make traveling and booking hotels easier.”

Great! But that’s not enough for you to start creating a prototype, design it, or even code it. Having just a goal or an objective is not even enough for you to fully understand your business. Market and product research is crucial if you want other people to hop on your team. If you don’t know what to expect from the product, who will?

These questions can help you gain a better picture of your product.

3. Having no clear budget or time constraints

“We have to build this hospitality application, but I don’t know how much money/time we have. It doesn’t matter! Let’s start anyway!”

Diving into a project where there’s no clear budget or time constraints will at some point have a negative influence on many aspects of your project. Even if a clear scope and vision of the product is defined, many complications will arise. Why? Here are two examples:

• the project’s budget might burn down before you build something valuable for your target market,
• spending a great deal of time planning something that will never see the light of the day is a waste of everyone’s time and a huge demotivator.

Maybe, money isn’t a problem for you? But still, if you don’t have deadlines, for example, when the first MVP should be released, the chances are you’ll encounter the risk of your product not being valuable or relevant to your target market anymore.

It’s not strictly necessary to have a detailed budget and time deadline, but it would help to motivate team members and increase their productivity, but also to plan and allocate resources efficiently.

4. Having a poorly described requirement list

Another frequent mistake is not having a features/requirements list ready before the development iteration starts. By “ready” I mean that each requirement or item in the list provides the following information:

• A description or criteria of when it is “done”
• All relevant materials are attached to the list. Including content, graphics, designs, access to related accounts, and anything that is needed
• It specifies the what and why, rather than the how
• The effort to complete the feature is estimated by the team
• It focuses on the user’s problems, instead of the software implementation.

Having a detailed and ready Product backlog is not a prerequisite, especially if you are working with Scrum where the whole purpose is to always be flexible and be able to adapt to new requirements. However, having the first-iteration(sprint) backlog ready is fundamental to proceed with the development sprint and deliver the very first part of the product.

In “Fifty Quick Ideas To Improve Your User Stories” by Gojko Adzic and David Evans, you can find some handy tips on how to write user stories like a pro!

5. Not having prototypes tested with real users (or not having prototypes at all)

So often, teams kickstart a digital project that they don’t know for sure if it will work. Stakeholders are confident that their idea will be successful, and usually, they are successful at convincing other people through research and data. However, it’s important to not only have business data backing your product, but also qualitative data!

One approach is to use prototypes. If you have a budget for learning then you should use it to reduce uncertainty. For example, you can use that budget to have a dedicated mini-team to build a prototype of your app to test with real users. That is an excellent approach to gather first-hand feedback. You can discover if the features and functionalities focus on user’s needs and tackle the problems you want to solve.

6. Using unknown technologies

If you start a project where your development team did not choose the technology to develop the product, you can expect:

• a slower production pace,
• lack of motivation,
• a lot of uncertainty and frustration.

It’s like asking someone that is fluent in English to give a speech in Spanish. That person could learn Spanish while attempting to complete the task, but he will take longer to write it, and the quality will not be the same.

Keep in mind that before the team makes a final decision on the technology, they should undertake extensive and in-depth research based on the list of requirements and designs.

If you don’t; you might end up giving up on features and requirements that have value for you. For instance, imagine you have designs and specifications ready for a project.Then, in the middle of the iteration, your team discovers that they can’t deliver the project as agreed by everyone. Why so? Because of limitations in the technology.

Conclusion

There are more bad practices that could be added to the list, but we hope that these six common mistakes can give you an idea of the actions that you should avoid or activities that you should take a closer look at when you kick-off your next software project. Also, the purpose of this article was not to give you a checklist of steps to follow when you are about to start a project, but instead to give you an idea of the things to look out for when you are about to start a new project.

I hope this was helpful and if you have any comments or ideas about other common mistakes then please write them below in the comments section.