Menu Home

5 common mistakes done in a greenfield project and how to avoid them

Spread the love

In software development, a greenfield project could be one of developing a system for a totally new environment, without concern for integrating with other systems, especially not legacy systems. Such projects are deemed as higher risk, as they are often for new infrastructure, new customers, and even new owners. For this reason, agile software development is often deemed the best approach, as it proposes how to handle those risks by developing small slices of complete functionality and getting them in the hands of customers (internal or external) quickly for immediate feedback.

The start of a new project is always an exciting day. If it’s a greenfield project even more. The possibilities are never-ending and so is the imagination of everybody involved. Project Managers jubilate with the blank canvas, Product Owners start dreaming about their product and Engineers can’t wait to get their hands on that brand new tech that has just come out. However, things can easily go sideways and end up very wrong. These are 5 common mistakes when working on a greenfield project and how to overcome them.

1. Start a project that should never have started

More often than not, everybody involved in the project gets so excited about it that it’s not uncommon forgetting the reasons why the idea came out in the first place. A lot of times a project gets so hyped out at the idea stage that when it gets to execution the people involved don’t even think about how relevant the project is now. Before starting any new project, don’t forget to ask yourself if the project is still as relevant now as it was then. Double check your metrics, goals and objectives. Make sure that nobody else got there first, and that the potential is still as big as it was. Overall just make sure that it’s worth doing and make the decision based on today’s knowledge.

2. Underestimating the complexity of the project

Building something new is not to be taken lightly. There are a lot of things that can go wrong (a lot can go right to). Many unexpected obstacles will be placed in front of you, some can be overtaken easily others not so much. It’s always a good idea to split the project into several phases. The more you break it the easier it is to manage. Break it and break it again, and then, when you are done breaking it, break it again. Throughout this process don’t forget to keep asking yourself: Is this feature still relevant? Is this feature a first priority? In the end, you will end up with a minimum viable product. Doing this will allow you to:

  1. Build and release more often
  2. Validate the premises on wich the project was initiated
  3. Learn the value of the built features and features yet to build

3. Bad task estimation

Product development is done in tasks. It doesn’t matter if it’s software development, car manufacturing, construction work or making yourself a Nespresso. In order to get it done, you will need to tick tasks from your todo list. Some tasks are easy to estimate and you can easily assess how long it will take to get it done. Others are more complex and need deeper thinking. Bad estimations can make a task drag or even worst not get finished and therefore not delivered.

When taking estimations from the executor make sure they are reasonable. If it’s not sit down with the person doing it and ask them to walk you through their thinking. In most situations, especially in software development, if something will take a week to get done it’s either poorly estimated or it should be broke down into smaller tasks.

4. Build everything from ground up

So, the tricky one, as an executor myself this is a very sensitive one to me. Here it goes. Don’t build it if you don’t have to. Simple right? No!

When it comes to delivering a project, this is particularly common in software development, we tend to want to do everything ourselves. It can be because we are not aware if there is something out there that can suit your needs, or simply because you want to go through the learning process involved in the building. Don’t fall into the trap of building everything from scratch, trust me I’ve been there, instead use whatever is available to you. Builders don’t make their own tiles, car manufacturers don’t make all the parts, and software developers shouldn’t build their own frameworks unless you’re in the framework business of course. Focus on your business needs and use whatever is out there to be used. There’s no shame in it.

5. Not killing it before it kills the company

A product is only as good as the value it brings. If you didn’t do n.1 and n.2 then please don’t do n.5. By now you should have all the tools and metrics to understand the progress and value of the project. If it’s getting too expensive or no longer fits the business needs kill it. Don’t throw more resources at it, 9 pregnant women still take 9 months to deliver a baby. Have no doubts about it. Just press delete. It’s not uncommon to projects to drag on false premises. Avoid this at all cost it’s extremely expensive, not only in money but also in manpower and willpower. It can crush a business or a team quicker than you think.

Wrapping up. A greenfield project is an unexplored ground, and as easy as it is to make all these mistakes in a brownfield or refactor project, it’s more likely to make then in a brand new project. Be realistic, honest and don’t forget to keep open communication at all time. And more important than anything learn quickly from your mistakes.

Categories: Opinion

Tagged as:

Claudio Pinto

Leave a Reply

Your email address will not be published. Required fields are marked *