Sticking to a deadline

After reading the comments to my previous post, I have to agree that I may have seemed like I was underestimating the importance of finishing things. I do value the finishing act – which would actually be a great subject for a totally new essay. I’m not going down that path yet since I’d like to structure some thoughts on that subject beforehand.

Still, I decided to write on something that happened to me in a previous project I worked on.

The project

I was working on a small development project at the time, with a small team. Our goal was to deliver a template web application that could easily be re-used by power users for developing business web applications, yet was simple enough for any new user to pick up and try without feeling overwhelmed by it. This small project was part of a bigger project and as soon as this small project was finished, we’d both have other things to do in the master plan.

As such, this project was slated to be released “as soon as it could” but also “whenever it would satisfy the user requirements”. This meant that, even though the version had a strict deadline, this particular project didn’t have one at start – it should be released by the version release date, but preferably before. Since part of the project would consist of gathering an accurate requirement list, it would be up to us to assess what features and requirements would need to be fulfilled in order for the application to be in a deliverable state.

After gathering the initial requirement list, an estimated deadline was proposed, and we started working. After a first couple of weeks into the project, we had the chance of having some beta users willing to develop an application based on our template.

The reviews

As it turned out, this first version we were aiming for was overly complex to re-use. There were too many things one needed to change, and most of the screens were so over-complete they were like giant Swiss-army knives: some of the template content was bound to be deleted depending on the specificity of the final screen. Oh, and God forbid someone wanting to create something that would deviate a bit more from any of the existing screen templates! It was something comparable to the experience of tightening a screw with a ballpoint pen.

Back to the drawing board we went, and this time, we simplified things the best we could. We even removed some of the initial restrictions and assumptions in the name of simplicity. It was not without its’ flaws, but it was better than before. Sure enough, this step backwards was not in our initial budget, so the budget stretched a bit. It would mean that we wouldn’t be able to join other projects on the initially planned date, but it was needed, and we were on track again.

Weeks later, on a second user review, we were pointed out that, even though it seemed simple enough (from a regular user’s point of view) to use and re-use, the fact was that almost no one would be able to use the templates without needing to customize them: even though we had a generic data retrieve and list page, for instance, some users would need page navigation through the data, others would want filters to reduce the search scope, while a few would like to able to sort the data. These were all valid reasons – we were trying to provide templates so that other developers would not need to create these things from scratch.

No size fits all

Another slight budget re-adjustment and a couple of weeks later we were closing in on the deadline. The ever-increasing backlog now consisted of bug fixes, simplifications we could still apply to some screens, and a couple of problems that kept being pointed out by the users. The main problem was that power users demanded more variety and composition of screen templates (such as a screen with an input form followed by a data list, for example), though each user had specific needs for different compositions, while other users were already defending that the application consisted of way too many different screen templates, that they would not use half of them.

Both sides were true, and had valid arguments. We could not settle for any of them without harming the other party, and we were not keen on adjusting the budget once more. As such, we stuck to the deadline: we committed on a requirement set that needed to be fulfilled, we fixed the bugs as best as we could, we stabilized the code so that – should something bad happen – we’d have something to deliver on time, and until the closing date we added one or more small features – mostly cosmetic or trimming edges – to the application that would add value without compromising it’s stability.

And that was it. Sure, the application wasn’t perfect. It was definitely not the “one size fits all” we had imagined at the beginning, but it was good enough for some purposes. More importantly, though, the fact that it was released meant that the application was now public, and more users could use it to help them develop their own applications. And while they were at it, we could actually gather more feedback that’ll help us decide what to include in subsequent versions. It was a win-win situation – even if it was not a resounding win for either side.

If we had not done that, we’d kept going on week after week adding features that would never end, and we would have settled on an up-to-date requirement list by fatigue – or had just become another Duke Nukem Forever-like project.

Conclusion

As I’m sure most of you already know this from experience, the “deliverable state” of a project is almost never objective. Parkinson’s Law- work expands so as to fill the time available for its completion – is a well known reality in every development project, be it because of unexpected difficulties, ever-increasing requirements, an Utopian strive for 100% perfection, or any other reason you might think of. And one way to minimize it is actually to be able to judge when to stick to and when to increase the project’s budget – provided that that’s an option.

Bear in mind, though, that I’m not defending that you should not push the deadline once more if the project’s result is broken, or clearly incomplete! It is never too late in a project to correct a bad decision, no matter how much time it will take and how early in the project it was decided. What I’m saying is that if the product is in a state that already fulfills the requirements, and that the product as it is will already solve some problems for the users, then odds are that you are better off releasing it, instead of postponing it ad eternum. Face it: the backlog will never stop increasing – unless no one is using the product. From bug reports to feature requests, you’ll have a lifetime of product management ahead. And you can always – and should – release those bug fixes and feature enhancements in new product versions, especially if there’s perceived added value in them.

P.S. – I’m pretty sure I’ve oversimplified some of the topics I used to fundament my arguments, and I’m aware that I may have seemed naïvely optimistic in some cases, namely the “win-win situation” description for our particular scenario. There are some other fundamental aspects such as the importance of the product’s first impression on the user; I purposedly disregarded them for the sake of making a point on limiting the project’s scope in order to keep on track with a deadline, as I feel they’ll only add complexity and not that much insight. I’ll dedicate a future post to the impact that a first impression has on a product’s – and company’s – image.

P.P.S. – Recently I read a couple of articles on simplicity, and on the fact that our initial approaches to the problem focused either on flexibility or on simplicity. We were only able to start seeking both after a couple of user reviews.

Explore posts in the same categories: Management, Technology