Suppose you’re like me and you’ve 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 of these 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 which foregoes what you consider to be fundamental pieces of a product (or service) to keep a manager off your case. And in fairness to project & people managers, they also have a job to do: put it simply, they are responsible for delivering and 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? Dealing in innovation is broadly trial and error. You iterate, find the problems, fix and start over. Each time you get closer to a workable product that satisfies the requirements 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 some 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 project which is loosely connected? 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 & quaility outweigh the desire to be on time and 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 attempt to mitigate the risk of the company becoming the next top story on ITNews. Tech which 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
