An Estimate Is Not a Deadline

I had a few meetings over the last few weeks that were focused on tight deadlines. Two of the clients were burned by other agencies who didn’t deliver so they were already behind schedule and wanted the projects done ASAP. Or even – much faster than ASAP.

The Estimate Factor

I’ve shared my thoughts on the risks of estimating a project before and I’m quite careful when I do the initial discovery meetings and R&D. Especially for larger projects or migrating existing custom platforms built many years ago with tons of features and integrations with various services.

Doing the right estimation is tough. There is always a certain percentage of risk involved there – missing an important bit, or being dependent on communication and other services that require approval or additional things to build in order to get in.

There is a great quote on estimating the work based on initial research and some mockups in the architecture world, which is just as applicable in our WordPress field:

We cannot afford to wild guess whenever we don’t have all the data. The more important a project is – especially existing popular platforms that have to be migrated – the more challenges we will have to tackle, and the better informed we must be in order to proceed further.

Building a Team

We tend to build different teams for our projects. Some include a frontend guy and two developers, others – several programmers, a system administrator and a dedicated project manager. Whenever the scope is 500 hours and more, we break the work into pieces which allows us to be more effective and deliver faster.

For example, building an LMS with a virtual classroom requires a new WordPress website, setting up an LMS platform or building a custom one, integrating a third-party class room solution such as BigBlueButton, crafting a nice design, manage the payment gateways and so forth. This could easily be delegated to several people – a sysadmin setting up a separate Ruby stack for BBB, few developers working on different aspects of the WordPress user management, capabilities, various post types, a designer to create the design and another frontend guy who can turn it into a decent theme.

But there are modules that can be handled by a single developer.

The beautify of VCS is that a team can work together on a project, without overriding each other’s work. You can even work on separate functions in a file and this would be merged behind the scenes by SVN, Git or Mercurial. Which is fairly neat.

But if you’re building a payment gateway, a complicated migration script or a bank security mod, delegating several experts on the same module may be ineffective. Code review is more than necessary, but mixing up several different coding styles, not using the generic libraries and helper classes and missing different internal policies from each developer would slow down the work. The end deliverable will likely be unstable, the time put into work would be more, and the delivery date will not move sooner just because we split an essential and independent component.

Challenges With The Corporate World

Which is why we often refuse to work on a single essential component under pressure. It could be due to the specifics of the module that we are building, or due to the quality standards from our customer.

Our technical team at DevriX has built several solutions for a few banks in Europe. Some of those projects were related to custom payment gateways or financial calculators, and we were often authorized to use internal documents or scripts of the highest degree.

In order to make sure that everything is in tact and triple check every single aspect, the percentage of communication is much higher than the work itself. Getting approval from several decision makers and a complex corporate hierarchy takes forever, and validating some of the internal processes is also a serious challenge.

We were approached by another bank for building a payment integration for them. We’ve established the management and communication process and the workflow, and we had access to everything we needed in order to make it work. But they expected the final product in two weeks.

After assessing the time for communication, technical setup, development, QA and more, we have estimated at least a few weeks extra. There is a 10% chance to make it work in time, but risking one’s reputation against the definitive numbers was not worth it, at all.

Our Estimate Is Not a Deadline

If we have estimated 6 months of work for a project and the expected launch date is in 45 days, it’s likely not going to work. Even if we pull all-nighters, add a few more team members and pray all the gods out there, the chances are minimal. On the other hand, it’s likely that the code quality will be affected drastically, and so is the team morale, the pressure during the scrum meetings and the overall chance that we will make it in time.

It’s often tempting to add a large corporation to your portfolio, but is it worth the risk? Would you put your reputation on the line when everything else tells you that it’s a gamble?

One of our other large clients expected us to double the team for a component and make it work in three weeks. After arguing over the course of a few emails and calls, my response was the following:

It’s as if you put two people in a car, ask both of them to step on the accelerator and expect the car to arrive twice as fast. Or even try that with two more people and cut the deadline in half.

There are certain tasks that could easily be distributed. If you have a hundred boxes and want to move them from room A to room B, you can hire 100 guys and make that work in no time. But hiring more lawyers won’t make improve the chances for a lawsuit. Asking for several surgeons operating on you will not make them work better and fix you faster. The same analogy is very well applicable when you have a goal of significant importance, want it done the best way possible, but still expect to squeeze the deadline.

Some clients agree with that sentiment. Others usually turn to gambling, relying on a risky estimate that often fails and they either end up completing their project much later than expected, or reach out to us with our initial estimate.