I just saw a Harvard Business Review article “Are You Solving the Right Problems?” (thanks Marty for sharing that) that made me want to share my go-to story on requirements gathering and focusing on the need rather than the solution. I use this story fairly frequently, so some of you are probably already rolling your eyes because you’ve heard this lame story before.

A long time ago in a state far, far away, a couple of colleagues and I were assigned to join another project that was running over budget and time. Our prior project had wrapped up with about 6 weeks to go before fiscal year end and new projects wouldn’t spin up until the new fiscal year. The goal was to help this other project get some more work done before end of the year.

Anyone with any sort of app dev management chops can tell you how adding people to a project late in the game usually doesn’t help accelerate the project and usually just makes it run longer. It hurts because you divert the people who are currently working on the project to help ramp up the new people on all the nuances and intricacies of the project. This is sometimes known as Brook’s Law because it appeared in one of the papers that was ultimately bundled into The Mythical Man-Month. Often the best way to employ folks who land in your lap like that is to find something they can independently work on. In this case there was a feature that needed to be implemented and hadn’t been started. Perfect.

This system was a typical business system built as an intranet web site. Any given client project would have a whole bunch of information that would be collected across multiple pages. So far, so normal. There was a requirement to be able to “save all of the pages for a given project as a pdf”. I.e. Export the whole project to PDF.

On the surface that doesn’t sound too crazy. However, at the time (I did say “a long time ago”), PDF wasn’t the established document sharing format it is today. In fact, it was still a little bit of a loose cannon to the conservative sorts within the organization (IT or not). This presented us a few problems.

  1. There wasn’t any existing expertise in the format itself anywhere in the team. Trying to create the PDF with custom code was out of the question in the time we had.
  2. I’d very recently had a conversation with a manager on another project who had been part of an effort to find a PDF export component that was safe to run server side (safe for multiple processes/threads, does not require a user signed-in to the desktop, etc). That team had been unable to find something that would work. There was promise that would change in the near future, but we needed a solution for release 1.
  3. Given that we had no previously vetted component to use, we would go through the whole vendor/component selection process. Our procurement process alone would take longer than the short time we had on the project. Now add in proof-of-concept and all that, you can see we were doomed from the outset. You can also see why an overburdened development team kicked this problem down the road!

Fortunately, the overall tech lead for the project had a possible workaround thought up. Given a server side component was essentially out of the question, what about a client side solution? We did have a “print to PDF” driver already approved (again, it was a long time ago, print to PDF wasn’t a standard Windows feature then) and available through the firm’s software management system. We could add media specific style sheets for printing, clean up the HTML where needed, and then provide some wrapper screens that would let the user pick what parts they wanted to print from all of the pages they wanted to export to PDF. They also would be able to print the page they were on by itself without having to go through the wrapper.

So, sounds like we can get off and running. Technical hurdle cleared, we move onto the discussions with the business analysts and subject matter experts to flesh out some more detail on those wrapper screens’ behavior. During those discussions, we were describing the process with an SME from the business. She was talking us through how the users used the existing system when I started wondering if there wasn’t another file format that would be acceptable. This let me to a simple question.

Me: “What do you do with these PDFs?”

SME: “Everyone I know who uses that feature in the existing system does it because they need a paper file.”

Me: “So they just use the export to PDF so they can print it?”

SME: “Yes.”

Me: “So you don’t need to export to PDF at all. The real feature you need is printing?”

SME: “Yes, that’s really it. In the event someone actually does want a PDF to email or something like that, using the PDF print driver is fine. Most of us have it installed for use in another system anyway.”

Obviously I wasn’t sitting there recording exact words and it was about 12 years ago and there was a bit more than that, but that should illustrate the point.

It all worked out in the end, but we only got there because the tech lead was forced into thinking about working around a requirement he knew he couldn’t implement as asked for. Had there been a clear server side component that we bought, we would have probably spent a pretty nasty sum licensing it given how we needed to deploy the app. We still would have needed to do basically all the work to make the app content exportable, so we wouldn’t have saved really any time on implementation.

Lessons Learned

  1. Always look at your requirements with an eye towards making sure the need is expressed first, not the solution.
  2. Do not mistake a legacy system’s features for requirements. Those features are solutions to that system’s requirements. You don’t know how they got there and whether the feature itself wasn’t a workaround.
  3. Getting to solutions too early can cost far more than taking that time to be sure you have needs and not solutions as requirements.
  4. Don’t allow anything you don’t have an answer for to be scheduled late in the project. Deal with risk early and least understand how you’re going to solve it (with a meaningful PoC) before you punt it.

This is a fairly trivial story but I like it because it comes with a twist. We had requirement A, we came up with workaround B thinking A would be addressed directly in release 2. However, it turned out A was the workaround and B was the desired feature. We got there accidentally thanks to that strange concept of direct communication. How many projects never get there even with a team that communicates well?