Planning and executing greenfield projects is no easy feat. It requires meticulous planning and flawless execution. Tune in to see how we unveil our strategy to achieve the utmost client satisfaction and critical decisions agreed upon within 15 minutes.

Introduction

Greenfield projects are innately vague requiring a significant amount of investigation, planning, and communication with clients. To put it in simple terms, you’re responsible for building a solution from the ground up collaborating with people you have never met before.

This blog focuses on how we tackle and execute projects that keep both the client’s and the supplier’s satisfaction high. To maximise efficacy we have built a model that partitions the work into four key areas; discovery, planning, execution and feedback.

Discovery

This initial stage sets the foundation of the model. It involves interacting with stakeholders within the business to assess the core requirements. A pivotal step is to remove any assumptions that the client will know the full intricate details of what they envision to be built. Removing this stark assumption eliminates imminent futures where you build solutions that do not bring the clients any value.

During this stage, a map of potential stakeholders that will interact with the system is built. It’s paramount we first understand all potential users and their dependencies. Each one will have eccentric requirements differentiating from its counterparts. Even if you’re building a solution solely for one stakeholder initially, it’s still a great exercise to include others as part of the discussions. Doing so, sets you up in the future when the client asks_ “How will this solution scale when we expand our workloads for Asia Pacific in two years”?_ This allows us to provide a solution that has scalability in mind.

After completion of the map, it provides us with a list of stakeholders we need to learn more about to identify their expectations of the solution. This can be done by setting up interviews which we will cover in the next part. The figure below details an example of a stakeholder dependency map.

Interviews

After building out the external map of potential dependencies, it sets us up to start interviewing each stakeholder. This step involves scheduling a 30-minute meeting with individuals to gauge their roles, responsibilities and requirements. As a prerequisite, due diligence is conducted to associate areas of responsibility to each stakeholder enabling us to tailor questions to separate domains. We then subsequently produce a template formulating a list of questions we should ask each stakeholder. This has a positive side effect: remove any inefficient questions that would lead to answers that require speaking to other stakeholders outside of the meeting. Such a simple step improves the overall efficiency of the meeting and prevents answers such as “You’ll need to ask the networking team as I’m not sure about the details on that”.

The meeting structure consists of allowing the stakeholder to drive the conversation initially. This provides the opportunity to cross-check our template to see if it covers any points that have been previously mentioned. Additionally, the stakeholder can provide context on how their processes are currently functioning to help us gauge their contemporary dynamics.

The figure below details an example of a template we can use when interviewing a stakeholder responsible for the security domain.

Planning

Given the feedback we have received from the interviews, that data is condensed to summarise the key takeaways that can be used to build out formal requirements. With this data, we are now able to effectively prioritise and advocate technological solutions. This stage allows us to conceptualise solutions by leveraging various heuristics such as proof of concepts, and high and low-level design specifications.

Proof of Concept/ Spike

Before suggesting any tools/ technologies, we leverage the condensed information retrieved from the interviews, to investigate and perform rigorous testing around proof of concepts that can augment solving key requirements. Evaluation is done on various tools comparing the tradeoffs. Executing spikes in parallel to planning, presents an opportunity to validate architectural design choices we recommend and allows us to battle test tools before recommendations.

High-Level Design (HLD)

To help formalize an agreement and provide formal documentation, we create a high-level design document for the client that highlights the main areas of the solution we will be providing. This is a formal document that outlines a design specification.

A typical document can typically cover the following areas:

• Networking
• Compute
• Tagging
• Identity and Access Management
• Policy
• Monitoring
• Backup
• Cost Management

Abstract diagram from HLD below:

Low-Level Design (LLD)

Another document (Low-Level Design) is provided that follows a similar layout to the HLD. This covers intricate details of how the solution will work and follows a consistent structure similar to HLD. Typically you find several diagrams in this document detailing relationships between components and entities in different architectures.

The figure below details an example of what you may find in a Low-Level Design Document. In this case, it covers an architectural diagram detailing how the account management hierarchy will work in a cloud environment.

Architectural Decision Records

Making decisions that affect stakeholders usually can take weeks, months, or in some extreme cases years to get a consensus. It’s important that whatever you’re building, you get buy-in from all parties. In the previous step, we defined design specifications that outline key areas of the solution we intend to build but there is one problem: stakeholders are busy and do not have unlimited time to read a 40-page document. Approval is required for key areas in the design specifications but we can’t afford to wait weeks or months. This is where Architectural Decision Records (ADRs) come into play.

Architectural Decisions Records are a single document that highlights a problem and a list of potential options for resolution. It’s useful for auditing key decisions made within the business but also allows you to condense a bigger problem into smaller parts that can be easily understood by various groups consequently leading to quicker decisions.

By leveraging ADRs, we can fragment parts of the High-Level Design (HLD) and convert them into a one-page document that can simply represent one problem with alternative options for solving it. Each option will have tradeoffs highlighted. This grants us the ability to present ADRs to stakeholders.

The figure below illustrates leveraging design documents to split up problems with the use of ADRs and get approval from various stakeholders.

Execution

Now we have a better idea of how the trajectory of the project looks and the type of work that needs to be prioritised. Due to a significant amount of investment going into discovery/planning execution should be seamless.

In the first part of this stage, we set up 1-hour meetings maximum with stakeholders identified in earlier stages. In these meetings, we present an architectural decision record (previously refined in the planning step) to the targeted stakeholder. Due to the amount of due diligence, we have taken to research various options with tradeoffs and document it in the ADR, our pitch easily allows the stakeholder to understand the problem and the solutions within a matter of minutes.

We have had significant value and great success in making quick decisions with the use of ADRs. In a recent project that we completed for a client, we had over 12 ADRs approved with each one taking less than 15 minutes with key stakeholders (including stakeholders from the CTO team).

Another positive side effect of using ADRs is that it inadvertently scopes out the coarse-grained details of what needs to be done to solve a particular problem. This ADR can be converted into a JIRA epic, story or even task making this highly compatible with agile environments. The figure below shows a timeline of critical ADRs being approved.

Feedback

This is the final stage which involves gathering feedback from the client. This allows the collection of feedback that can be used for future engagements. It involves scheduling a short call with the client allowing them to provide detailed feedback on the project journey. This is a great exercise to allow us to document our successes by gauging the overall morale of the client and listening to their feedback.

Quite recently we were recognised for our deliverable for one of our projects within the healthcare sector where many c-suite leaders recognised us for the project’s success.

Summary

We’ve looked at how CECG manages to execute greenfield projects that keep both the client and the suppliers happy. Involving building a framework consisting of discovery, planning, execution and feedback. The framework provided us with the resources to complete projects months before the estimated deadline agreed with the client. Hope some of you can utilise this framework that will help carve out your future customer success stories!