Initially, discussion around the possibility of starting a 3PL (third-party logistics) business within Nebraska Book Company was with a small company. They had around 50,000 books in their inventory. While early discovery work was happening with this company, the opportunity came forward to work with a much bigger client.
Eventually, terms were struck and we had a partnership with one of the largest online textbook rental providers, outside of Amazon – well over a million units of inventory.
While we were very familiar with managing our own textbook inventory – managing someone else’s was an entirely new ballgame and line of business for us.
My role with this project covers a lot of areas, and has evolved over time. I manage and prioritize work for both our internal and WMS (warehouse management system) development teams. I lead discovery work with stakeholders for new development requests and processes. I conduct independent research, write requirements, and design new enhancements. Finally, I build test plans, test development changes, and manage the implementation. This project is still on-going and remains my primary focus at this time.
Project Cycles
There were two main cycles, or phases, to the start of this project.
The first was to induct (receive) student return units at our distribution center, instead of them being returned to the previous ones. Additionally, there were bulk transfers of units to be inducted that were being held at the previous distribution centers.
The second was to receive and fulfill the first round of student orders with inventory from our distribution center (DC).
I’ll go into each of these initial cycles in more detail in a moment. Currently, we are now in a normal cycle of:
- Receiving and fulfilling student orders (outbound from our DC)
- Inducting student returns (inbound to our DC)
- Rinse and repeat
Initial Cycles
After the agreement was formed, design and development of the induction (receiving) and put-away processes began in earnest. We had a very short timeline to build this new system, so it was ready in time to receive student return shipments.
While these are normal processes for our own inventory and business, managing the logistics for our partner had some additional requirements:
- Much more inventory than we’re used to – required increased staffing, more efficient processes, and additional storage areas.
- Serialized inventory – each unit of our partner’s inventory has a unique serial number. None of our existing systems or processes were designed for this type of inventory.
- New integrations – new APIs had to be created between our WMS, our systems, and our partner – so they had an accurate, real-time view into their inventory.
As you can see, there was a veritable sea of boxes, waiting to be received into inventory. The development and testing process was rapid – we had to get the books out of those boxes and off of the floor!
After a few weeks of supporting the induction and put-away processes, we quickly got to work designing and developing the picking and outbound processes (to fulfill new student orders).
Once again we had another short timeline for development, testing, and implementation for the order fulfillment and outbound processes. We were able to implement on time, and focused on supporting these processes for the next few weeks.
Challenges
There were many challenges to overcome with this project, but I’ll touch on the big ones.
We had extremely narrow deadlines for the initial project cycles of inbound and outbound, especially for a project of this magnitude. This caused some short-term thinking in terms of design, and only allowed for minimal testing.
Moving this many books required a huge increase in hiring of temporary DC labor. Compounding that problem was keeping workers safe during the COVID-19 pandemic.
There were also some issues of burnout on the project team. Some team members decided to move on before additional staff could be brought in to bolster support.
With extremely short timelines, this inevitably caused system integration and support issues, requiring many manual fixes. The extra effort required was significant, and narrowed future development windows even more.
Results
We made our deadlines. 😅
But, we did pay a heavy price with rushing development and testing. A lot of work was put in to fix bugs, shore up processes, and provide extra validation of data between systems. While there was a massive improvement in data accuracy and reliability from the initial cycle to later ones, ultimately this project failed and the 3PL relationship between our two companies ended. Unrealistic timelines and expectations, problems of scale, and inadequate testing and design all contributed to this downfall.
Reflecting back on this project, it was an extremely stressful and sometimes very frustrating time in my career. I could smell the smoke of burnout. However, getting through it made me stronger. I learned the importance of teamwork, dealing with adversity and constraints, coming to terms with things outside of my control, and the importance of all the things mentioned above that caused the project to fail. This gave me a lot of experience in how to manage large, complex projects and better “radar” to see incoming problems before they happen.
