How AWS Partners Can Drive Cloud Transformation for Customers Through Experience-Based Acceleration
By Maria Babilon, Sr. Manager, Customer Solutions – AWS
By Robert Heitzler, Principal Account Executive – AWS
The ability for AWS Partners to scale cloud transformation for their customers is essential to partners’ ability to retain and grow their business. Partners who have the transformation skill set are more likely to drive customer acceleration and higher customer satisfaction scores.
This post aims to educate AWS Partners on using Experience-Based Acceleration (EBA) as a mechanism to drive cloud transformation and increase time to value for Amazon Web Services (AWS) customers.
The information we present here will enable AWS Partners to leverage the EBA methodology, and we’ll highlight best practices for rapid modernization through agile transformation. By the end, AWS Partners will learn to scale EBA across enterprises to drive cloud maturity through key stages of adoption.
Overview of EBA Modernization Mechanism
Experience-Based Acceleration is a repeatable practice designed for customers to build capabilities and transform, de-risk, and accelerate their modernization programs and projects. It implies the EBA is a complete process, and it is built upon tools, adoption, and inspection.
This EBA overview video provides the AWS representation of Experience-Based Acceleration.
Experience-Based Acceleration ensures quick wins for the customer in a compressed time frame, and focuses on both technical and non-technical friction points—including leadership, people, process, application, and technical—in order to break down organizational siloes and remove friction points.
The EBA is a transformation methodology with hands-on agile interactions to build customer and partner capability and accelerate business value. There are many different possibilities for EBA activities, but in this post we’ll look at the Modernization EBA that is partner-led.
Modernization EBA to Improve the Customer Experience
Mechanisms such as Experience-Based Acceleration improve the customer experience by a focused approach to team-building communications (for example, succinct daily stand-up meetings) and workflows across departments, levels, the business, and IT.
EBA reduces time to value that is spent on “analysis paralysis” and continuous planning. AWS Partners leading the EBA will train the customer to become confident in their use of cloud skills in order to operate successfully in the AWS environment with less dependency on partners and AWS.
EBA Flywheel for Rapid Modernization
The flywheel for partner EBA scaling is an AWS cycle that consists of training, pre-planning, planning, executing, and post-EBA support. It’s a repeatable pattern that incorporates timelines to set expectations with the customer and partner on the lifecycle of an EBA.
The flywheel is intended as a guidepost, and the more EBAs a partner completes the faster the flywheel will spin. For example, the first EBA pre-planning with an AWS Partner took the full 12 weeks, while subsequent EBA pre-planning and planning was accomplished in 4-5 weeks total.
Based upon recent use cases, we have seen a partner-led modernization EBA (2.5-day duration) accelerate the customer’s work 1,200% faster. This was accomplished by removing the blockers from the project in real time, which saved an estimated 28 calendar days.
Figure 1 – Flywheel for partner EBA scaling.
A successful partner-led EBA requires emphasis on training first, especially if it’s the partner’s initial foray into EBAs. The partner should spend time reviewing the resources in this post and building initial EBA training into their plan.
EBA partner training videos are available through the AWS Partner Network (APN) and can be accessed via Partner Central (login required). The training is as simple as viewing the partner “EBA Foundations” video for approximately one hour.
The AWS team guiding the EBA can provide all of the partner links and assist the partner in setting up an EBA watch party of the EBA Foundations Class.
Pre-Planning the EBA
It’s best to plan the executive leadership sponsorship at least 8-12 weeks in advance of the actual EBA. Most importantly, it’s essential to obtain executive leadership sponsorship, commitment, and alignment with the customer and AWS for a partner-led EBA. The sponsorship is “three in a box” and should cover the customer leader(s), partner leaders, and the AWS leader.
Within the partner organization, we have seen that successful EBAs require buy-in from senior leaders. Having a knowledgeable partner program manager at the helm ensures the partner team is working backwards from the EBA with plenty of ramp-up time to get all members aligned and documented well in advance.
At about 8-10 weeks, the next crucial step is to agree upon which short list of partner-led projects make the best candidate for an EBA. Some things to consider are:
- Build the partner short list of at least three projects to discuss.
- Select migration projects that are low-hanging fruits to demonstrate quick successes.
- Projects should have sufficient scope to be in the early stages and not nearing production.
- Projects should be able to set achievable and aggressive goals for a three-day EBA with cloud and organizational outcomes.
Planning the EBA
At around 8 weeks, the partner will want to start building their team based upon the decisions and outputs from pre-planning. The team should be cross-functional, empowered, and agile-based. We have seen that partner teams work best with a mixture of project management, DevOps, and testing, which could be resourced from an existing partner engagement in flight.
The partner EBA lead should set the expectation with the team to motivate them for the experimentation during the EBA. AWS provides templates and EBA kits that are specific to the partner, and these can be used to generate all of the pre-meeting materials, including overview and kickoff presentations, training materials, goal setting, participant list, work stream worksheets, and backlog.
The partner will need a plan or roadmap for execution. The plan should work backwards from the EBA target date with a week-by-week countdown. To plan and execute the roadmap, the partner will need the support of technical or workstream leads. This will typically be the responsibility of the Solutions Architect in coordination with the partner team.
The partner EBA lead will want to ensure the executive leadership (partner, customer, AWS) are prepared to speak briefly on the first morning for kickoff. It would be helpful for the partner to prepare the bullet points in advance, at least for the partner executives.
One purpose of the EBA is to build a culture and develop a team across the dimensions of agile ways of working. The partner-led EBA focuses on hands-on use of mechanisms and creates a less stressful environment for learning and team building to occur across project teams who may have never met in person or been able to invest the time for team building.
In the next section, we’ll look at how the partner may introduce the EBA which combines the Customer Obsession, Dive Deep, and Learn and Be Curious Amazon leadership principles in an experiential workshop, where there is room to experiment within the bounds of the team’s self-managed goals.
For logistics, the partner should determine if the EBA will be onsite, remote, or a hybrid combination. The partner should collaborate in conjunction with AWS on the EBA theme. Some themes that have worked well include: Western, Hawaiian, and wearing different hats. The partner should have input into the theme and the meal selection.
The partner EBA lead should allow at least two weeks’ notice for letting the customer know the theme and plan to have food orders and final headcount for meals two weeks out from the EBA, if possible. The partner EBA lead will want to order cowbells (yes, cowbells for the “bell ringers”) so there are enough to support each workstream.
Regardless of the EBA format, the collaboration tools used for the EBA are of key importance, and they should be agreed upon between the customer, partner, and AWS. Once the tools are agreed, it’s a matter of documenting how they are to be used so that everyone participating in the EBA, spanning all roles, knows how to communicate. For example, where will the key templates and files be shared with the partner?
Another consideration is the meeting tool. If the customer specifies a tool, does the partner have access to the tool and thorough knowledge on how to use it to set up breakout rooms, administration, and file sharing? If the partner is the tool administrator, does the EBA facilitator have admin rights as well? Does the EBA facilitator have access to the folder structure for every EBA completed template, and worksheet?
Executing the EBA
The purpose of executing is to manage small deployments in the cloud, slowly building confidence. It’s also to gain traction and velocity on business and application outcomes.
Some potential outcomes from a partner EBA include:
- Fully defined requirements.
- New process creation.
- Two-way door decisions made and documented on the direction and strategy.
- Clear time frames and critical path.
- Deployed workloads.
- Partner-customer-AWS team alignment.
- Hands on learning and training of EBAs, AWS environment, and how to work on a global project with multiple time zones.
The key to successful execution is building the required checkpoints along the way. There should be a morning and afternoon check-in with the workstream leads. The partner management, along with customer and AWS management, join the checkpoints to hear the progress updates and assist with removing blockers to the team’s successful EBA.
The other key to successful execution is an off-line check-in with the workstream leads at the end of the day one and day two sessions for the purpose of course correcting the following day’s agenda.
Finally, the partner will want to document progress in real time. The EBA partner lead should be taking notes daily and ensuring that all EBA templates are being populated with actions, risks, issues, blockers, and accomplishments or bell ringers. The partner does not want to be surprised on the third day that there is no documentation or materials to substantiate the success of the EBA.
What happens after an EBA is equally as important as the “before” and “during” phase. The outputs of the EBA will be shared across multiple organizations and leaders, so the data needs to be captured correctly during the EBA.
This includes business outcomes and the execution of stated goals, acceleration of time frames and critical path, and the number of deployments that met business outcomes. We have seen, based upon successful use cases, an acceleration of 1,200% on development speed across 2.5 day partner-led modernization EBA.
It’s important for the partners to know that AWS positions EBA Ambassadors as scaling team members who will be requesting statistics that are specific to the EBA. This data includes the number of blockers removed, amount of backlog items or tasks that were added as a result of the EBA, total attendees from each organization, and even the number of cowbell rings.
The partner will want to complete a “lessons learned” document of the EBA with the partner team, at a minimum. This should consist of the lessons learned EBA template being populated with key highlights of learning across all workstreams. Typically, the lessons learned should be summarized a few days after the EBA and while the retention of the retrospective items is still fresh in everyone’s minds.
Scaling an EBA Across the Enterprise
Scaling will become easier once the partner completes the first EBA. As a result of a successful EBA, both word-of-mouth references from the customer and within AWS become possible.
The number of after-action documents generate positive communication and reinforcement on the success of the event, and the partner can work with AWS to ensure there is agreement on these marketing materials. These documents should be placed in the appropriate AWS and partner communication channels, such as Slack or Teams.
The scaling of an EBA follows many of the same steps as the individual EBA. The partner will still need to manage the pre-planning, starting with a short list of follow-up projects that are based upon similar criteria to the original EBA. The difference is that the partner may work across projects or portfolio, selecting a different project team and different project scope based upon timing, urgency, and other factors. It’s helpful to have the same partner program manager who worked the original or first EBA to consult to future partner EBAs.
A successful partner-led Experience-Based Acceleration (EBA) is transformational and can enhance the customer’s overall experience with the partner and with AWS.
In this post, we have included some key guidance around the flywheel for rapid modernization with an EBA, and we’ve looked at the recipe for success which trains the partner on EBA foundations. We’ve broken out each phase into the core EBA phases of pre-planning, planning, and execution.
Finally, the need for post-EBA support has been highlighted as an essential step. Please refer to the resources below for additional information on how AWS Partners can drive cloud transformation for customers through the Experience-Based Acceleration methodology.
Here’s a list of partner-specific resources for an EBA or governance you may find useful: