Project delays: why good software estimates are impossible
chrismm.com
chrismm.com
Software estimation is required for real business to ever consider software projects. The key is to embrace uncertainty, and instead of estimating that task X will take exactly Y days, estimate a range of possibilities. I like the three point system, estimating a best case, worst case, and most likely case. It explicitly asks you to think about the long tail for when things go wrong. Then use statistical methods to combine estimates and create estimates for multiple confidence levels.
This is all covered in a great book, "Software Estimation: Demystifying the Black Art" (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). It's not that long a read, and it goes over the problems covered by this blog post but doesn't throw it's hands up in the air and say estimation is impossible.
Because the benefits of the software project would far outweigh the benefits of a new store? With the completion of the software project you could open an order of magnitude more stores? Completion of the software project will increase the profitability of existing stores such that they make more than a new store at existing (hypothetical, since the store is not open yet) profitability?
If opening a store takes 6-9 months, and we have a software project that can make all of my 100 stores ~10% more efficient that needs 2-4 years, then the software project looks a lot more feasible! (ignoring that calendar time is not exactly cost, and that we may need shorter term wins to stay in business)
The problem is if, when asked for an estimate, we say "I don't know and I never will know until I'm done". Now I don't know if stores will be more efficient 2 weeks or 20 years from now.
How can you estimate something that isn't done? You can throw some words out there, but they are likely meaningless.
If you are operating solely on predictive ROI, then maybe investing in ambitious software projects is not for your business.
>Now I don't know if stores will be more efficient 2 weeks or 20 years from now.
That is your problem, not the software's or of the people creating the software.
Maybe because you're trying to innovate? Will opening a new store dramatically change your company's market outlook? Will it open up entirely new markets for products you don't yet have? Will it solve new problems for people?
Milton Hershey offered his first chocolate bar in 1900. It took him a further five years to perfect the manufacturing processes that produced the Hershey's Kiss. None of those processes, and none of the machinery to execute them existed when he started. He had to invent them.
Today, 110 or so years later, the company produces around 60 million of them a day which it ships all over the world. Probably he should have just opened another store.
No offense, but people who think the way you do about risk are exactly the reason large companies lose their ability to innovate at all.
> No offense, but people who think the way you do about risk are exactly the reason large companies lose their ability to innovate at all.
Exactly. This is why the startup ecosystem continues to thrive even after the age of the big IPO is over. Startups are akin to R&D for larger companies who don't want to (or can't) take the risk to try something new.
Even if what you are doing is truly research that is completely open ended, there still have to be controls placed on it. Budget/grants/runway will run out at some point.
What are these rigorous techniques you speak of? I seriously, honestly want to know.
It's "Software Estimation: Demystifying the Black Art" by Steve McConnell (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). Same author as "Code Complete" and "Rapid Development", which are also great books but much longer and showing their age a little more.
Second, in estimation, previous performance is often indicative of future performance. If something took you X days before, it will likely take you roughly X days next year. It's not likely to take 10X the time. The real problem is that very few teams actually track their time on task accurately so no one on the team knows what X was. Without that data, trying to get accurate estimates is a waste of time.
A very large part of the problem is that most developers are educated in Computer Science or other areas and simply haven't been trained in estimation techniques. Software Engineering is about the process side of development, and one of the benefits of process is predictability.
Managers, for the most part, keep saying that. Usually its because they have, or they've read about someone who has estimated accurately one or more times. How do I know they were not simply lucky? We cannot accurately estimate the time it will take to construct a building, and we've been constructing buildings for thousands of years.
Producing movies, for example. Even if you cast established actors and limit yourself to low-risk sequels of successful franchises, chances of box office bomb are substantial. Book publishing would be even better example; thankfully, writing a book is dirt cheap comparing to developing software or making movies. Pharmaceutic research is absolutely unpredictable — but big pharma companies are usually quite profitable, like software companies (their research/production patterns are similar).
New software development is _always_ innovation (because, if your problem is already solved by existing software, it is way cheaper to buy this software instead — as cost of production is close to zero compared to the cost of development). Innovation is _always_ unpredictable. Building the business on innovation is therefore a hard problem.
Producing a movie isn't rocket science either. But if anything it's more complex than most software projects, because you have to arrange the finance, hire hundreds of people spread across tens of teams, move people and stuff around, design and build things, knock things down, add a lot of stuff in post - which may need custom software - and so on.
And that's just the footage. You also have to market and distribute the movie worldwide, work out deals for residuals on various media, and so on.
And everyone has to be paid on time, near as, or work stops.
Estimating profit is a completely different job, unrelated to keeping the machine running from start to finish. It's barely a footnote. Studios are mostly not bad at it, but they do sometimes get it very wrong.
Designing a CRUD website that scales is nowhere close in terms of complexity.
But here's an interesting thing: movies only get finished because there's a hierarchy of talent and delegation. The director/producer can hire an expert or a ready-made team to handle part of the project, and delegate that entire element to them. From then on the producer/director needs to do some oversight, but the details (should) "just work."
Startups don't work like this. Startups hire everyone on a permanent contract basis, often as individuals, try to build them into teams internally, often on the basis that anyone sub-senior is pretty much interchangeable with everyone else at the same level, and generally delegation doesn't happen in the same way.
There's really no reason why teams of programmers couldn't get together, set up service companies, and hire themselves out as consultant solution providers. After a few successes a team should have it made.
This doesn't happen. I think that cultural difference is very interesting.
It is impossible to know for sure. It's a bet. It's also impossible to say precisely what the DOW will be at next Thursday. But you can make a guess with confidence intervals, long or short the appropriate index, and make some money.
The problem is that "real business" people want impossibly precise estimates for software projects in particular. If software estimates were more like medical prognoses or financial reports, they would include confidence intervals and risk assessments, and we would be having another conversation.
Just because you can't always have an accurate estimate doesn't mean it's now worth it.
Also remember that estimates are based on resources. We were able to go to the moon in a decade but a lot of work was done before and the budget to get there was much higher than what most software development efforts ever get relatively speaking. It might not be going to the moon but that doesn't mean some projects aren't very complex either.
I'm not an avid hiker, but I've done enough weekend hikes to know that 10 miles per day can be pushing it for me on some terrain. I wouldn't ask someone who has never hiked ever before to estimate how long a hike would take. I wouldn't ask a programmer to estimate how long it takes to construct a bridge.
In terms of never having done it before, this is true of most software projects. If you're building the same house from the same plans then this is the same as say installing a Wordpress blog, easy to estimate. But if you were to ask how long it would take to build Wordpress from scratch, even having a Wordpress sample app, it would be very hard. Not only that but there are a lot of assumptions. Is it for a handful of visitors or are we talking a million visitor blog?
Ignoring that, let's go back to the pharma example. How long do you estimate developing a new drug will take? It's not the first drug your company has developed. Anything beyond a week is hard to estimate.
Back to your estimate of 25% within 4-8 weeks, this would never be accepted because it could mean anything.
The worse part, I an tell you right now, even if new functionality or changes are added, you will be elf to 4-8 weeks, the 25% will be ignored. And in most cases management will hold you to 4 weeks because this is what was sold to their bosses.
So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates."
As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.
I agree with what you're saying and that's all great and awesome but in the real world it unfortunately doesn't work that way. In most cases you have a day to a week to come up with an estimate for a year long project. If you by great luck get a cognate to do a spike, you get maybe an extra day. Ok most cases actually you would've maybe gotten an hour to a day at best and there would be no spike, and if you did get a spike it would be maybe an hour. Again I agree with what you're saying but it just doesn't work this way for the vast majority of companies.
Also is this real time or actual time? In other words does it include time for meetings, holidays, sick days, change in staff, etc.
That said, I believe that a week is plenty of time to estimate a year-long project. However, you need experience estimating.
Look, I'm no genius at this but when asked to estimate a task, this is what my manager would normally get:
Time to Research fuzzy task C
Find libraries for X, Y, and Z
Assume cost of $A for libraries. Make sure we have this in the budget to avoid delays
Repository setup time
Tool configuration time (if different)
Feature A
Feature B
...
Integration Test time for x, y, z
I'm on vacation for a week
Bug fix
I need to interact with Susie in Manufacturing around this date and she says she will be having a baby and out for 6 months. You need to find me a replacement contact.
Incorporate feedback from Manufacturing. Historically this adds about 2 weeks to any project.
Add up all the times and provide an estimate along with any confidence intervals around each line item.
This is how I have done it in the past before we implemented more rigorous processes and never gotten complaints. It gives management plenty to data to work with and talking points for them to ask questions about.
Just to give you an idea, do you think Steve jobs ever really allowed an estimate like this or would've accepted it? It's not just him think Amazon, oracle, EA games, etc. they all have reputations for being aggressive and you either provide and estimate they like or they will provide it for you. And not just the big companies but most of the companies are like this too. Working long hours to try and meet estimates is more than common in our industry.
Again I agree with you, and I've seen a couple times, but that's it. It's very very rare is all I'm saying. It's part of the reason I started my own company. I understand that estimates are just estimates, and in most cases they aren't going to work without spending a good amount of time on them.
But even then an estimate is an estimate, the same as you get an estimate when doing some major renovations on your house. It's only when you open up the walls and do the actual work that you'll know the true time and costs. You can't predict the plumbing is bad and leaking in your estimation. And sometimes you don't even know who the staff will be. The only way to do a proper estimate is to start the actual work.
The only thing I disagree with is that what your describing is the exception rather than the norm. Well that and a week is not enough to do a year long estimate. Of course that also depends on the size of your team, it's easier to estimate for one person than a 20 person team. But 1 week is too short. but even with the appropriate amount of time you should still be ready to accept that once the walls are opened you never truly know what you will find...
What's even more interesting is that most of the discussions around anything tend to be bike shedding discussions, discussing the color of the paint, rather than actual hard stuff.
There are exceptions but that's much more the norm. You estimate based on what you know right now and it will never be adjusted if things get added. And you will only be given the minimal amount of time to make an estimate. And of course you hope they listen and agree, many many times your estimate gets overridden.
Most software projects in a given company really don't vary all that much, so it often is like installing a WP blog. Since most companies do only minor variations of the same thing, you have pretty good history of how long the last variation took.
I can think of my last job for example. We built extremely complex medical devices, but yet we could say: software for this product will take us 4 years from concept to getting it on the market and we'd be accurate within a couple of months. It takes work and planning and sitting down and literally thinking of every major task along the way and trying to estimate how long it will take. Estimation of that sort is expensive and you have to have a good reason to take the time to do it. You also have to keep re-estimating as time goes on. Schedules aren't fixed in stone if they are to mean anything. Have to make a market window and you're running late? Well if your estimates mean anything, then features have to be removed or you ain't gonna make it!
I do agree with the management comment. You need good management that understands what they're doing. Management that understands if they change features, there is a cost. But it's up to developers to continue to make this clear to them.
Just wanted to emphasize this sentence.
Good estimates take time and cost money -- time and money that aren't necessarily worth spending. In many cases you're better off living with order-of-magnitude estimates and spending most of your time doing the actual work -- depending on the nature of the business, of course.
I've also had clients where they are not great at this. They are also invariably the ones with poor scope control and overall immature project management.
That's pretty much the definition of "estimate".
There must be a better way to package the no-estimates message, and it's not this.
Indeed, most projects are remarkably (and sadly) similar to other projects we've done before.
Saying no estimates is akin to saying "this is hard, we suck at it so we quit." The problem isn't solved, you still have no way of measuring how complete you are and when you'll be able to turn new things on.
We use a combination of story points and historical reference where we can during our estimating phase. So if we are talking about adding a new feature and wet estimate it out we go look at the actuals from a similar change that we did before to see how is base we might be. We also like story points because they are a ballpark and help us judge if we are estimating reasonably well. If we are continually having things signed low points that take data to finish, we can address that. Fast feedback and lots of iterations. The thing teams fail to do is to measure properly. If you measure too much no one fills out their stuff accurately and then you've just got garbage. Measure the wrong things and you're blind. Measure nothing (no estimates) and you're just giving yo.
We don't try to measure to the minute or hour. Things are basically 'quick' 1hr or less, 2hrs, 1/2 day, 1 day, or a 1/2 week for a task we know is big and hairy that has a lot of sub tasks that we don't really want to dive into the minutiae of it because what's relevant is that X does A and B, not that X requires T, U, and V to be done first.
That's the hard part for us, enough detail that its meaningful without spending all your time planning to plan.
ReRe's Law of Repetition and Redundancy [1]
A programmer can accurately estimate the schedule only for the repeated and the redundant. Yet,
A programmer's job is to automate the repeated and the redundant. Thus,
A programmer delivering to an estimated or predictable schedule is...
Not doing their job (or is redundant).
Answer: Well get the previous developer back to do it then. Otherwise STFU, and let me get started.
"Why is this so expensive? Can't you just copy and paste some of the code from other parts of the system?"
I couldn't even respond right away, I had to censor myself before saying anything.
Background: They wanted pre-populated values/logic very specific to their workflow. It wasn't just an easy cut and paste because the software would behave differently for them.
I've had significant success in using historical metrics to accurately estimate software projects.
It takes diligence and professional experience to learn to do this, but it is possible in my experience.
Unfortunately I find this philistine sentiment quite frequently in the software world: "I've had difficulty doing X. I am smart. I am senior. I am a professional. Therefore X must be impossible." Isn't it possible you haven't been stubborn/hard-working enough in your own personal growth?
It works best on a long-running project. When you plan a new feature, you can gauge really accurately at what speed your current team developed a feature of comparable complexity, so as you go forward you get better and better estimates.
Joel Spolsky explained it there: http://www.joelonsoftware.com/items/2007/10/26.html
I know this because every line of code I've written (using that company's process) for years has been measured and timed. So now the estimation process becomes a matter of figuring out how many LOC (as a proxy for effort) a given feature/project will be and then dividing that number by 30.
It is scarily accurate, but like I said, it's been aggregated over thousands of lines of code for years.
Properly estimating a software project takes just as long as developing the software itself.
When people want estimates they somehow assume they can be given on the spot, or at most with a few hours of work. Nothing further from the truth.
A good software estimate is a project in its own right. It takes time, a deadline and a budget to break apart a software project, design a solution, identify its subtasks, identify its critical path, research alternatives, evaluate frameworks, tentatively assign tasks to teammates, write down an estimation report, discuss it with the customer, etc.
And then you end billing the customer for 120 hours of work to conclude the project can be done in five days, give or take a week.
2. Some of my clients do excellent work with estimations delivering on time and on budget and satisfied customer (In the Wardley Six Sigma zone - low uncertainty)
3. Estimation does not work in the Genesis or Product zones (high uncertainty)
We need to grow up beyond the "software estimation not possible".
The part you're working on (and trying to estimate) in almost all cases should be "new or unknown area".
http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sig...
It says "Six Sigma/Outsource" for a reason. The product is "ordered, known, measured, standard, obvious, low margin". If at all possible, this should be an off-the-shelf choice. Previously, that would have meant packaged software; now it mostly means getting something as a library or service.
Six Sigma is fine for manufacturing low-margin items, because you are trying to get high repeatability in the world of atoms. If you have one widget and need to make one million more, you use Six Sigma. But with bits, we already have near-perfect repeatability. If I have one integer and need a million more integers, the computer will do that at a reliability level well beyond six sigmas.
If software is being made in the Six Sigma/Outsource zone, it mostly means that one is reinventing the wheel. Sometimes that's necessary for historical reasons. E.g., if I'm working in a new language but need a library that doesn't exist yet, sometimes I really can just take the old spec and implement it anew. Or if I want developers to use my cloud service, maybe I need to just reimplement chunks of the AWS API, because Amazon won't give me that code.
But the great majority of software development should take place in the higher-novelty zones, where reliable project-scale estimation is somewhere between impossible and nonsensical.
(As an aside, casting people you disagree with as children is insulting.)
Though some of my clients create software for others duplicating and modifying existing products with high certainty.
But once modifications happen, I think you're headed back to the other end of the Wardley spectrum. Do the modifications meet user goals? Do they meet business goals?
In those circumstances, the only way you can return to high certainty is by creating very firm specs and resisting change orders. From the perspective of a contract development shop, I'm sure that's fine. But for the people actually paying for the software, that's a process smell.
The commercial and practical validity of modifications can only be fully evaluated by shipping. But large specs require long release cycles. This creates a long period where learning is deferred. Estimates only become manageable because the project is saving up trouble for later. A period of artificially high predictability will be followed by a period of artificially low predictability.
And even in the pure duplication case, what comes after that? I can't think of many successful pieces of software that stopped at 1.0. Once the duplicate is released, most businesses will need to respond to their customers, doing novel and innovative things specifically for them. So at best, you're back in the fast-cycle end of the spectrum. But at worst, you have executives who are attached to specs and estimates and long timelines, which are the wrong tools for innovation. You have development processes that match. And you probably have a code base that's not set up for flexibility.
Given that, even if I were, say, making that AWS competitor, I'd still use all my tools from the fast-cycle innovation end of the spectrum. Because even a pure duplicate assumes that a) there is nothing left to learn, and that b) the context of sale/use is not changing. Estimation is always a bet that you won't learn anything important between the start and the end. Given how smart my colleagues are, that's a bet I'm rarely willing to make.
Business people have put a great deal of worthwhile thought into how to manage these risks in ways that make sense for the company. For some fresh, eye opening ideas on how to do project management for software and other businesses, check out the book The Critical Chain. The short section at the end on metrics for investment is worth the price of admission alone.
Yes there is slippage, but you learn to plan for it. In the past week I had an employee have a baby and an employee have a parent pass away and another one have a horrible knee injury and be unable to work for a couple days, meanwhile we lost no time on a project by we are up some of our buffer.
If you don't plan to meet your deadlines even when faced with feature and scope creep ( which managing is another discussion entirely ) or things 100% out of your control there is other people that can and so your not going to be picked for projects that require real time mission critical demands.
And yea, if you figure that out, you get to charge more, and sleep less.
If you start treating estimates for software as estimates for design work your life will suck less.
The anxiety and stress around making and meeting software estimates is all rooted in a misperception of what software is.
"Real businesses" budget for design work too, they just have different expectations for it than, say, a new office building.
You're not a novice programmer, you've done it before. And if you are a novice hiker, you shouldn't be doing it alone.
Similar enough that I can make good estimates. You can too, with experience.
I can tell you, if you have a relatively long project, it's worse than that: Susie (or someone else) will probably quit. Better take that into your estimate calculation.
Remember, estimates are an outer bound; if you finish early, that's ok.
Give yourself extra time: no one will complain if you finish early.
Meanwhile some crazy optimist went out and to catch a deer. It was many times more difficult than expected, but they returned to the cave with the deer and eventually reproduced more successfully than the accurate estimator.
Thus our ancestors were the crazy optimists.
More trouble than starving?
Unless you worked on a few products, your going to be bad at estimating larger pieces. A lot of software is very similar.
You can't make business decisions without having some idea of estimates, so I find that arguments like this are used to weasel out of making any sort of commitment. Go ahead, add a big buffer, try to take uncertainty into account, pad, pad, pad - at least after all that we'll have some idea.
On the other hand a very real problem I've often faced is when the target date is an input into the estimation process. I.e. we want to ship by May 2017, go estimate until the estimation fits this target date. Of course, after estimation the target date can be an input into requirements scoping, after which you can re-estimate.
The outcome was simple: his estimation was good, the team was lazy.
p : number of people
c : number of changes into specifications (= learning during implementation)
f : number of frameworks, libraries, tools.
x : number of new people, frameworks, libraries, tools
e : initial time estimate in weeks
correct estimate: E = e + e(0.1p + 0.2c + 0.3f + 1.1^x)
E=e*5
Almost always works.
Although it looks to an outsider like the main thing is typing stuff in (or pasting it in :-), the thing that takes all the time is learning what you should type, or learning why the code you already typed in isn't doing what you expected.
If you've done that exact project before then sure, you can estimate how long it will take to do it again. But that isn't often the case - usually we're trying to do something new, or better, or on a different platform. Always learning.
> And the best thing is if they then get 'their 10x code slinger' who does it indeed very fast, sends the code back to you and you are stuck with something akin to a broken toilet with diarrhea coming out the sides
A grim picture to think about but I find this to be true a lot of the time.
I usually have a pretty accurate estimate for small tasks but never go back and add the time spent on fixing recessions caused by that task. Or the time spent on extra smoke testing due to missing automation.
Sometimes your test matrix is too big. But I agree: sometimes you have to move slower in order to go faster overall and have better estimates. Estimates have to take into account testing and regression testing, which most people don't so it can make you look slow if you start doing that.
Pad your estimates, because you are typically going to have similar bugs (for similar projects), and you can account for those unknowns probablistically. You don't know the exact bugs that will be found, but you've already predicted that some will be found, so include that in your estimate.
It's usually a single bug or feature which blows the iteration. Though, by consuming so much time, it may cause other tasks to spill too.
If you aim to estimate most tasks accurately, the overall project will probably be underestimated. Outliers consume a significant portion of the overall project time.
Let's begin with the first phrase, "Software estimate". An estimate is an approximation. An approximation is an educated guess. So if someone said to you, "Please make an educated guess on when the software you are working on will be completed" To say it would be impossible would be the most absurd thing!
To make an educated guess, You would have to break down the tasks into manageable chunks that you can clearly reason about. Once you have your chunks of task, you will have knows, unknowns, some with risks or not, some that are complex or easy, etc. The problem with estimates is the unknown. If you are constructing software for an entity, then you must not approach it as an R&D, but rather, as a possible Research THEN Development. All your unknowns should be figured out at the research phase, then you estimate the development, else you should fight to remove those unknown tasks from the project.
Think about it, do you get asked for "Software research estimate" or "Software development estimate"? It's the latter, but most developers make the mistake of offering their estimate across both R&D. The really beneficial thing to developers about estimates if they do take it serious, is that it forces you to stop, think, design, and think again before coding.
The biggest concerns for developers is that estimates TURN into deadlines. This is a legitimate concern, but nevertheless this doesn't invalidate your estimate, which is nothing but an approximation. The other concern is that feature/scope creep into the project really puts a wide gap between the estimate and completion date. This again is true, remember your estimate was for the original requirements. So what are you to do as a developer? You must teach your manager if they don't know or whomever you are working for the difference between estimates and deadlines. You must also learn to keep feature creeps at bay or estimate those new features anytime they are added and adjust your estimate accordingly.
If you are a non manager or business. Please do think about this from their point of view. Projects have costs, which we can quickly approximate via cost of people working on it multiplied by the duration of the project. Part of running a business is managing your cash flow, knowing if you should spend or not. Without having an estimate of a duration of the project. How can businesses make decisions on which projects to fund? If you have a startup and $100,000 in cash. No income yet, 5 programmers that you pay $5,000 a month. Would you let them work on a project with no completion date, 1 yr estimate or 2 months estimate?
That's a trite observation. What matters is than an estimate can be made better than not estimating at all.
It's funny how all these problems come up in other disciplines, but they don't throw their hands in the air and quit.
They accept that the Nirvana Fallacy is not an acceptable reason to not estimate and they go ahead and do it anyway.
IMHO, for software project A, break the work down into relatively small pieces and attack those. Make each piece small enough so that if that the work on that piece takes too long or even just fails, then the loss there is not too big.
Some of the most important pieces are about the experience of the team -- have they successfully done just such a thing before?
So, for such experience, start with the skills and, in particular, the documentation. So, start with the skills and experience with the operating system, the text editor, the e-mail program, the file system, the command lines, and the programming languages. Then move on to other related software, e.g., TCP/IP, HTML, CSS, JavaScript, SQL, AJAX, Web site security, collection classes, APIs, etc. So, for each of these, get the documentation, the skills, the experience, etc. E.g., have people write test programs that illustrate and test the tools, and some of the more important limitations on the tools, being learned.
Then start in, say, outline form, the waterfall development process by coming up with a requirements document, that is, what the heck the software is to do.
On writing this document, e.g., what level of detail to include, get some good consulting help.
Then move on to the architecture document. This document is an example of the standard project approach of divide and conquer. So, that division results in pieces, e.g., components of some kind. So, get started on some of the components. And have write some code to test those. Do these pieces one at a time so that a failure is not to expensive.
As long as the project is not struggling at some obstacle, is making good progress, each of the small steps looks okay, then continue on.
Soon begin to get some data on how fast the work is going, at least for each of the stages.
When are well into writing the code for version 1.0, then soon should have some okay estimates of the time to complete version 1.0.
Here see part of the truth: Much of the work is getting relevant skills and experience. Next much of the work, especially the risky part, is getting a clean description of what the heck the system is to do. With those parts done well, we should be talking mostly a nice road downhill from there to a good finish line.
Gee, in the middle ages in Rome there was a big project to move a huge stone obelisk some yards to one side. Big obelisk. Big project. Lots of timbers, ropes, horses, workers. It was successful.
Impressive until ask how the heck the obelisk got there in the first place? Sure, ballpark 1000 years before some of Caligula's slaves went to the upper Nile, cut the obelisk from solid stone, floated it down the Nile, across the Mediterranean, and to Rome, and erected it.
So, Caligula's slaves did some project planning, for a project they were likely mostly doing for the first time. And they got it done.
And now we are struggling with some software project for some Web based order entry and inventory system or some such? Ah, come on, guys!