Dave's Blog

I’m still somewhat scarred by my consulting project for Pittsburgh Action Against Rape (PAAR) as a part of Students Consulting for Nonprofit Organizations (SCNO). They came to us seeking help with a variety of projects aimed at optimizing their advertising campaigns. In my first meeting with the client, I had the bright idea of creating a spreadsheet using census data to target their campaigns. So if they wanted to find the neighborhood in Pittsburgh with the highest proportion white females aged 40-50, they could refer to this excel spreadsheet. Of course, they didn’t have the time or capacity to ever create something like this, but they loved the idea.

I left that meeting and delegated the project to a computer engineer in my group. I told her to create a spreadsheet using census data that could be sorted by each county, then sorted by ethnicity makeup and the age makeup of women. So the end goal was to give PAAR the ability to target counties with women that had the greatest proportion of women of a certain age and ethnicity.

A few immediate issues: I had no idea how to create this template. My conversations with PAAR and my teammate never included any “specifics” about the database.

Early on in the project, I just let my teammate work and didn’t ask much about the project. As the semester continued, I started to ask more about the project, and I’d get vague status updates. I was fine with this though, because I had no expertise in the subject. I just wanted to hear that it was coming along. She could’ve told me just about anything, and I would’ve said it was fine. Because I had little information or understanding about the spreadsheet, I gave very few status updates to the client. We never discussed more specific things they wanted, or talked through the details of the spreadsheet. I just said it was coming along. Come presentation week, I asked to see the spreadsheet. My teammate showed me how the excel sheet linked online to the census data and could be sorted. After about 20 minutes of explanations about the processes and what the data that appeared meant, I thought we were set!

Yet, when we showed this spreadsheet to the client, I realized how completely misguided I was. First, they did not understand what the data meant on the sheet. Also, the steps needed to reproduce the output using different data were complicated and they seemed confused. Also, they wanted the data organized by more than just ethnicity and age – we had just not spoken about those kind of details since the start of the semester. I left that presentation so disappointed. I knew my group had the capacity to create a spreadsheet that really could’ve helped them out. Instead, we left them with this burdensome sheet they probably were never going to use. They didn’t know how to use it, couldn’t understand the output, or even refine the data in all the ways they wanted.

This waterfall project truly crashed in my face.

On a grand scale, I should’ve tried to create a more agile system of designing this spreadsheet. One of the major reasons agile was appropriate for our project was because it dealt with an unknown goal. We had never created this spreadsheet, didn’t even know what it should include, and needed the flexibility of this organization. Instead of treating the analysis, design, coding, and testing elements of the project as separate, distinct categories, we should’ve done each throughout. This would’ve improved the visibility of the project for me and our client, alerted us to issues with the spreadsheet early on, and provided enough time to go back and fix them. Instead of one big failure at the end with waterfall, we could’ve had a few small failures with agile and produced a viable product at the end.

This means that early on I should’ve asked my teammate to try and link the data for one county and show me the spreadsheet in action. Then I could’ve asked questions and showed this output to the client. Feedback from the client and me would’ve helped us better understand the spreadsheet and better tailor it to the client. This is similar to the idea of creating a Minimum Viable Product from The Lean Startup. It reduces risk and would’ve left us room for small failures in order to get a big return.

Early on, I also should’ve also tried to bridge the gap between “policymaker” and implementer. I had created a plan, but I needed to talk to my teammate that was actually creating the spreadsheet to learn about our strategy. Yet, similar to the planners in the healthcare.gov project, I had zero interest in learning the details of the spreadsheet. I had an idea, I assumed it was infallible, and I wanted my teammate to just create my vision without any growing pains or failure. This means I needed to ask about the steps involved to make this spreadsheet. I needed to know the nitty gritty details, the designer’s thought process, and have the know-how to try and help my teammate streamline our service. Instead, I remained closed off.

Borrowing ideas from the Digital Services Playbook, I also should’ve thought about functionality of this spreadsheet for our actual client. Important things I ignored: addressing the whole user experience (not just possible numbers the sheet could pump out) and focusing on simplicity. By thinking about these details early on in the process, I could’ve intelligently critiqued the projects progress throughout. For example, if I didn’t immediately understand how to run the data through the system or what the output meant, how could our clients? I should’ve asked these questions early and often. Even when I did at the end of the project, I should’ve known that my confusion would me mirrored by our clients. Instead, I kept marching down the path of making an unusable finished product.

There were many other issues beyond these that I should’ve addressed earlier, and it’s so easy to look back and critique. But it is challenging to address these issues in the moment. Here are a few things that I think may hurt me from implementing agile, flexible projects in the future:

1. My comfort with hierarchy
2. Fear of looking unintelligent
3. Lack of empathy/vision about client needs
4. Thinking my vision is a reality rather than a hypothesis

These are real issues, but I can fight these urges throughout the project. One guiding principle that will drive me is that these project plans are actually project “hypotheses” that can change. This flexible mindset will allow me to focus on these others items:

1. Failure is important and makes our final product better
2. A focus on the client’s user experience and goals needs to be consistent throughout, even if it involves changing the plan
3. I can’t silo myself into either the policy or implementation side of projects – an understanding of both will help me greatly

The saving grace of this project is that it happened in a low-consequence environment. We were doing pro-bono work for a nonprofit – they were just happy we were doing anything for them. Yet, I know that a large failure like this can be very costly in the real world. It’s just important that I apply these lessons to future projects and environments where large failures will be more damaging. At least they appreciated our work! 

Our project team at the final presentation