Maybe it’s time to review it with your team….
We’re currently experiencing significant pain with one of our software development projects. The effort of the project was to improve an e-commerce platform which Unosquare had previously built and has been maintaining for a few years now. Currently, the delivery of the promised features is past its estimated date of completion. The testing of the bug fixes have become contentious because of their effect on the client’s budget which is now overrun. The client is obviously upset about this and so are we.
Unfortunately, we are also in the position that the contingent actions we’ve take to provide strict oversight of the development and testing now involves the oversight of senior leadership from both sides. So, now we are accounting for sunk costs associated with the time we are taking to support remediation of the project’s problems.
It’s important to point out that we’ve had a healthy relationship with this client for many years. Despite the current challenges, we maintain candid and professional interactions as we are simply trying to finish this phase of the project. No one is pointing fingers, though the source of the problem was unclear for a while.
What happened?
An existing client, a merchant with a large, physical, retail presence needed their e-commerce platform (one that we helped to develop) to match the changing usability needs of their customer base. Their team approached the Unosquare engineer who had been working with them for over a year in a development maintenance role. The initial ask was to scope out and provide a roadmap for new features and enhancements to the platform. The result would be a an alignment of efforts from a team member intimately involved with the tech and business rules needed for successful delivery. For the record, applying local knowledge to an estimation of effort is something that we wholeheartedly support.
Once the estimate was completed, it was provided to the client. They felt that the timetable and costs were attractive and pulled the trigger on starting the development, we executed the work orders, and away we went with the team already in place. Little time was lost on on-boarding and project kick-offs which is of significant value.
Fast-forward to today; a project with a promised delivery date in November is still pending.
There were warning signs that things might become problematic, but I missed them because of the health of the existing relationship. The daily SCRUM calls were not happening. There was communication, but it was not following a defined project management process, let alone SCRUM ceremonies. Coupled with that, we were working off an estimated software project roadmap that both Unosquare and client took at face value, with little investigation into its validity. All effort aside, when risks appear during a project, the roadmap needs to be reviewed , and work items need prioritization among the team. These things weren’t happening, and we were still pending delivery and arguing over whom to blame for bug fixes and the cost of the development time.
Unosquare has a Client Services program in place to maintain the health of a project. The programs processes have proven to be effective time and again. However, our Client Services team, those charged with the responsibility to support project communication between the development team and the client, was hamstrung by the communication standards that had been in place for some time, which were none. Ultimately, it was only when the budget overran that people started paying attention.
The trust of a good relationship ultimately became the undoing of timely delivery. “Oh! That’s your estimate? Looks great! Let’s get going,” was not the right way to kick-off the engagement. We didn’t validate the roadmap and the requirements were vague. We did not clarify any of this effectively and, sadly, we started to realize this retrospectively. We dropped the ball on setting a good foundation for successful delivery and the client bypassed the organizational processes to get an estimate done quickly. Both sides are suffering, and that is rooted in poor planning and too many assumptions that were left unchecked.
No matter what the relationship with the client, the ceremonies of SCRUM and the basic tenants of work estimation and project management must always be followed. It’s vital when working with distributed teams that you stick to the process
This story isn’t all bad news, mind you. The communication is back on track after we enacted SCRUM ceremonies to “right the ship.” The work is getting done and being monitored effectively. We still have a healthy relationship with the client despite the challenges that we have experienced. There was trust that existed before these challenges began and maintaining an open line of communication has supported that confidence.
Takeaways:
Assume nothing when scoping out your Agile projects and make sure that your entire software development team and the client side, especially the Product Owner, are aligned on the job requirements and agile project roadmaps before the project work begins. Both sides need to stay in constant communication and I don’t think that I can stress this point enough. We advocate for our clients to have direct contact with their distributed teams members. However, just because that channel exists, doesn’t mean that it is being used. Stay “Agile” with your development and ruthlessly attentive to the health of the project at the same time by setting a cadence of effective communication with all project stakeholders.
