I went through a horrible project experience at SPARK.
We had an exciting software project for a high-profile client – a well-crafted roadmap with a solid return on investment. From the beginning, we knew that a successful project with this client could lead to another great SPARK case study.
But, when the project was about to go live, after 6 months of development, we discovered a MAJOR stakeholder requirement had changed. Adding this requirement at the end– although small if discovered during month 1 of the project– was now significant and it cost us the go-live date.
Even worse than missing the launch date was that SPARK disappointed our client and our client then disappointed their own customers. Words can’t quite describe how frustrating of an experience it was for all involved.
I’m not writing about this experience to rant. I want this to be read by future clients and SPARK teammates who build amazing products. I want this story to be a lesson learned on how things can go so well…until they don’t.
Here’s how it happened (and how we can avoid it in the future).
Everything starts well in the beginning:
Like every project at SPARK, we kicked things off with an Assessment phase where we meet with the client’s key stakeholders and discuss features that align to their needs.
This first phase is always an exciting time for the client and our team; Ideas are flowing and you can start to visualize the future system or tool.
Next, we delivered designs, scope definition, and system architecture, followed by a cost and time estimate to fully develop the tool.
At this point, everyone is full of energy saying, “this is going to be beautiful, let’s go!”
It’s a lot like that feeling at the beginning of a family road trip. You know your destination, bags are packed, and you can’t help but feel a bit giddy about it.
Then, we start building it:
Once we start coding a new system or tool, there’s typically not much to show the client for weeks or even months. Developers are heads down building one feature at a time.
(Hint: It’s during this middle part of the journey that projects can take a wrong turn, without teams even realizing it.)
And if you don’t understand languages like C#, PHP or Vue.js, it’s hard to gauge progress and what’s been accomplished. So once a user interface is ready, our project manager is thrilled to FINALLY reveal to the client something concrete (and more than just an invoice).
We show off a screen or two of the product, but sometimes the client’s first reaction isn’t always what we expect. They say, “This doesn’t look right” or “I thought it would do this.”
Okay, not a big problem. Our team makes a few adjustments. In most cases, clients ‘trust’ us to get it right by the end.
A few more months go by. Then we’re ready for user acceptance testing. We can’t wait for the client to see our work and interact with the working product!
The moment it all starts going wrong:
At the final checkpoint, a project can go one of two ways:
1. The client does a quick pass and says “looks great, let’s go.” When this happens, the team is stoked! We got it right the first time!
-OR-
2. The client goes in deep and realizes all the edge cases they forgot to mention during the stakeholder meetings in the beginning phases.
When a client starts down that second path, they start saying things like, “Wait, we need to get Stakeholder X to sign off.”
The problem? As you might guess, Stakeholder X’s needs have changed and we have to address it now.
Most of the time we have met with that Stakeholder at the beginning of the project. But now it has been 3, 6 or even 12 months later and we’re now learning of a new, sometimes major change.
The worst case scenario is that Stakeholder X was never involved at the beginning. And when they’re brought in so late in the game, there’s no telling what impact their needs can have on a project that is already 95% complete.
Now what?
There are X number of scope changes from the client, but $0 left in the budget.
This is a tough moment for everyone.
The client looks at us like “shouldn’t SPARK have known we needed these items?”. We look at the client and say “how did you not know you needed this”?
When this happens, you start asking yourself, “How could we have avoided this mess in the first place?”
Could we have budgeted more time for stakeholder alignment and planning in the first phase? Well, of course more planning is always better. But most clients won’t agree to that much additional work upfront. It seems like a budget buster and could rightfully add scope creep.
So here we are, both teams frustrated. The project excitement from the beginning is nowhere to be found. Nobody wins.
How did this particular story end?
Our team at SPARK dug in, worked an extra month (for free), and delivered the project late. After many apologies along the way, we launched the system…but without celebration.
Ultimately, it’s a beautiful product that saves our client hundreds of hours of work each month and is growing their business. However, the journey to get there wasn’t what any of us expected.
How do we avoid messes like this in the future?
As we all know, software projects take time. And along the way, stakeholder needs change more often than not. As their business moves forward over those months, their processes can change or new stakeholders brought on.
But software teams aren’t always aware of those changes, unless we ask. Again and again and again.
The main takeaway from this story: Software teams must have a continuous feedback loop throughout the entire project to ensure features align with user needs at the end.
How can you create that constant feedback loop?
1. Set the Right Expectations Early
During the project kick off, both SPARK and the client should understand that business needs will likely change before the end of the project. Ensure everyone that it’s okay for this to happen and establish a process to uncover these changes. You want all stakeholders to feel comfortable bringing things up early and confirming their needs as you go.
2. Gather Stakeholders Often Throughout the Project
Bring those stakeholders together several times throughout the project to confirm their needs. In addition, we end major meetings with a recap of what’s left in the project. This can help remind a stakeholder about a future phase that may be impacted by something outside of the project.
We also ask stakeholders to publicly acknowledge that their needs are the same as they were. This little extra bit of accountability can get someone’s attention if there’s a change to address.
3. Review the Entire Projects with New Stakeholders
If stakeholders do change (which, again, can happen) take the time to review the entire project with them. Go back through the sign off process to ensure you’re all on the same page. Sure it takes more time up front, but it’s worth it so that the project meets the needs of the business at the end.
Lastly, remember that even the best of teams can forget a feature or edge case during the planning phases of the project. Go into those final sprints knowing there will be changes.
Following these steps will lead to a better project experience and the chance to build something you and your client will be proud of.
