Have I ever developed anything for customers that they didn’t really want in the first place? A project that did not produce value and took far too long to realize this?
Sure I have. I worked in state government! However, the example that I want to share actually comes from an industry that is well-known for maximizing customer value and eliminating waste...consulting.
In my first six months as an associate working for a top environmental and health sciences consulting firm, I was tasked with restructuring a more than 14 gigabyte network drive. The files on this network drive -- essentially a “data dump” of what had been amassed by a succession of consultants during a contaminated industrial site’s 40+ year history of environmental investigations -- had been recently inherited from the latest consulting firm in the chain. Included were thousands of historical reports, emails, letter correspondence, regulatory decisions and guidelines, databases, maps, and other project materials for the site.
The two project managers who assigned me with this task wanted me to create a network-based document repository. The purpose of the repository was for the team to easily navigate and search for project-related documentation throughout the course of the project because increasing accessibility to these materials will help the team to more efficiently and accurately complete their work on this long-term, multi-phase project that could easily last a decade.
As a junior staff member, I did not question our approach. This seemed like a simple task, and quite frankly, a great way to accumulate billable hours which was proving harder than I thought since most tasks up until this point had required a significant amount of unbillable professional development and training hours. So, I simply went forward with the assignment. This involved:
Sifting through all of the documents;
Running scripts converting the scanned files into readable text;
Creating clear file folder structures organized by date, consultant, and project type;
Constructing a document tracking log in Excel (the project managers’ tool of choice) containing metadata on the file type, file path, date authored, document type, project name, consultant name, and regulatory approval status;
Entering new documents prepared by the team, new documents received by the regulatory agency and from the tens of other consulting firms working on neighboring project sites into the newly created document repository and document tracking log; and
Crafting a three-page memo outlining the structure, protocols, and best practices for filing and searching for documents, data, maps, etc. in the repository for the team, which went through three revisions with the project managers.
About 6 months and close to 200 project hours later, we were done. The repository was finished, maintenance systems were in place, and we were ready to roll it out to the team. I thought that other than the ongoing repository maintenance tasks, my work was complete, and that we had created an incredible tool that would be used by all 35 staff, improve operational efficiencies (meaning I would no longer be emailed 38 million times per day by staff who needed a certain document, like, yesterday and could not find it), and everyone would be happy.
Once we rolled out the system and shared the memo with the staff, my teammates kept emailing me a.k.a. “the unofficial librarian” with document requests. It turns out staff didn’t want to navigate the file hierarchy I had created. It was easier for them to type the author, date, title, or whatever little information they had on the document into an email and ask me to find it, now that I was the document expert.
After digging a little deeper, I learned what people really had wanted was a search engine. They wanted the ability to enter a query with a few keywords into a cloud-based search engine, which they could easily access at home or on the road. This would avoid the inevitable slow VPN connection and the struggle to remember the correct filepath and structure of the document repository I had spent so much of our client’s budget to create.
After I learned this, I wondered, why didn’t we know this earlier? Now we were stuck with what we had as we surely couldn’t justify a new document organization project to the client, even though I was essentially the only person using the system.
Looking back on this experience, it seems obvious that this could have been prevented had we learned what people truly wanted earlier on. One way that we could have tested our hypothesis -- that the project team will use a network-based document repository to search for project-related documentation throughout the course of a potential decade-long project to help them get their work done faster and better -- would have been to use the lean startup method proposed by Eric Ries in 2008.
Prior to spending significant project resources on producing a fully finished product, we could have quickly created and deployed a minimum viable product (MVP) to elicit team feedback allowing us to tailor the product to the team’s needs. This MVP, perhaps containing only a subset of the total documents, could have allowed us to rapidly test the idea on a few select team members and measure whether they were willing to use a document repository at all. We also could have explored what the members initial reactions were to the repository, how many times they used it, did they use it as we intended, did they encountered issues, etc. We likely would have learned at this early stage in the process whether to continue with the idea or to pivot. Unfortunately, we didn’t create an MVP and we didn’t pilot. We didn’t even ask the team for their input in the development of the “solution.”
Now that I’ve left the company, I still hold out residual hope that either someone is maintaining the repository I toiled over and that people started to pick up the system or that the team got additional budget and created the search-engine system they wanted all along.
