How often does an engineering project you’re overseeing finish on time?
Delays have become a basic expectation in software development, but they’re not inevitable.
Here are the top three reasons why software engineering projects are delayed, along with steps non-engineers can take to address them.
1. Overpromising, Underdelivering
In my engineering past, I frequently made promises I couldn’t deliver. Take a feature I worked on at Twitter, which helped Taylor Swift see what her followers were talking about:
I was so excited to help T Swift that I didn’t spend any time planning. I figured I could finish in two weeks, which made my PM very happy. By the time I realized how hard it was to process tweets for 30 million followers, the deadline had already passed.
Two months later I was still responding to messages with “almost done”.
Engineers often underestimate work for a project, and usually it’s because we didn’t think hard enough before starting.
Much has been written about how engineers can better estimate scope of work, but most strategies are just roundabout ways of getting engineers to think more.
Here are some simple ways non-engineers can help engineers think more and estimate better.
Go for “no”.
When planning, try to hear a “no” first, before compromising on a “yes”. If you hear a yes right away, your engineer hasn’t had time to think. Here is planning conversation I should have had with my PM about the Taylor Swift feature.
PM: “Taylor wants this feature before March 1st”Me: “It will take until at least June and we can only process 1% of her followers”
*I said no. Great success.*
PM: “Ok, how can we make these features easier and faster?”
Plan cross-functionally
An hour of PMs asking questions to engineers goes a long way. For the feature above, questions like “Are there any privacy issues for Taylors followers?” or “Where will we store the processed data?” would have surfaced the issues that later caused delays.Give time for spikes
For larger projects (those lasting more than 2 weeks), allow a day or two for an engineer to “spike,” or research a task. Before starting on Taylor’s feature I could have spent a day working on the challenging parts, for instance getting all her followers tweet, without worrying about the UI. The code from the spike wouldn’t have made it into the final feature, but it would have helped me be more realistic when planning.
2. Changing Requirements
No matter how well you plan, if the requirements for a project change, the deadline will be affected. Here are some tips for avoiding requirement changes.
Separate business requirements, product requirements, and technical requirements
A business requirement is “Acquire 10k new customers by June.” These rarely change.
A product requirement is “Shorten the onboarding flow.” These change fairly often.
A technical requirement is “Use MySql DB.” These are constantly evolving.
By separating requirements you make it easier to adjust estimates without re-planning the whole project. Static, higher-level requirements act as anchors for the project.Resist scope creep
Modifying or replacing existing requirements is inevitable, but adding on new requirements is not. Users rarely want MORE features than you expected. More information should lead to a narrowing of product and technical scope, not an expansion.
3. Finishing is hard
It’s often said “The final 10% of a project is as hard as the first 90%.”
As a project nears completion, you will begin to see the difference between what you have and what you want. You will find yourself thinking: “It would be really nice if this button flew in from the right."
But the reality is, you probably don’t need that.
Apps and ballet dancers are similar in this way. Becoming a professional ballet dancer is really hard. Even after training for twenty years you’re still likely to fail most professional auditions.
But those ballet dancers who do fail an audition are still incredible. 99.9% of ballet patrons won’t be able to tell the difference between a star and the dancer who failed the audition.
Most products will have a small percentage of customers who are vocal about their high standards. This is good. Their passion can inspire you. But don’t let the perfectionism of your most ardent customers delay features for everyone else!
Conclusion
Non-engineers often feel helpless working with engineers. They expect that projects won’t finish on time, but don’t feel that there is anything they can do to make work more predictable.
Engineering delays are ubiquitous, but not inevitable, and there’s a lot everyone can do to help. Helping engineers process a task before starting, maintaining stable requirements while the project is ongoing, and resisting perfectionism at a project’s finish are simple ways we can keep things on track, even if we aren’t the ones writing code.
This article, like most our pieces, was written in response to queries from readers! If you have a topic you’d like us to write about, leave a comment or send us a note.
Big thanks to the Foster members who gave feedback on this post: Kushaan Shah, David Burt, and Tom White.