Defining Enterprise Product Delivery Process

Executive Summary:

Monsanto was “old school” in it’s research and tracking of data. When someone told you all the data from their experiments was in their journals, it meant it was literally written in a journals.

A massive digital transformation was undertaken to modernize the number six on the Global 500 list and a massive product team was assembled hiring top talent from all over the world.

Challenge

You have to start somewhere and development started immediately. While a product team was assembled to start working through the initiative on a product by product basis. The product team started small and grown over time.

I was assigned to the chemistry division. They were having digital products rejected by project sponsors at a concerning rate and tech debt was becoming insurmountable. My task was to increase the adoption of Experience Design by improving the product process and convincing the team to adopt it.

It was a really life changing job. I’d never worked at the organization level before. I had worked on enterprise products, but to give you an idea of size, the chemistry department had it’s own campus.

Results

This was a total team effort, as I had never worked with so many teams on a project before and I honestly don’t know if I will again. I hope so, cause it was a blast. We had to bring together agile coaches, product managers, business leads, development leads, department heads, developments teams, product owners, project sponsors and I know there’s a few more I’m forgetting.

I was grateful, every day, at the end of the day when I got to return to the product design area (we had our own floor on a different campus) and decompress with the team. We’d exchange ideas and talk about our challenges. There were a lot of whiteboarding sessions.

At the end of the six month contract the team and I were able to deliver a process for bringing products to fruition that would increase the viability of the final product and minimize the change it would be rejected. It may seem simple to look at it, but it took a lot of brain power to make this happen.

---

Introduction

There is no one fault when a system breaks down. There’s always a million things that can and do, go wrong, when product are created. The bigger the system, the more the more people there are, the more boxes that need checked the more the odds that a system breaks down. I didn’t really know that before this project.

So, I cannot stress enough how awesome it is to work with a large collection of likeminded people. Even more so from such a diverse educational, geographical and experiential group of people. I was honored to be on the same footing as people with multiple degrees and even a few with double doctorates from all over the world. I also had an amazing boss who constantly encouraged me to follow my instincts and helped me shape my ideas through conversation.

The Discovery

Shortly before I started there were two large scale workshops including people from each of the groups I mentioned earlier and across all divisions. The Product Design Team assembled all in an auditorium (they had an auditorium in every building) and performed a mapping exercise, identifying all the challenges associated with the product creation process from beginning to end.

This was a amazing workshop, I wish I could have been there. I heard the stories and was lucky to learn from their experience. Most of all, I got to learn from their documentation. It wasn’t the typical kind. I was amazed at how much information could be represented and visualized from simple calculations.

The Symptoms

Looking at the process, the number of negative inputs at the point of delivery was exponentially larger than any other point in the process. Conducting an analysis of the the inputs I was able to find two main categories; product didn’t meet expectations and lack of adoption.

Additional Research

Using the analysis as a starting point I conducted interviews with chemistry representatives from the workshop. Focusing on where they believed the issues to come from and how they thought they should be resolved. People tend to talk more when they feel empowered to share their expertise.

The conversations led to what seemed like two obvious challenges. The first was with the development first approach the sponsoring teams never got to see the product as a whole until it was delivered. The second was communication. There was no leadup to the product being released, notice was only sent at the time of launch.

Working the Problem

Back to the whiteboard, and working with the product sponsor, we spent hours talking it through as a the team. Coming up with a relatively simple solution. Perform a design sprint to clarify the requirements and provide the team with a frame of reference.

The second was to ensure there were touch-points at strategic points during the product cycle to ensure it was still in line with expectations. These touch-points would result in product reports that would be released by the communications team.

The Finished Process

Discovery cannot be replaced by requirement gathering. Most of the gaps identified were due to a lack of discovery and communication.

• Discovery: Added journey mapping and a design sprint to create a shared understanding.
• Evaluation: Adding time to review the work compared to the initial requirements and re-scope based on the shared understanding.
• Design: Implementing a six week feedback loop including user testing and revising the previously delivered prototype.
• Communication: For each cycle the progress reports and updated documentation would be shared with all stakeholders and future users to increase awareness and potential for adoption.

So many thanks

Where to begin? To everyone involved, thank you for your collaboration and candor.