In my time at ArgonDigital, I’ve had a chance to work with a number of different clients, operating in a range of industries. Oftentimes, these clients begin projects with a number of legacy systems that need updated or integrated with; it is a rare opportunity for a project team to get to create a solution from scratch, in a purely green field scenario. In these cases, the team’s only guide to follow is the human processes that have been used by the organization in the past. While this may seem like a flawed approach since ArgonDigital is typically brought in to replace many of the manual processes with some form of automation, it truly is an optimal way to start a project from a values perspective.

Recently, I had a chance to work on a green field project under similar circumstances to those described above, and the experience has shown me that the basis for all software envisioning must begin with a firm understanding of both a company’s business objectives as they relate to the problem space, as well as a clear description of the manual processes that lead up to the decision to add automation to a process. In this post, I would like to share my process for defining a solution in a green field, as well as some of the common issues I encountered during the project’s elicitation sessions.

As I mentioned above, the first step to any project must be an initial discussion of business problems and business objectives. Using our Business Objective model, we are able to guide our customers through the process of identifying the underlying problems they wish to solve, along with clear, measurable business objectives to define when a problem has actually been solved. The first discussion of business objectives is just a way into the project and a starting point. I found myself revising the Business Objectives model throughout the envisioning process, as many as 26 times, before setting on a final version.

So, getting back to the process, once a team of subject matter experts and project sponsors come to a preliminary agreement on the goals of a project, I dive into capturing what the business does today to execute the specific processes with the planned system. Once clear process flows have been created, this information will define the contours of the team’s future state solution.

“Why worry about current state?” you may ask. Well, the answer is both simple and profound: without understanding what a business needs to accomplish today (however flawed the methods for accomplishing those needs may be) you are not only risking implementing a new system that lacks the functionality users need, but you also risk buying or building features that are unnecessary, impacting the overall value realized by an organization.

With a firm understanding of the projects goals, and how an organization functions today, we can begin discussions around the specific parts of a process that could be made more efficient through automation. This type of elicitation should be open and wide ranging, leaving out considerations of feasibility and price. The outcome of this stage should be a massive list of features; a wish list if you will.

Now is the time to start analyzing your wish list against your current processes and business objectives. If a capability or feature doesn’t directly address a goal of current state processes or, more importantly, doesn’t relate to one of the business objectives that have been captured, you know you have a cut-able feature. Ultimately, the outcome of this analysis will be a list of high priority features that directly map to the project’s objectives.

Once this list is created, it is time to reconvene your project team and hold prioritization discussions, to understand, from the user’s perspective, what features are highest priorities. This sort of ranking exercise becomes the basis of the team’s project planning.

Through this approach, the product manager, as well as the project team has the ability to not only narrow their focus to the specific problems that must be solved, but also eliminate any features that risk adding to the cost of the solution. This type of analysis can provide extreme value not only to green field custom development projects, but also to projects that will ultimately opt to purchase a pre-built solution from a vendor.

Be sure to tell us, in the comment section below, about your experiences gathering requirements in a green field, and what sort of techniques helped your organization settle on the right solution.