16 September 2014
Learning From Failure: What We Do When a Client Project Goes Wrong
At Gaslight, transparency is baked into the company. It means that we share the messy, sticky parts of running a software design and development shop right alongside the success stories.
Last week an app design and development project ended early because we were unable to identify a successful path forward with the client. After this disappointing turn of events, we held an internal project retrospective, and we wanted to share our process for learning from failure.
This retrospective meeting was open to anyone in the company, and Gaslight co-founder Doug Alcorn led us through a two-hour session with this agenda:
- Set the stage (5 minutes)
- Gather data (40 minutes)
- Generate insights (25 minutes)
- Decide what to do (20 minutes)
- Close (10 minutes)
Doug kicked off the meeting by reviewing some of our core company values – collaboration, trust, empathy, growth and accountability. This first five minutes also set two overarching goals for the meeting: Continuous improvement and thinking about how we can improve our relationships with customers.
Next the meeting moved into the gathering data phase. Doug invited everyone to write down project steps and milestones from the roughly 16-week project then arrange them on the wall in a rough timeline. We wanted to discover the project’s facts and create a shared truth of what happened.
A few things became clear as Post-it notes went up on the wall. There were a number of team changes, both on our side and the client’s, throughout the project. Frustrations and doubts started during the sales process and continued to grow as actual work moved forward. Different people in the room had different ideas about what we actually set out to accomplish for the client.
These observations moved us right into the generate insights phase of the meeting. Roughly six things came to light as the discussion became more emotional:
1. Turnover: This project experienced many more team changes than our typical client project, and this probably made a difficult situation more challenging.
2. Jekyll vs. Hyde syndrome: In meetings with the client, the Gaslight team always felt support for their ideas and suggestions. But the next day the process and approach went back to same-old, same-old as if the meeting never happened. Communication was strained.
3. Churning tech tools: The architecture changed in the middle of the project, and there seemed to be a never-ending parade of trendy tech tools and plugins.
4. Poor product ownership: It wasn’t entirely clear who owned the product on the client side, and we didn’t meet one key decision maker until late in the game. We should have pushed to identify this person earlier.
5. Lack of milestones: There didn’t seem to be a clear set of project milestones or many metrics to define success. We didn’t push for clarity on the vision or objective when we started the project. That left us floundering and we couldn’t tell when we were off-target.
6. Lack of leadership: We know how to execute projects, but we let the client treat us like a straight development shop. Our sweet spot is in leading projects end-to-end, and we missed by playing the staff augmentation role in the beginning and then playing it too long.
From there, we moved into the “decide what to do” agenda item, and it was probably the most stressful part of the meeting. We talked about several points in the project where we met with the client to try and put things on a healthier path. People questioned if we did our due diligence in the sales process or if we short-changed our own discovery process in the first few weeks of the project.
The most valuable discussion probably revolved around fears. Were we afraid of turning down work with a high profile client? Would there be work to fill the gap if we did? Did some people on the project not speak up due to imposter syndrome? Worrying they were doing a bad job vs. there being intrinsic problems with the project? Were we going deep enough with our consulting? Beyond tech issues?
None of these questions have easy answers, but at the end of the meeting, we agreed to think on the discussion and revisit next steps. The meeting wasn’t perfect, but there was a shared understanding that we were there to learn how to do better next time–not scapegoat one or two people for the project’s failure. We believe trust and transparency are critical to doing great work.
