If you’re like me and have worked in project-driven organisations, you’ve presumably been caught in the trade-off between time, budget, quality, and scope. You may feel pressured to compromise on one or more factors to meet project deadlines and stay within budget.

Balancing these factors can be a delicate process.

You may be requested to work on something that foregoes what you consider fundamental pieces of a product (or service) to make our managers and project managers happy. In fairness to project and people managers, they also have a job: put simply, they are responsible for delivering. They may be disincentivised for missing deadlines and not producing the expected outcome.

In the past, teams I’ve worked in have attempted to deliver groundbreaking products that aim to automate, streamline and improve many elements of a company’s IT stack. These products seek to limit the continual re-invention of “the wheel” and establish foundations that can be sustainably leveraged by multiple teams across an organisation.

One challenge I’ve encountered is estimating work when operating new technologies. How do you consistently assess the size of something when doing it for the first time?  Innovation involves trial and error. You iterate, find problems, fix them, and start over. Each time, you get closer to a workable product that satisfies the requirements of the business stakeholders, your colleagues, or your manager.

How do you accurately estimate when you’re learning and don’t yet know what you’re doing?

You may not have many answers, but you’ve got a solid vision! You understand the problem, but no instruction manual describes how to make it work? You are pioneering something entirely new, where everyone has an opinion… Still, like you, no one else has walked the path. Everybody is on a steep learning curve. Estimation turns into a bunch of opinions, all of which are mostly wrong.

This puts an engineer in a challenging position. Do you overestimate and hope things fall within a workable window where the PM accepts the assessment? Do you underestimate and find alternative ways to progress? Do you work extra hours or on the weekends? Do you outsource your work to business-as-usual (BAU) teams? Do you tie your work to another loosely connected project? Do you cut scope? Drop the quality or sacrifice security, compliance, or audit to meet your KPIs?

I’ve been playing with this question and conclude that when building something new, scope and quality outweigh the desire to be on time and on budget. Okay, I said it, time and money aren’t everything!
I’ve often worked in teams that are working on BIG TICKET items and with new technologies that seek to mitigate the risk of the company becoming the next top story on ITNews. Tech that will eventually improve speed to market, automate all the things, or set a company up for a challenging situational landscape, such as heavy regulation or compliance.

Good things take time. Patience is a significant factor in being successful. 

Having come to this conclusion, I still believe it’s vital to work with urgency, communicate and try your utmost to minimise any potential time and cost impact, but innovation is difficult.

A half-baked creation is broken and will assumably not deliver the expected value. A half-baked creation is unlikely to gain user adoption. A half-baked creation is frustrating for most.

Anyways, I hope you enjoyed my observation on estimating when dealing in innovation. If you’ve got ideas or thoughts on the matter, comment below! Stay tuned for more of these posts in the future. 

Scott