Guide to Creating a Successful Brownfield Software Project

Software development projects are often divided into two categories — creating new software from “scratch” and working on software that was already developed or was partially completed. The common term in software development for this type of project is “brownfield project”, as opposed to “greenfield projects”, which are those that are started with no prior code base.

 

As one might expect, there are significant differences between brownfield and greenfield development projects and this document will address important development considerations specific to brownfield projects.

There are two main types of brownfield software development projects:

• Abandoned - Legacy software that was completed by a development team that is no longer available to maintain it
• Incomplete - Software whose original developers did not finish the development effort and simply stopped working on

In the abandoned type, the software may have been created in-house, but its developers have since been dispersed to other projects, were laid off, moved on to other jobs, or retired. In the incomplete type, the project may have stopped because of budget limitations, dissatisfaction with the original development team, poor project management, a change in business priorities, or any number of other reasons.

 

In both cases, it’s logical to ask why many companies choose to pursue a brownfield project. The answer for a brownfield decision is usually involves cost, but other considerations also exist. For example, in the case of legacy software, the client may be in the process of replacing the legacy product, but they need code maintenance or editing to keep the legacy product going until new software can be deployed.

Sometimes organizations find that it’s just more cost effective to keep a legacy system going rather than embark on a new project. For incomplete projects, clients choose to leverage their investment in the code base rather than write off the incomplete software as a total loss.

 

Whatever the case, brownfield software development projects have challenges and risks that are not applicable to greenfield projects. For example:

• The quality of the existing code may be poor
• Product requirements may have expanded or changed
• Documentation for the product may be improper or nonexistent
• Institutional knowledge about the product may be non-existent or incomplete. That is, no experts are available to provide guidance or explain the design decisions

Despite the risks and challenges, brownfield projects can be successful if they are managed properly. The purpose of this article is to describe some of the things that can be done to manage a brownfield project to successful outcome.

 

One of the world's pre-eminent novelists, Miguel de Cervantes, wrote, “To be prepared is half the victory.” As Cervantes words are true for most things in life, they are also true in software development.

 

In a brownfield development project, there’s almost nothing worse than finding your estimate was way off because of something you should have known - but didn’t know. For example, discovering:

• The previous developer’s uncommented spaghetti code does nothing, and it even does that badly
• The reliance on an obscure, outdated component or framework that is no longer supported
• The head-scratching database design that will have to be thrown out and started anew
• The office politics that sabotaged the previous project are alive and well in the current project

 

While these are just a few of the many potential “should have known” issues, a successful brownfield project requires all stakeholders to go in with eyes open and every effort needs to be made to discover all there is to know about the existing code. This is an extra step that doesn’t encumber greenfield projects. Brownfield preparation can take a long time, but it must be done to avoid being blindsided in mid-project.

To complete the discovery process properly, think of it as a history lesson. The first step is to gain context around the previous work on the project. Important questions to ask include:

 

• What was the history of the previous effort?
• When did the previous project start, what was the motivation for the project, and who worked on it?
• What development staff, documentation, or records remain from the project?
• If the previous effort was considered a failure, what criteria were used to make that determination and what were the likely causes of failure?
• How was the decision made to continue the effort as a brownfield project, rather than starting over or replacing the existing system?

 

For best results, don’t rely on only one person’s perspective; that person may have biases, hidden agendas, or emotional attachments that can provide useless information at best or lead you into a minefield at worst. Instead, talk to end users, leadership, the previous developers (if available), or other participants. With diverse perspectives a comprehensive, well-rounded history of the previous project can be assembled.

 

If possible, you should review all documentation related to the previous project, including the project charter, requirements, design documents, test cases...anything you can get.

 

Sometimes, some or all of the original documents or participants are not available. In this case, much of this discovery effort requires some detective work to piece together the project’s backstory.

 

Another essential element of the discovery phase is a complete code review by the developers. They should be able to evaluate the quality of the code and determine how much of it can be carried forward and how much needs to be replaced.

 

Having assembled a comprehensive picture that addresses the technical, human, and organizational issues of the previous project, you’re ready to address the next step in preparing for a brownfield development project — the gap analysis.

With an understanding of the project history and its current state, you are in a better position to determine what needs to be done to bring the project to a successful conclusion.

• Identify shortcomings - Find out how the current state fails to meet the expectations of the stakeholders. Is there missing functionality? Usability issues? Performance? Security? Compliance? Is it just visually ugly? (Don’t laugh, this can be an important issue for customer-facing websites and mobile apps.)
• Requirements comparison - If the original requirements documentation is available, compare your findings with the original requirements. Were the present requirements known and just not filled? Filled but unsatisfactory? Or are these brand-new requirements that were not known to the previous project team? Are there any original requirements that are no longer needed?
• Requirements update - Armed with this information, update the requirements to bring them current. Identify each requirement as “original and filled,” “original and incomplete, “original and not filled,” “original and no longer needed,” or “new.” This effort will require you to spend extensive quality time with the stakeholders so that nothing is overlooked, and everyone agrees on the target.

With the updated requirements in hand, you can plan the path forward. This will involve updating the product roadmap or establishing one if it doesn’t already exist. (For older legacy software that was not developed using the Agile methodology, you may be starting the roadmap from scratch.)

 

As a side note: If the previous effort was not done under Agile, the stakeholders may need some education on the Agile methodology and how it works. In particular, they need to understand that their involvement will be needed throughout the project, not just to review and validate the solution at the project’s completion.

 

Then, work with the stakeholders to set the priorities: What are the “must have” features? What features need to be added or corrected first? What are “nice-to-haves” features that can be addressed later? When working with various stakeholders, it’s important prioritize the issues that need to be addressed and to deal with their biggest pain points as early as possible.

 

The development team can take these priorities and break them down into the tasks that form the product backlog. Further analysis will determine the complexity and level of effort for each task, enabling the tasks to be organized into the development sprints.

For the most part, executing a brownfield project is little different from any other software development project. There are, however, some twists and things to watch out for.

 

Avoid Reinventing Everything

Developers working on updating a piece of existing code may be tempted to throw the whole thing out and start over from scratch. They will justify this desire with thoughts such as:

 

• “This code is inefficient. It would execute much faster if I refactored it.”
• “This code is difficult to understand. I need to just start over.”
• It would be so much better if this code used [name of newer framework].”

 

This urge must be avoided. Yes, there are times when tossing out existing code and replacing it from the ground up is justified: If the effort to update it exceeds the effort to rewrite it, then by all means go ahead. But looked at objectively, these cases will be rare.

 

More often, you will find that code needs to be rewritten in order to meet known performance, security, or interoperability requirements. However, this situation should be known before anyone starts coding anything, and should be factored into the level-of-effort estimate and sprint planning.

 

A major problem with rewriting existing code is the resulting unintended consequences. If another part of the application relies on that old code, and that code no longer exists or has changed so that it no longer takes the same input or provides the correct output, you may be introducing problems that could have been avoided.

 

Further, if you rewrite one part of the code, you may find that other, dependent parts need to be rewritten too. It won’t be long until the project becomes a total rewrite, which isn’t the goal of a brownfield project.

 

If nothing else, new code will often just take longer to write, thereby adding effort and complexity to the project. The best rule of thumb is: “If it ain’t broke, don’t fix it, even if it isn’t as pretty as you’d like.” Just tweak what needs tweaking and move on.

 

Anticipate “Discovered Work”

It’s highly likely (some would say “inevitable”) that, when working with an existing code base, some tasks will turn out to be more complex than the original estimate. Sometimes a change to one segment can’t be implemented without writing (or rewriting) another code segment, something that wasn’t known at the time of the initial code review and level-of-effort estimate.

 

This situation is known in the development world as “discovered work.” It’s not unique to brownfield projects, but you should expect more of it in a brownfield project than in other projects.

 

If the project schedule is packed too tightly, discovered work can throw off the entire timeline. For this reason, it’s often a good practice to add some padding to the schedule for a brownfield project. This can involve reducing the estimated amount of work that can be completed in each sprint or adding contingency sprints to the schedule that can be canceled if they aren’t needed.

 

How much padding to add depends on the skill of the team members in estimating complexity, the team’s experience in working brownfield projects, and the nature of the current project. In the spirit of “under-promise and over-deliver,” it’s safer to start with a schedule containing more padding than you’ll need than to ask for additional time part-way through the project.

 

Many brownfield projects come about due to the failure of a previous development team to execute and deliver what was promised or expected. Often there’s a perception that the stakeholders weren’t asked to participate in the project, and that this was a primary cause of the failure.

 

A properly planned and executed brownfield project is your chance to show that not all software development projects are poor experiences for the client. A positive experience starts with stakeholder involvement.

 

Involve the Stakeholders

There are many ways to involve the stakeholders. A few key one to keep in mind:

• Requirements gathering: All stakeholders should be involved in this phase. In particular, the end users often have the best insight into the pain points with the current software that must be addressed by the new project. Insights gained from stakeholder input and feedback are incredibly valuable and well go a long way to delivering a successful project outcome/
• Prototyping: Building and demonstrating application functionality and user interface prototypes is an important way to get feedback from the stakeholders and keep the design in line with their expectations. In fact, rapid prototyping can align stakeholder expectations and go a long way to expedite the development process and avoid costly development rework.
• End-of-sprint demos: The goal of every sprint is to have working, bug-free (if incomplete) software that could be deployed if needed. Demonstrating the progress of the project at the end of each sprint is another opportunity for feedback, and it provides concrete evidence that the development team is on track. Said another way, end-of sprint demos can go a long way to avoid un-welcomed surprises and build stakeholder enthusiasm.

 

Don’t underestimate stakeholder involvement. Keeping stakeholder involved gives them a sense of ownership in the product and a critical role in the project’s success.

Brownfield projects are inherently risky. Without proper preparation, your team could be just another group that fails to deliver the software the client needed. It’s important to make sure you know what you’re getting into before you agree to take on a brownfield development project. Being properly informed about the past development efforts and objectives will help to mitigate financial risks and, more importantly, help to ensure a positive project outcome that delivers increased business and user value.

 

At AndPlus, we have many years of experience completing successful brownfield projects —projects for maintaining legacy software and getting failed projects back on track to success. If your organization needs to pursue a brownfield project but doesn’t have the in-house resources to tackle it, give us a call. We’ll be glad to turn your brownfield project into a success story.