The last grain of sand fell, and with it I too looked forward to resting, albeit in defiance of the rising sun. While I had welcomed the new rays of light spreading across the empty parking lot the day before, I now cringed at the sight as though I was hearing some painfully true accusation of wrongdoing from a good friend. And yet, thinking good progress had been made, I knew nothing of the trail by coding that I would experience even after that 24 hour warm up session.
That 24 hour session, sun rise to sun rise, was actually day 2 of the coding ordeal that would drag on for 4 weeks, but the story begins a couple months earlier. I had flown to London with the President of my company to gather business requirements for the 3rd and latest iteration of deploying and upgrading our software for our biggest client (a Fortune 100 company). Our flagship product, which they used along with a couple others we’d written for them, is customized compensation software covering the focal review process (Human Resources – budgets, raises, bonuses, stock options mixed with international currencies, taxes, and other headaches).
We were beginning our 3rd year working together, and while we’d had good experiences with them before, we were in an awkward position this time as they weren’t able to begin this process the month before as we would have preferred (we stay in contact year round, even though we only go through this initial process once a year). They were going through possible acquisition dealings with a few other large companies, and didn’t have the time to deal with this next iteration of updates because they didn’t really know what they wanted/needed thanks to their constantly changing environment. Additionally, because our software was uniquely the most encompassing of any software they had on certain financial aspects of their company, they were trying to use it in a way that it hadn’t been intended, which was as a primary reporting and strategic decision tool in this merger & acquisition process.
Now, we usually have a general idea when clients want to start their focal review process before we start talks. This obviously helps us determine when we should start the next round, so we can be sure that we start a reasonable amount of time ahead of that based on any changes they request (and there are almost always changes). The client’s official start date (our go live date for the new updates) isn’t usually determined until after we’ve already begun, and even then, it’s usually flexible within reason, but we have some room to play with given their needs. However, this time, with this client, not only could we not start when we would have preferred, but they also set the go live date before we started this process as well as set a number of near non-negotiable change requirements and product enhancements.
We were more than happy to work with them, and you’re usually in a great place if your clients are knocking at your door with a big problem that only you can solve, so we were a little anxious, but confidence we could do whatever was needed. The President, my London counterpart, and myself did our best to trim back their demands to their core, truly necessary requirements. Surprisingly, this didn’t include much change to the primary product, but mostly consisted of changes to peripheral applications that supported the main one, but are included as a part of the whole package.
This was because they were as much, if not more interested in the reporting and strategic decision making functions as they related to the on going M&A process as compared to their interest in improving the standard focal review process. But don’t be fooled, they still required a fundamental alteration to the primary application. So, one change instead of many, but a big one that they couldn’t do without as it tied together the whole package, and gave them some newly required flexibility along with the additional functionality.
From this week long meeting, we came out with a timeline for development and User Acceptable Testing (deploying the application for go live at the end of the UAT). Because of the many large changes and the short time we had to define all of them, we had to finish without completely understanding the requirements (both us and them had a lack of understanding). This is OK when everyone is on board (clients definitely included), and if everyone understands that you’ll be going through an iterative process that unfolds as you make progress, meaning that you redefine or update the requirements as things come up.
I don’t usually have a problem with this because at any scale of development (small or large), I believe that iterative development is the only right way to work. Projects, like life, change dramatically as you’re going through them (in reality the much acclaimed – when it was “invented” at least – Software Development Life Cycle (SDLC), aka the Waterfall Process, is actually crap, although good to know). Many times because you can’t really understand the situation until you’re in the middle of it with your hands dirty. It’s usually only after the 3rd or 4th time doing something that you can start generalizing, but even then, you’ll inevitably encounter lots of new, important, and unexpected challenges if you’re always pushing for better.
However, this iterative process and the communication and relationships required for success turned out to be a problem for us later on down the road. Not because of inexperience on either side as this is how we work and have worked with clients – this one included. They’ve experienced this kind of development process, and they prefer it having worked with us like this, which is probably half the reason they waited so long to have this business requirements meeting as they were more than comfortable with our ability to adapt and adjust to critical changes.
Making iterative development work, though, requires that both sides remain friendly and understanding throughout the whole process or it falls apart. Not that things became nasty, but myself and others felt a little betrayed at one point by the near reversal of attitudes on what had been agreed to, and how we had agreed to accomplish the large number of developing requirements (I’m sure I’ll bring this up in more detail in the following posts).
Before I get to that, though, everything looked good. Everyone was confident, although a little nervous perhaps, yet happy with the definitions and understanding we’d come out with. And really, there’s only one big mistake that could have been avoided at this point. That one big mistake, or risk we’d thought reasonable at the time, is what caused my trial by coding.