The Checkbox Project (Part 1: The Case Study)

This post is excerpted from the DevOps Enterprise Forum paper “The Checkbox Project: Learnings for Organizing for Outcomes.”

How long does it take to enable one checkbox? A seemingly straightforward digital task; yet, for a large enterprise, it often proves to be anything but.

Consider a company with a user base in the millions, which we will call Parts Unlimited. Their business team wanted to add an additional monthly third-party subscription service. Their users would simply have to check “Yes” to opt-in. The service offering was a third-party pass-through, requiring no additional delivery from Parts Unlimited.

However, adding this recurring subscription reveals a complex web of interdependencies. Product development needs to understand customer journeys. The IT department has to manage technical aspects. Global legal and compliance teams must ensure privacy regulations are met. Finance needs new fields for tracking revenue and for tax purposes. Marketing must determine segmentation and drive campaign promotion and success. And on and on and on across multiple channels and lines of business.

This single opt-in checkbox stumbled over nearly all of the challenges that come when cross-organizational collaboration is required to deliver value. Parts Unlimited wanted to go fast, but it was just not organizationally equipped to expedite and facilitate a working implementation in a rapid time frame. Doing so required that they crisscross organizational silos to deliver a checkbox that provided recurring revenue and economic value for the company.

For Parts Unlimited, there were three primary stages in implementation:

• Experience iterations: Understanding the user journey and discovering the permutations across various teams, value streams, and business segments.
• Design iterations: The technical implementation required determining where the code would live across the system of records and technology stacks and how data would be structured and flow.
• Program activities: Planning, funding, and delivering this initiative across multiple boundaries did not flow naturally. Substantial program management personnel and activities were required.

Let’s take a deeper look at these stages in practice.

First, Experience Iterations

The subscription checkbox soon starts to materialize as more complex than originally thought. User experience and business model questions demanded immediate attention. Should this offering go to all of their customers? Are there any customers for which it’s not applicable? Should customers have permission to approve the service on behalf of all users in their accounts? What monitors and resolutions will be in place if the integration is struggling or fails?

No one person or team can make these decisions on their own. Experience iterations span vertically down the IT teams and architects and horizontally across multiple major P&Ls across the entire company. Each experience iteration requires new code and artifacts to be created by individuals and realigning and context-switching from previously existing priorities, previous commitments, and attention to security and compliance—all before any customer or company value can be created.

Then, Design Iterations

Next came design iterations, and the spider web of dependencies continued to expand. In terms of customer interfaces, how will the checkbox be displayed across multiple frontends? In regards to billing, can their existing system handle the number of additional calls to check and write to the checkbox store? How will this be monitored and operated? Are there layers in place to ensure duplicative actions don’t occur? What about payment and nonpayment issues?

All design iteration scenarios would have to be thoroughly tested, but there were many challenges. Which team would generate accurate testing and customer data? How can changes be made to the system with no downtime or loss of transactions? Increasingly, they were also challenged with the challenge of enticing users to opt-in. Questions, decisions, and dependencies continued to mount, and they involved an expanding number of teams.

Finally, Program Activities

Due to the increasing scope of this project and the time it would require, a centralized program management function stepped in to ensure the workflow was organized. This included defining which teams need to do what work, what their current priorities and new schedule estimates would be, and how much it would cost the teams to make this “simple checkbox” change. The program managers at Parts Unlimited led priority conversations across more than twenty separate engineering teams and uncovered a substantial list of dependencies.

No tooling or representation for dependency impact existed, so Figure 1 is just a rough approximation of the tangled web of dependencies, many of which only became apparent when the project reached an impasse. In addition to these, they also had to:

• Determine go-no-go dates and iterations with “big bang” releases.
• Account for architectural changes as they learn more.
• Manage costs and OPEX conversations with every involved team to support this functionality.
• Create contracts and agreements with vendors, publish RFPs, hold vendors accountable, engage legal on all contracts and agreements, and accommodate for scope changes and increases in budgets.

The Results

In the end, Parts Unlimited achieved what they wanted: the ability to activate a “simple checkbox” so users could opt-in to an additional third-party subscription and enhance both customer and enterprise value. Doing so, however, required a managed and close collaboration across over twenty teams in multiple organizational hierarchies across multiple channels and segments, including involvement from many coordination roles and shared services. In addition, it required the involvement of senior-level executives to handle the reprioritization of current tasks, rally staff, and handle escalation.

In the end, the project took over twelve months from conception to completion and cost the company over $28 million to implement. Few stakeholders would consider it a success.

In the next post, we’ll look at how to evolve your organization to better outcomes.

Read the full paper in the Fall 2023 DevOps Enterprise Journal.

- About The Authors

Kamran Kazempour

Kamran Kazempour manages the Software Delivery & Developer Experience team for the Wallet, Payments and Commerce group at Apple. For over a decade, Kamran has been a leader and advocate for DevOps best practices and Lean principles across his organization. A Canadian from British Columbia, Kamran lives in California with his wife and their two children.

Chris Hill

Speaker, author, leader, evangelist, engineer, researcher, and disruptor in developer relations and experience

Follow Chris on Social Media

• 
• 

Steve Pereira

Steve Pereira has spent over two decades improving the flow of work across organizations. He’s worked through tech support, IT management, build and release engineering, and as a founding CTO for enterprise SaaS. He serves as lead consultant for Visible Value Stream Consulting, as a board advisor to the Value Stream Management Consortium, Chair of the OASIS Value Stream Management Interoperability technical committee, and co-founder of the Flow Collective to bring flow-focused professionals together. Since 2017, he has been developing and facilitating Flow Engineering to make flow improvement in large organizations accessible, collaborative, and actionable.

Follow Steve on Social Media

• 
• 

Dean Leffingwell

Cofounder and Chief Methodologist at Scaled Agile, Inc.

Follow Dean on Social Media

• 
• 

Amy Willard

Amy Willard is an IT Director leading John Deere’s Agile Operating Model transformation.

Follow Amy on Social Media

•