Think through how much off-the-shelf opportunities exist to satisfy your dependencies.
But also remember there’s no free lunch: integrating outside resources can still be costly.
4.
Estimate how much time it will take to satisfy your dependencies—then multiplySoftware development time estimates are comically error-prone.
But if you price the estimation risk into your estimate, you can earn yourself some breathing room.
There will be bugs that keep coming back.
There will be surprises as you integrate third-party tools and content.
There will be tasks which seemed easy at the outset, but whose implementation reveals a raft of additional complexity.
That’s life in the software business.
As you create an inventory of your dependencies and the time you estimate they’ll need to cook, multiply by 2.
5.
Maybe that seems excessive.
But it’s a concession to the fact that our frail meat brains are bad at storing and modeling the total complexity of a software system.
When you made your initial guess, you were quite possibly ignoring more than half the picture.
Price that limited perspective into your final guess.
Or don’t.
It’s your ship.
You can use whatever multiple you feel comfortable with here.
Long experience tells me that for my estimates, though, I usually want 2.
5x.
Don’t forget time for testing your project ahead of ship.
I can’t tell you how long this will take, since different environments have different constraints.
If you’re shipping native code to for approval in the iOS App Store, for example, you’ll want to do much more thorough testing than if you’re shipping a web app you can update at-will.
You’ll also want to budget time to make fixes based on what you learn in the QA process.
5.
Add up your time estimates and compare the timeline to your ship dateIf you’re very lucky, your time estimate and your ship date mesh perfectly.
But you’re probably not lucky.
You’re working with software, and software delights in thwarting our optimism.
What if your requirements push far past the ship date?You’re going to be tempted to manipulate the estimates.
Don’t do this.
There’s a reason we estimate in pieces and add things up, rather than working backwards from the ship date.
In this process, here are all the things we’ve considered in order from most real to least real:The dependencies for our desired featuresThe minimally-viable feature setThe time estimatesThe ship dateThe ship date is the least real thing we’re dealing with!.Don’t let it drive.
That said, if you absolutely must treat the ship date as a hard constraint, we have options.
None of them include goosing the estimates.
6.
Make hard choices: trim scope or move the ship dateI know.
You want a pony.
????????But now you know what the pony costs.
You’re going to ship the pony 18 months later than you would have liked.
Are you going to have enough money to survive for that extra 18 months?.Will you give up an important competitive advantage by taking that extra 18 months?.Are you okay waiting 18 extra months before getting feedback from customers about whether you’re even on the right track?Maybe you’re fine moving the ship date.
Sometimes that’s the right call.
But often times, this is the point in the exercise where you take out your knife and start trimming scope.
Maybe you’re not going to ship a pony.
Maybe it’s time to ship a bicycle instead.
With the knowledge of the time and money cost of your minimally-viable feature set, maybe you can find inspiration to pare down even more.
Trim scope until your estimates for the remaining work—which you have not goosed—give you a few days of margin under your ship date.
Now you can get to work, having a clear idea of what’s worth prioritizing and what can wait.
You can repeat this process whenever you feel your project getting off-track or losing steam.
It helps me to track my requirements and dependencies on something tactile, like notecards or sticky notes, but you can document the process you’ve gone through using whatever systems make sense for you and your team.
But Danilo, this isn’t the agile/scrum/[cargo cult methodology] way!Whatever, man.
I’m sure it isn’t.
This is the way I know to get a project out the door on a date agreed upon by all parties, with scope documented for all parties, with tradeoffs understood by all parties.
Within that, I’ve seen it work alongside tools like sprints, planning meetings, standups, and retrospectives.
I really like doing all of those.
If you have existing systems you like to use to communicate and collaborate, you can keep them.
But you need a way to understand the relationship between costs, scope and outcomes, and to communicate those constraints across all functions.
This is the basic approach I’ve long used for that.
I hope it’s helpful in your adventures.
I love building software, but I love supporting people’s growth even more.
If you want to hire me for your tough engineering management challenges, get in touch.
Further reading:1.
0 by Rands: “Shipping a 1.
0 product isn’t going to kill you, but it will try.
”.