Greenfield vs Brownfield Projects in IT

Differences, Pros & Cons, and How to Lead

Starting a project from scratch or taking an already started one – this is what the greenfield vs brownfield question is mainly about. Easy? Easy. It brings, however, a few important issues. How to run such projects? Which approach is better for your needs? What does the development process look like? Check the answers below!

Today we come to you with the mysterious, yet appealing subject of greenfield and brownfield IT projects. You might have never heard of them, so let us first explain where this has all come from.

Both terms originally referred to direct investment. A company that decides to invest and chooses to build everything from the ground up, on a “green”, implicitly uncultivated field, can call this investment a “greenfield” one.

The “brownfield” investment, on the other hand, refers to a situation when a company builds upon already existing facilities or other resources, or even leases them, which means it operates on a field that’s been previously used and cultivated.

The same goes for IT projects – a greenfield project is a brand new one, developed from scratch, and not based on any existing systems, code or infrastructure, unlike a brownfield one, which is built upon already existing projects, code or other resources.

From this article, you will learn about:

• The differences between greenfield vs brownfield projects
• Their pros and cons
• The project management process for both types
• When to choose greenfield or brownfield projects

Curious to find out more? Read on!

Greenfield vs brownfield in the IT world

Both approaches can concern many types of IT projects, such as a software tool, an app, a website, a network, or an IT facility.

In the brownfield option, the task may be adding a new management module to the current CMS, integrating new features to an e-store or boosting the performance of an existing app.

Greenfield projects usually allow for more flexibility and innovation, which, on the other hand, means that you must thoroughly understand your business goals and set a clear path of development in order not to lose the scope.

To handle this risk, it’s best to use the agile methodology, because it allows for constant communication and the ability to catch small mistakes before they turn into big ones.

Brownfield projects usually come with some constraints and limitations, but in this case, much of the work is already done.

These differences have their implications, which you should consider while choosing how to launch your software – and we will talk about the use cases in detail later in the article.

Having said that, let’s look at the pros and cons of both approaches.

What’s good about greenfield projects?

The advantages of greenfield projects stem directly from their nature.

First one is flexibility. They can fit the business needs like a glove, because they are built exactly to cater those needs and provide all the custom solutions one can imagine.

For the same reasons, the software solutions built in a greenfield manner can be highly scalable.

The enhanced flexibility also means lower maintenance costs, for there are no unused or duplicate functions inherited from the old software.

Greenfield IT projects can be more future-proof, because they are not limited by the constraints of outdated technologies and are free of redundant dependencies of old systems.

Everything is state-of-the-art and freshly built, so no old story is involved.

What are the risks in greenfield development?

Building everything from scratch means that the time-to-market is longer, and the business risk is higher because there is no well-trodden path to follow.

You have to plan everything starting from business needs to the choice of technology, the architecture of the system, the user interface and so on. There are many decisions to be made along the way, which can slow down or even stop the development process.

No wonder, then, that the cost is usually also higher. Greenfield projects require new tech skills that may be scarce in the market, and the end users will have their fair share of learning too, often with the help of external consultants.

What are the advantages of brownfield projects?

Unlike greenfield projects, brownfield ones have an already predetermined direction of development, and old code can be reused to answer new needs.

It also involves a shorter time to market and, in some cases, lower costs (these are not always true, which we will explain in a moment).

The business risk is mitigated because the initial project has usually already been proven in the market and utilized by its users in many different ways, so all the potential pitfalls are already known.

What are the challenges of brownfield development?

On the other hand, the brownfield approach may be very limiting. Developers have to deal with old code, and the functionality is not always tailor-made to the users’ needs.

What’s also important is the fact that developers must know the current system in every detail. If they in fact weren’t involved in building it, it might be very difficult to figure out the old code, especially if its quality is poor and there is (almost) no documentation.

And, sometimes, the end result isn’t really worth the effort of trying to patch the old software with new features, and the project may eventually be very time and resource-consuming.

How to run greenfield software development

A greenfield project gives you the benefit of a fresh start and unlimited creativity, which is a chance but also an equally big challenge – with great power comes great responsibility.

Agency may be your partner in this development. Let’s say you have got just the idea for an app to handle a battery storing solar power, and a certain budget, but no developers or technology on board.

How should you start? You should pass the idea to the agency that has experience in executing such projects because their assets are not only experienced developers, but also the knowledge about each step of the process that will eventually take you to a business success.

Because we are undertaking a greenfield project that has many unknown areas, all the preparatory stages that precede the coding phase are crucial. What does this process look like? Let us break it down into several steps.

Business analysis

In this stage, which can also be called a product design phase, we have to answer some important questions concerning the planned piece of software.

These concern a problem that the product will solve, the user personas, the goals, and the software’s reasons of existence in the first place. Why is it important? According to CB insights, a lack of market for the product is the second most important reason for startup failure (35%).

This is more of a business and marketing analysis, so this stage has to involve specialists from these areas – workshops with brainstorming sessions featuring both the agency’s and client’s employees are very useful in this phase.

You can also do some market and competition research if the answers to the above questions don’t seem easy.

Strategy

Once we’ve analysed everything, we should decide about the exact business model (including methods of monetization and pricing) and a development model for the software (including choosing the right approach, such as Jamstack, and the specific tech stack).

The strategy smoothly connects business-oriented and development-oriented issues, creating a rational idea for every aspect of the product, alongside ways for implementing them.

Design

Once we have a strategy in place, we have to design the product. Also, during this stage, the cooperation between the client and the agency should be very tight.

Design connects the logical, UX, and graphic issues and all these areas are interconnected, so working on them can be simultaneous.

We should think of user journeys and translate them into subsequent steps reflected in the final design.

Another vital part of the design process is prototyping, which may help to determine the optimal user experience and test all ideas. The created prototype should be reviewed, refined, and iterated according to the needs.

Development process

The final phase is development. The agency prepares a workflow, constructs a team of developers, and sets an agenda.

The product is usually created in sprints, which creates room for iterations and refining within this stage.

A good practice here is to create an MVP (a minimum viable product), which is namely a simplified version of the final software featuring only the most basic functions necessary to put it into the market.

That’s how the process roughly looks in the case of a greenfield project.

How to run brownfield software development

In the case of brownfield projects, the path is slightly different.

The software we have to build upon may be abandoned (created some time ago and not currently used) or incomplete (developed only partially and containing unfinished software).

The first important thing is to ask why the client wants to pursue a brownfield project in the first place. Usually, they think the cost will be lower and the time shorter, but as we have said before, that’s not always the case.

After an initial analysis of the existing code and new product requirements, it may turn out that the product will be less time-consuming and just cheaper in the greenfield approach.

But let’s assume we analysed all the pros and cons and decided that a brownfield project will be the most reasonable way to reach our goal.

Analysis of the existing project

The existing code may hold many surprises, so it has to be thoroughly analysed, with all the weak points and outdated elements identified. It may be reasonable to reuse just a part of the existing solution and throw away the rest.

We should also analyse the history of the product based on the original developers’ testimonies and documentation, its past failures, and its initial goals, comparing them with the new ones.

This phase takes a long time and is quite tedious. Sometimes, it may even feel like detective work, but if done well, it makes the other phases shorter and easier.

The result should be a comprehensive picture of all the technical, human, and organizational constraints of the system you will build upon.

Gap analysis

At this stage, we define what to do to bridge the gap between the initial and final, desired software. The questions we should ask in this phase allow us to specify the problem. Is it an issue with the usability, the performance, the compliance, the security or the looks?

We should also compare the new and original requirements, and check what we have already solved.

Building a plan

Having updated the requirements, we can prepare a roadmap of the project, which tells us which features are the most important and should be implemented first, and which can wait to be addressed later. Then, we should break the agenda into specific tasks.

Don’t fall into the trap of rewriting everything to work better – remember that you chose a brownfield project for a reason in the first place.

Also, rewriting code may lead to technical problems, because it might not be compliant with the old parts.

Some tasks may appear to be more difficult than they initially seemed, so you should consider a time and budget margin in your plan.

Brownfield implementation

The final phase, as in the case of a greenfield project, is development according to the pre-specified agenda.

Remember to involve all the stakeholders in your project, because without them, the plan may just rip at the seams. They should take part in requirements gathering, prototyping, or end-of sprint demos.

Should I choose a greenfield or brownfield?

Knowing all of the above, you probably want to know when you should choose a greenfield approach, and when a brownfield will be the best option.

The answer is not so obvious, because it all depends on the specific situation, and this should be analysed between all the stakeholders at the very beginning – involving the client and the software house.

If you just want to update your software with new functions, and the old system is generally working well, has clean code and is equipped with futureproof solutions, opt for brownfield.

If you want custom-made software that answers the specific business and users’ needs, or your existing solution is outdated and messy, you should definitely go for the greenfield approach.