Deadlines feel like they are mainly useful to induce stress and urgency. The stress and urgency being useful (or important) is another matter.
In a perfect world (for me, from my point of view), there are no deadlines, but rather short plans and enough understanding of the plan to decide whether doing something specific is useful or a hindrance (and to what degree) for executing that plan.
A genuine deadline is good, an artificial one isn't. Sometimes budget limitation can be a genuine hard deadline. A fixed special days, such as new year or election date, can also make a hard deadline. That being said, you'll need to move the deadline some time ahead to provide buffer.
Shorter, soft deadlines and milestones are also good, since they provide a measurement between long term planning and current progress. Without them larger projects will likely failed than success.
However management loves short, hard deadlines with artificial reasons, which makes them stressful.
Your comment made me realize my problem with deadlines. Whenever I hear about a deadline, it has always been the case that management would like to have a time constraint without giving in from any of the other constraints, e.g., scope, budget, quality. It's like trying to find a solution to a set of equations when constraints guarantee that there is none.
Deadlines are great for keeping scope in check. Almost any feature can be developed with endless embellishments - without some kind of deadline it's not clear how you can decide how much of those embellishments you should add before moving on to the next feature.
It’s fine to say “we need to ship a product by 2023”. But the kind of long term plan the article is talking about would not only set a date but list the very specific features that will be delivered each month leading up to the date. This kind of planning happens really often. It’s nuts, for the reasons they list.
This is extremely long, but the fact of the matter is that these long term plans don't matter anywhere. They're a way for a relatively work-free layer of managers to feel like they have a hand in real work. After the plans are made, they can be burned: Their use was purely emotional, solely for people that won't be executing the plans.
In my experience long term plans are a way to ensure that there is a scapegoat when things go to shit. They live in the bottom of the cupboard and come out only when blame assignment begins.
“The product didn’t work because the developers didn’t follow the plan”. Doesn’t matter that the plan was half baked and had no connection to reality.
I think that things like GTM strategies are super important but long term plans are useless. Build the next thing, ship it, learn, repeat.
You are not hit with the plans because the plans exist, you are hit with the plans because you displeased someone and didn't cover yourself. Either your manager does this for you or if they are an asshole you do this by establishing a paper trail. The plans are and remain a vapid exercise that doesn't matter to anyone (no, not even the people punishing you with them).
To an extent I think it comes from looking at other companies out there that have achieved something and thinking that they planned everything about where they are now.
The reason we have deadlines and long term plans is financing. Nobody is going to give a development team a blank cheque to produce something they can't describe against no timeline. Furthermore there are often external constraints that impose deadlines and specific long term objectives. A hardware product launch for example. Even within companies, architectural or infrastructural constraints, or business commitments to partners, can add up to essentially the same situation as the agency exception.
All the problems the article describes are real, and I found it thought provoking and useful, don't get me wrong.
You are probably right. Funny, it’s product development that builds the product to begin with, the thing of value that generates revenue to pay the salaries of all these supporting roles like finance. Those roles are then planned for and filled. At some point a business silently becomes a financial instrument itself and product development in turn becomes just a resource or investment, that needs to be planned. While truth is, the product still is the business’ reason d’etre. Does this phenomenon have a name?
It's the phenomenon where the actual work increasingly gets pushed aside to make room for recording information about the work.
Jobs of higher and higher complexity get invented to measure and analyse this meta-work, ostensibly in the name of productivity. But I suspect a large portion of it is just the paper-pushing meta-workers making jobs up in order to fill their time.
Bureaucracy? Sure. It's very visible, to everyone at all these companies.
How about putting this in the context of a company & product like Coca-Cola though? It's not bad for them per se, to hand over the reins to finance/commerce/bureaucracy. Can we call it a "business cycle" perhaps?
Management, in particular for soft drink and FMCG (fast moving consumer goods) there's brand management (marketing, sales channels, target audience, product placements in movies, communicating with the consumers, coming up with new creative ideas every quarter to keep the brand fresh, managing advertisements, etc).
Basically after a certain size the question is not how to make the product better, because ... it's what it is. It's a mature product. Sure, there are sometimes quirky versions, seasonal versions, promotional versions, but the high-level focus is on keeping the market share, and to grow it if possible.
For example at that level it just makes sense to pay for lobbyists. To know where health regulation is going (soft drink tax), and of course CocaCola probably tried and tires to contest these proposals on many levels.
Bureaucracy is the process of adhering to processes, management is the process of coming up with new processes. Then of course the bigger the whole enterprise the more these seem to be ... the same.
Well said. So on a company's road to success, opportunities can arise in different corners of the international landscape. Understanding that, it makes sense that a small journey with enough time and distance becomes an enterprising voyage.
But then the question is, how does management determine whether to stay an enterprising voyage (eg exploring space endlessly) or become a settlement (eg McDonalds franchise)? Maybe the analogy ends here.
shareholders decide that implicity by hiring the management that aligns with this or that idea/vision/style.
and society at large (culture!) decides what is a worthwhile endeavor, for example by pre-ordering space telescopes, or by complaining loudly and shaming anyone who does not behave like good McDonalds patronizing people.
> The reason we have deadlines and long term plans is financing. Nobody is going to give a development team a blank cheque to produce something they can't describe against no timeline.
This is true, and the usual proposed timeline is usually wildly inaccurate.
Financing and, I'd add, feasibility assessments. A good plan may reveal that a given project is simply unachievable given the resources available, providing info for a wise manager to avoid making huge mistakes.
Sometimes we technicians adopt such condescending tone, like this article's, out of ignorance. There are decisions whose underlying logic we won't fully comprehend while we don't consider factors outside tech and product design. This article seems to share the misbelief that plans are supposed to predict future. Granted, several managers also think like that, but many people who produce and consume long-term plans are relatively well connected to reality and understand their limits.
But feasibility assessment is basically about going to the engineers and saying, "we want to spend 6 months on product X -- can it be done to satisfaction in that time?" That's often a very easy question to answer reliably.
Long-term planning approaches the problem from the ass end of things. It's going to the engineers and saying "design feature X on paper for us" and once they've spent a month doing that, management says, in the best case*, "well, this work cannot be done for real in the remaining five months, so never mind".
The original question would have been answerable in a day without going into too much detail.
----
* Best case. The more common case would be "well, now that we've spent a month planning this we better get the actual work done in the five remaining months, no matter what it takes!!"
We engineers can be really fast at refusing unrealistic estimates imposed by other departments, especially when we take them for loosers. But we are not very good at estimating as well, and we are often overoptmistic. I don't track my times too fanatically, but I do it +/- regularly and, still, I err way more than I think it's reasonable considering the data I have.
I don't think you are going to get much reliability on simply asking 1 question to an engineer, especially if you approach the matter with such overconfidence.
You might argue that an engineer would be more conservative and would avoid many mistakes by replying "no, it isn't feasible" more often than not, but then they would be wasting a lot of opportunities by discarding feasible projects, ruining the company as well, only in a different way
Is your experience really that engineers cannot reliably estimate feasibility given a fixed budget, and that they have to be treated like children and asked for something completely different?
If they can't do their own feasibility assessments, they will be producing bad work, because there are many feasibility questions that arise during design and development, and never even make it to the parents^Wmanagement.
Then I feel like that's the bigger problem that needs to be handled with training, and perpetually working around it is still a bad idea.
> Nobody is going to give a development team a blank cheque to produce something they can't describe against no timeline.
You seem to be describing an issue of trust and risk assessment.
For instance most companies won’t micro-manage projects that probably last for a few days, as they trust their team and/or feel comfortable pulling the plug after a few days if it didn’t pan out: the risk is low enough.
Same way buying a new mouse probably requires less oversight than contracting thousand dollars of GCP for 3 years.
In that respect, how long a project can be before needing a fleshed out plan, internal milestones with verifiable deliverables and a set timeline comes down to how much the team is trusted.
I only skimmed the article yet it it is ridden with weird takes on management.
Let me give you an example. You go on touristic vacation. Most people would plan the core sights to be seen and places to be visited, probably center all that around pre-booked places to crash for the night. This article sort of advocates shortening the plans to half a day plans, because you might to go a tad bit different route.
Of course there are uncertainties and the longer the term, the more uncertainties. Knowing exactly how long a task takes is worthless if you do not know what and why you are building. Where does the itemized list with well-defined tasks for sprints come from? The longer term plan. Both are very relevant, but are tools used at different levels.
Without long term plan Facebook could have ended up a dating app or blogging platform.
Do most people really vacation that way? I like to have something to fall back to, like a rough set of things to do in any type of weather, but I can't imagine making that fallback plan a priority. The priority is always what I feel like in the moment, having experienced what I have just before. Most of the moments I remember come out of spontaneously visiting a graveyard or bookshop locals talk about, or taking a trip to the outskirts of town because they looked interesting from afar. Things I would never have thought to plan!
That is exactly my gripe with the article. There is nothing stopping you from spontaneously taking a trip to outskirts instead of downtown, just because you feel that to be a good decision at the moment. And yet your large scale plan to visit town A on day #3, town B on day #4 and be back at airport on day #5 is still valid.
At least in my circles people do vacation like that - general macro plan with exact micro decision taken at the moment. Macro plan is there to give general shape and maybe put certain anchor points (hotels, flights in case of vacation). Just because you planned dinner in your macro plan does not make macro plans a bad tool in general like this article tries to portray.
I agree with the sentiments but there are a number of things that make this hard, some already alluded to.
The idea that something we "need" but maybe not in the top 5 and it seems weird to deal with it with "bring it back to each meeting until either you don't want it anymore or it becomes top 5", why not instead put it into the roadmap?
Someone else has alluded to external investment driven by strategy and long-term plans. It is uncomfortable if there is no long-term plan even though we are told that investors invest in the people, not the product.
Some tasks are long-term and might involve communication with customers, deadlines to deprecate something, other work needed to support something. If all of this will take 1 year in elapsed time, you can't simply forget the later bits since the earlier bits are only being done to support the later bits.
Because then there will be 100 things on the roadmap, 20 of which have a sponsor that have long since left the company.
In an ideal world, yes, everything would go on the roadmap which would automatically take into account the market appetite and internal economy and sort things so the most important thing is first.
In reality, trying to intelligently prioritise among hundreds of things takes a huge amount of work -- time we could instead spend on doing the real work of development. In other words, it's a trade-off: do you want to spend time shuffling Jira tickets around, or actually implementing them?
Having people bring up their top priorities repeatedly ensures that the only tasks under consideration are ones that people think are important right now, not ones that were important at some point some time ago. And we get that filtering for free!
There is a balance with all things, but I’ve started to default heavily to execution.
The best way to figure out feasibility and timing is to just start doing whatever. Presumably, we are talking about software and computers so mistakes are cheaper.
An estimate that comes out of 15 minutes of trying to do that actual thing is infinitely more informed than one that a committee deliberates for months.
I’ve been thinking a lot about this exact problem lately. If we accept the concept of “better / faster / cheaper”, but the velocity and cost of a team is fixed, then the only variable is “better”.
This means that we can either reduce the feature count or we can reduce the code quality. If we stick to the plan (which inevitably talks about features) then it’s quality that will suffer, but reducing quality has a significant cascading effect on the entire project.
So the only real option is to change the plan - change the deliverables timing. But if the value of the plan was predictability, this option suggests that long term planning isn’t particularly valuable anyway.
> If we accept the concept of “better / faster / cheaper”
The idea that these are somehow constant is one of those things that looks superficially reasonable but really is not.
I often hear people wanting to reduce quality to increase velocity. But that's not how any of this works.
Code that is hard to read, issues with tooling and papercut-type bugs that aren't showstoppers are the velocity tarpit. And these are the first things people skimp on in order to move faster. It's not just a long- versus short term thinking either.
Part of it is that nobody really knows what "quality" is in a software development context. Except for the people who specialize in software quality, but they mean something different than the rest of us.
To be clear I’m not suggesting (and don’t believe) that velocity can be improved by reducing quality - that’s actually my point.
To put it another way, the dimensions of software projects are mostly invariant; absent an unlimited budget and unlimited time, one of the few effective knobs to fiddle with is the number of features shipped by a given time.
The problem is that long term plans and detailed road maps attempt to make feature delivery invariant as well, which - IMO - is why at least 30% of IT projects still fail [0] - and of those that are said to have succeeded, many of them seem to have redefined success post-hoc.
When we start to believe that delivering features to some inflexible plan decided 12 months ago is why we’re here, we’re well on the path to building crap. What’s important to me is to ship good software as quickly as possible, learn from the users, and be flexible and respectful about the future.
[0] I’m sorry but it’s late and I’m too tired to pull out the PMI stats URL, but a cursory search should find the latest stats.
Long term plans do not work very well for sure. But they're not _meant_ to. Long term planning is meant to give people an idea of what's coming after.
This is important because what's coming after may change the implementation of what you're doing now. Some people in the team may say: "hey if we did 3 before 1, then we'd have 2 for free".
Estimating the time it will take to do things is also important cause you may think that you know what's coming after, but if you don't know how much time it may take (apply a 0.5-2 multiplier range), you may actually never have time to do it.
Keep making plans. Keep selling them to stakeholders, and keep telling them that it's just a rough plan and that details will be very different.
In any case, it'll cost you more pain to fight your CEO and tell them that you don't want to make a 1-year plan, than to actually making a 1-year plan...
I feel like you are talking about something more like roadmap.
Of course long term plans/road maps have their place when everybody agrees on that it is an "idea of what's coming"
However most long term plans I have encountered at my last two companies have absolutely been treated as commitments to detailed plans two years ahead of time,
before we have no idea what we really want.
This is causing project members constantly stressing/hurting about not meeting plan still years after everyone knows that the plan does reflect real life anymore.
I think there's a lot of confusion in this area. A long term plan tends to become too rigid, making us unable to respond to change. If we are dealing with a complex problem
where the outcome is hard to predict this is a death sentence to the project.
On the other hand having only short term "agile" plans can on the extreme end turn us reactive and without any focus. If we are dealing with a "big" problem this is a death sentence for the project.
If the project is big complex and hard to predict we have to be able to be agile on both the short term and the long term, and sometimes on the really really long term, all at the same time. Oh, and also for the group and the whole organisation at the same time.
No, in my team we've been doing 1y actual plans for the past twelve years, with time estimates and project breakdowns and who's going to do what and when.
What does work well mean? Compared to what, and is that a fair comparison?
Long term plans "work", but by sticking to them you might be giving up opportunities to do something more profitable. They can also "work" in the sense that the culture encourages abandoning them if something more profitable comes up, but then you've spent time planning for something that doesn't happen.
How often do you decide to abandon your long-term plan for something more profitable? And how often do you decide to pass up on something more profitable to stick to the plan?
>> However most long term plans I have encountered at my last two companies have absolutely been treated as commitments to detailed plans two years ahead of time, before we have no idea what we really want.
That is an issue with your company, not plans themselves. I'd agree with avoiding long term plans in a disfunctional organisation.
Beyond the inability to reason about stuff, not even asking Who What Why When Where and How, the inability to divide & conquer, the hostility to verifying assumptions (eg will any one buy our stuff?), etc. etc.
I've met very few people, any where, in business or politics, that can war game scenarios. Much less reason about tactical decisions. Or even know the difference between strategy and tactics.
My hunch, totally unvalidated, is a strategic thinker isn't especially smart or talented, so much as everyone else is fantastically, tragically inept.
I always marveled about the rise of Microsoft. Sure, they did some good stuff, made some good moves. (And then later was simply criminal.) But OMG their competition was terrible. Ashton-Tate, WordPerfect, Novell, Lotus, and probably a zillion others. So many defeated themselves. Microsoft was like the Bolsheviks; they found power lying on the street, after every one else imploded.
> Long term planning is meant to give people an idea of what's coming after.
This is precisely the problem though. Your statement is contradictory because if (as you say) long term plans don't in fact work, that "having an idea of what's coming" is complete fiction.
And trust me, confidently believing in fiction is much much worse for effective planning than proactively preparing your product for uncertain outcomes.
If I am 100% sure our product will be doing X and not Y in 18 months, I'm going to build that product with a strong bias toward X and zero consideration for Y. If I don't know what's coming, I'm going to build it with weak contracts toward both and a heavy emphasis on being refactor-/pivot-friendly. Which of those approaches will serve my company better when we unexpectedly end up switching to Y after a year?
That's fair. This isn't a binary, and the ideal is likely somewhere in the middle.
Still, I do think there's quite a large portion of detail-planning that can be radically different dependent on the high-level expectations, even where the range of high-level outcomes is small.
i.e. (random off-the-top-of-my-head example): I'm building a piece of software offering some kind of service to end-users. We're considering staff-curated -vs- user-generated & curated content & we opt for the user-gen approach as we don't think the first option will scale. As we get into the market, we quickly realise the demand for content is high, we're in a good position to adjust our pricing upward, but engagement in content-provision & curation activities is low. So we decide to pivot to staff-curation.
The above pivot doesn't involve a radical product change (the offering remains similar overall), but does involve radical technical changes under the hood. A long-term-planning oriented company may have invested heavily in building robust (expensive & complex) community features that may be thrown out later. A short-term-planning oriented company would more likely hedge their technical decisions - leverage some 3rd-parties temporarily during user-testing, maybe test earlier, be more sensitive to priority changes.
I think parent’s point still stands: expecting that X and not Y will come in 18 months might be worse than not expecting anything, if X actually comes in 36 months.
Even within the same organization, it’s such a gamble when:
- X might never come if the project takes too long or gets deprioritized. 18 months is a long time, perhaps half of an engineer’s average time in the company. X’s sponsor going away could mean the project stays in limbo for the rest of its life
- X might become Z when you realize midway that X wasn’t a good idea in the first place, or the assumptions behind X changed enough for the project to not make sense anymore. The org might not care for the cost to readjust now that X is gone, but you’re still worse off than if you weren’t waiting for X.
The refactor question is not just about the next 18 months. How likely the project will be in active development in 5 or 15 years?
That’s something long term planning can give you a reasonable idea about. If your working on Madden 24 then the business model is about minor changes every year, while most games are one and done.
>And trust me, confidently believing in fiction is much much worse for effective planning
Absolutely TRUE - and this becomes a political problem in some organizations, depending on whether you're around people who can handle hearing the truth (whether they just don't want to hear bad news, or whether they don't understand complex webs of interdependencies that can cause time estimates to be wrong).
I feel this is a problem in our entire mindset. People so often get confused with the difference between a plan and a goal. One is the what and one is the how. What most people call plans are really just goals. Plans require sufficient data to make a how. Or they need a whole set of contingency plans that would be the plan if and when sufficient data becomes available. This is why "long term plans" are so vague in general because they are just a goal. As time progresses, the long term becomes the short and the data becomes available to turn goals into plans that can be executed.
Agreed. The alternative to long-term planning is often a feeling of aimlessness, chasing the next incremental improvement with no idea of what, if anything, will be achieved. Useful fictions can still be useful.
OT, but anecdotical: Just a month ago ago, it seemed, my girlfriend was 'multitasking'. Confused i asked her why she does something, left it and leave for a minute or two (in and out). She said: "This seem to be my way to get around 'oh-i-forgot-this-or-that'-surprises" ^^ (-kitchen-talk).
Some moments later i remembered, i had made a comic about exactly that. Searched for, and 5 (um no! way more years ^^) years ago we both sat in the kitchen, when i was writing a note after she confronted me with: 'you seem to forget too much!', after i had forgotten something. So i was writing when she ask me: 'what do you wrote?', and i told her 'A to-do-list'.
So she sayed: 'Show me...' i handed it to her, written on the sheet of paper was: 'What you can do in under two-minutes, do instantaneously !' (-;
> 1. Nothing will go wrong 2. Product developers know precisely what they must build 3. Product developers know exactly how long each task is going to take
If your plan is built with these assumptions you are not very experienced at long term planning.
The real reasons long term plans don't work well in real life is are:
1. People don't spend enough thought on strategy before putting the plan together [1]
2. The people assigned to make the long term plan often don't have buy in for the results
3. Most management teams have, at max, a 1-2 month attention span
The most important result of a long term plan is that it produces a collection of important, documented, well understood projects and their relevant priorities and approximate costs.
Thats the exact opposite point to the author’s. Both can be true depending on context, but I find his take more realistic for the majority of products in tech.
You’re suggesting that plans fail due to poor execution, he is saying long-term plans are pointless when you don’t know where you’re going in terms of market fit, design, feature set, which is usually the case (and arguably should be the case if you want to build a competitive product).
Can you give us some context or background of the field you’re in? Things differ quite a bit between a mobile app vs shipyard crane controller software.
The point is that even “proper” long term planning doesn’t work for the former. You never have enough information for the plans to actually materialize, it’s not simply the planners fault.
Well ... in my 30+ years I've done medical (imaging and diagnostics where design controls and planning are required by regulation), enterprise firewalls/anti-spam/anti-virus (again, design and planning critical), more than a few mobile apps, SaaS, VR. So pretty much the gamut.
Long term planning "works" everywhere ... you just have different plans: sometimes less detail on the 3-12 month items, sometimes you need a detailed plan out for a full year or more.
While the problems presented are real, the solution proposed is laughable. None of these are new problems. It’s amazing how often we think we’ve discovered something new when it’s really an age-old problem that has been debated forever.
I like to sum it up as the tension between two contradictory yet true axioms:
(1) Failure to plan is planning to fail.
(2) No plan survives contact with the enemy.
You can’t just abandon long term thinking because it’s hard. Grow up. You’re an adult. Life is hard. You still need to have a destination in mind. The path to getting there probably won’t look like the one you planned, but your odds of success are much better when you both have a plan and are ready to adapt and evolve that plan as you go.
That's another great way to put it, but I don't know that I'd say plans are "useless". It's a good adage all the same, as long as we don't take it too literally. (Which, ironically, is a good way to think of any plan, too.)
Long term thinking and planning are different though.
> Grow up. You’re an adult.
Being an adult is also about taking paths that you don’t know where they go, but have enough resources, experience and confidence you’ll make it work somehow. I think your point has merit, but it’s not that solid to match such confidence in it.
In virtually all initiatives, we don’t know where we’ll end up. Not really.
But the best way forward, the best way to set yourself up for success, is to develop a plan based on what you do know. It’s incumbent upon anyone responsible for keeping others employed that we don’t dive into things blindly. We make informed bets, and hopefully we’re right more often than we’re wrong.
I’d like to add that you were far more respectful of me than I was of the OP. I appreciate your respectfulness, and I’ll strive to do better.
I think the article could be improved by defining or giving an example of a long term plan.
At the start of each year we have a plan, but it's a rough plan. We know we have certain external constraints that need to be met, for example system A is moving from sending XML files via SFTP to a REST API in June. If we already know the scope, we'll have some rough dates for when we should be ready for testing and so on, if not we have some (much) earlier dates for studying documentation to determine scope and requirements.
We also have some internal goals we would like to meet, for example making a new module for doing X. They also got some rough dates attached.
This yearly plan is then used to ground our short-term planning.
However, I didn't get the feeling that it was this sort of long term plan the article had in mind.
This article assumes a very narrow definition of "long-term plan", yet doesn't give that definition to the reader. Here are some clues towards that definition:
> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget
"The plan does not look at the usefulness of work done. The plan decides in advance on a time frame and budget for each feature."
> Consequently, to make up for these delays, teams are pressured to deliver the next feature in less time than they originally estimated.
"The plan must be rigid with respect to unforeseen bugs. Scope or time frame cannot be adjusted."
> Consequently, long-term plans either force you to stick to useless features or pressure the team to accelerate the following features to compensate for the delay created by listening to feedback.
"The plan does not allow adjustments based on feedback."
My experience is that the only thing that actually works is making the plan simpler. As in: implement the simplest version of whatever you're building at the same time being mindful that you'll have to eventually include all the features.
With such a solution:
-You can start dogfooding early on.
-There's less to go wrong.
-There's less sunk cost in those of the features that don't make it to the final product.
Integrate one of all those payment processors that were required, one external API and move on. Also don't do fancy, handcrafted components on the frontend. Or component libraries for that matter. Have separate tickets for validation.
Once you're finished with that you'll find that in the meantime the Nth payment processor went bankrupt, Nth external API was deprecated and UX finally managed to convince the stakeholders that a color picker the shape of a peacock following the mouse with its gaze is not the best solution in terms of user experience.
A plan and a backlog are two very different things. A backlog is not a plan. But having a backlog is still a good idea. Especially if it is prioritized and you have a clear idea of what you need to do short term and why.
That prioritization does not come out of nowhere, there need to be some business goals and a strategy. Those are longer term things that change less often. Often that is summarized in some kind of roadmap. A roadmap is also not a plan but more of a tool that you use to align short term planning with long term goals. Ours is adjusted on a quarterly level and we tend to try to figure out the two or three most important things that we need to make some progress on. And we set some targets based on that.
But a list of items that you want without a clear idea of how you are going to do these things is not a plan. Simple reality: unless you do waterfall, you won't have such a plan. And if you do, it's likely a bad plan. Adjusting plans regularly and figuring out business goals is something that happens a lot in software engineering. A classic misunderstanding is that that is a problem that needs to be fixed. It's a feature, not a bug.
Building software is simply not like manufacturing, architecture or other engineering disciplines where you work off blueprints on predictable schedules. Until those blueprints are done, planning an engineering project is not doable either.
You are not going to start building say a nuclear power plant without a very detailed plan and some blueprints and lots of analysis having taken place already. Of course, creating such a plan typically takes years and represents a massive investment in itself. And of course a common complaint with nuclear plants is that the planning stage is expensive, runs too long, and seems hard to plan. Agile nuclear plant design seems to be not a thing but if you think about it, the process of coming up with detailed plans for a nuclear plant has some similarities to how software projects work. Lots of uncertainty, constantly changing rules, requirements, legislation, and other factors. Maybe they should be more agile?
Anyway, in software, the blueprints are the main thing that you build. That's why it's called software. It's an executable specification of some sort. Building that specification is the whole work. Having a blueprint for the blueprint is not really a thing (though of course many have attempted this). You might sketch out bits of it on a whiteboard and do some mvps, prototypes, and what not. But that's not the same as a detailed plan either.
What's interesting is that some engineering companies are actually applying agile practices. E.g. the way SpaceX rapidly iterates on their prototypes seems a lot like the chaos you see in software companies. It seems to work for them and is very different from the way some of their old competitors work. What has changed there is that a lot of the work has moved inside computers. They are iterating on software, cad designs, using simulations, etc. Modern engineering inherently involves a lot of software. And you need to plan accordingly.
I can answer for the previous job I had. When I joined, we had a process where
1. A plan took roughly 40 person-hours to make.
2. The plans were meant to cover 6--18 months, although a bit unclear at times.
3. These plans were generally made 5--6 times per year.
4. 100 % of the plans were abandoned for something more profitable.
5. About 80 % of the time when something more profitable came up, we chose to pass it up to stick to the plan.
Halfway through my time there, we had a change of process which moved emphasis much more toward short-term planning. The long-term plans became much more flexible. I would summarise the outcome as
1. The long-term plan is built in 4 hours.
2. It still covers roughly 12--18 months.
3. The plans are adjusted to agree with reality every 5 weeks or so.
4. The long-term plans are still abandoned around 100 % of the time.
5. We now pass up on around 50 % of the more profitable things.
1. There's a few weeks every summer where planning is a major focus, but then evaluating and adapting that plan might take up to half a day a week on average throughout the year. Basically: What assumptions underlie the plan, and have those assumptions changed? Maybe we assumed wrong, or maybe facts changed. So I try to keep an eye out for things that require an adjustment in our direction.
2. I have 10 year goals, 3-5 year milestones, and 1 year plans. I'd like to push that to 18 month plans, but at the moment I only go into any detail for 12 months.
3. Once per year in terms of formally planning the subsequent year.
4. I can't think of a time where I completely abandoned a plan (as opposed to adapting it to changing data).
5. Interesting question. I would argue "never", because if there's a truly more profitable option on the table, then the plan needs to adapt and take that into account. But are we talking about short-term or long-term profitable? I very rarely change my plans in response to short-term opportunities, because that's a great way of killing long-term profitability.
137 comments
[ 7.5 ms ] story [ 85.9 ms ] threadDeadlines are useful. Yes it may need to be pushed back but saying it'll be ready when it's ready with no time frame is not, in most cases useful.
In a perfect world (for me, from my point of view), there are no deadlines, but rather short plans and enough understanding of the plan to decide whether doing something specific is useful or a hindrance (and to what degree) for executing that plan.
But alas, deadlines are easier to decide on.
Shorter, soft deadlines and milestones are also good, since they provide a measurement between long term planning and current progress. Without them larger projects will likely failed than success.
However management loves short, hard deadlines with artificial reasons, which makes them stressful.
It’s fine to say “we need to ship a product by 2023”. But the kind of long term plan the article is talking about would not only set a date but list the very specific features that will be delivered each month leading up to the date. This kind of planning happens really often. It’s nuts, for the reasons they list.
“The product didn’t work because the developers didn’t follow the plan”. Doesn’t matter that the plan was half baked and had no connection to reality.
I think that things like GTM strategies are super important but long term plans are useless. Build the next thing, ship it, learn, repeat.
All the problems the article describes are real, and I found it thought provoking and useful, don't get me wrong.
It's the phenomenon where the actual work increasingly gets pushed aside to make room for recording information about the work.
Jobs of higher and higher complexity get invented to measure and analyse this meta-work, ostensibly in the name of productivity. But I suspect a large portion of it is just the paper-pushing meta-workers making jobs up in order to fill their time.
How about putting this in the context of a company & product like Coca-Cola though? It's not bad for them per se, to hand over the reins to finance/commerce/bureaucracy. Can we call it a "business cycle" perhaps?
Basically after a certain size the question is not how to make the product better, because ... it's what it is. It's a mature product. Sure, there are sometimes quirky versions, seasonal versions, promotional versions, but the high-level focus is on keeping the market share, and to grow it if possible.
For example at that level it just makes sense to pay for lobbyists. To know where health regulation is going (soft drink tax), and of course CocaCola probably tried and tires to contest these proposals on many levels.
Bureaucracy is the process of adhering to processes, management is the process of coming up with new processes. Then of course the bigger the whole enterprise the more these seem to be ... the same.
But then the question is, how does management determine whether to stay an enterprising voyage (eg exploring space endlessly) or become a settlement (eg McDonalds franchise)? Maybe the analogy ends here.
and society at large (culture!) decides what is a worthwhile endeavor, for example by pre-ordering space telescopes, or by complaining loudly and shaming anyone who does not behave like good McDonalds patronizing people.
This is true, and the usual proposed timeline is usually wildly inaccurate.
Sometimes we technicians adopt such condescending tone, like this article's, out of ignorance. There are decisions whose underlying logic we won't fully comprehend while we don't consider factors outside tech and product design. This article seems to share the misbelief that plans are supposed to predict future. Granted, several managers also think like that, but many people who produce and consume long-term plans are relatively well connected to reality and understand their limits.
Long-term planning approaches the problem from the ass end of things. It's going to the engineers and saying "design feature X on paper for us" and once they've spent a month doing that, management says, in the best case*, "well, this work cannot be done for real in the remaining five months, so never mind".
The original question would have been answerable in a day without going into too much detail.
----
* Best case. The more common case would be "well, now that we've spent a month planning this we better get the actual work done in the five remaining months, no matter what it takes!!"
We engineers can be really fast at refusing unrealistic estimates imposed by other departments, especially when we take them for loosers. But we are not very good at estimating as well, and we are often overoptmistic. I don't track my times too fanatically, but I do it +/- regularly and, still, I err way more than I think it's reasonable considering the data I have.
I don't think you are going to get much reliability on simply asking 1 question to an engineer, especially if you approach the matter with such overconfidence.
You might argue that an engineer would be more conservative and would avoid many mistakes by replying "no, it isn't feasible" more often than not, but then they would be wasting a lot of opportunities by discarding feasible projects, ruining the company as well, only in a different way
> asking 1 question to your engineers
If they can't do their own feasibility assessments, they will be producing bad work, because there are many feasibility questions that arise during design and development, and never even make it to the parents^Wmanagement.
Then I feel like that's the bigger problem that needs to be handled with training, and perpetually working around it is still a bad idea.
You seem to be describing an issue of trust and risk assessment.
For instance most companies won’t micro-manage projects that probably last for a few days, as they trust their team and/or feel comfortable pulling the plug after a few days if it didn’t pan out: the risk is low enough.
Same way buying a new mouse probably requires less oversight than contracting thousand dollars of GCP for 3 years.
In that respect, how long a project can be before needing a fleshed out plan, internal milestones with verifiable deliverables and a set timeline comes down to how much the team is trusted.
Let me give you an example. You go on touristic vacation. Most people would plan the core sights to be seen and places to be visited, probably center all that around pre-booked places to crash for the night. This article sort of advocates shortening the plans to half a day plans, because you might to go a tad bit different route.
Of course there are uncertainties and the longer the term, the more uncertainties. Knowing exactly how long a task takes is worthless if you do not know what and why you are building. Where does the itemized list with well-defined tasks for sprints come from? The longer term plan. Both are very relevant, but are tools used at different levels.
Without long term plan Facebook could have ended up a dating app or blogging platform.
My best travels have been those where I only ever planned one or two days ahead. Backpacking is great!
At least in my circles people do vacation like that - general macro plan with exact micro decision taken at the moment. Macro plan is there to give general shape and maybe put certain anchor points (hotels, flights in case of vacation). Just because you planned dinner in your macro plan does not make macro plans a bad tool in general like this article tries to portray.
To me, a good plan is a map of dependencies in time.
The idea that something we "need" but maybe not in the top 5 and it seems weird to deal with it with "bring it back to each meeting until either you don't want it anymore or it becomes top 5", why not instead put it into the roadmap?
Someone else has alluded to external investment driven by strategy and long-term plans. It is uncomfortable if there is no long-term plan even though we are told that investors invest in the people, not the product.
Some tasks are long-term and might involve communication with customers, deadlines to deprecate something, other work needed to support something. If all of this will take 1 year in elapsed time, you can't simply forget the later bits since the earlier bits are only being done to support the later bits.
Because then there will be 100 things on the roadmap, 20 of which have a sponsor that have long since left the company.
In an ideal world, yes, everything would go on the roadmap which would automatically take into account the market appetite and internal economy and sort things so the most important thing is first.
In reality, trying to intelligently prioritise among hundreds of things takes a huge amount of work -- time we could instead spend on doing the real work of development. In other words, it's a trade-off: do you want to spend time shuffling Jira tickets around, or actually implementing them?
Having people bring up their top priorities repeatedly ensures that the only tasks under consideration are ones that people think are important right now, not ones that were important at some point some time ago. And we get that filtering for free!
[0] https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
The best way to figure out feasibility and timing is to just start doing whatever. Presumably, we are talking about software and computers so mistakes are cheaper.
An estimate that comes out of 15 minutes of trying to do that actual thing is infinitely more informed than one that a committee deliberates for months.
This means that we can either reduce the feature count or we can reduce the code quality. If we stick to the plan (which inevitably talks about features) then it’s quality that will suffer, but reducing quality has a significant cascading effect on the entire project.
So the only real option is to change the plan - change the deliverables timing. But if the value of the plan was predictability, this option suggests that long term planning isn’t particularly valuable anyway.
The idea that these are somehow constant is one of those things that looks superficially reasonable but really is not.
I often hear people wanting to reduce quality to increase velocity. But that's not how any of this works.
Code that is hard to read, issues with tooling and papercut-type bugs that aren't showstoppers are the velocity tarpit. And these are the first things people skimp on in order to move faster. It's not just a long- versus short term thinking either.
Part of it is that nobody really knows what "quality" is in a software development context. Except for the people who specialize in software quality, but they mean something different than the rest of us.
To put it another way, the dimensions of software projects are mostly invariant; absent an unlimited budget and unlimited time, one of the few effective knobs to fiddle with is the number of features shipped by a given time.
The problem is that long term plans and detailed road maps attempt to make feature delivery invariant as well, which - IMO - is why at least 30% of IT projects still fail [0] - and of those that are said to have succeeded, many of them seem to have redefined success post-hoc.
When we start to believe that delivering features to some inflexible plan decided 12 months ago is why we’re here, we’re well on the path to building crap. What’s important to me is to ship good software as quickly as possible, learn from the users, and be flexible and respectful about the future.
[0] I’m sorry but it’s late and I’m too tired to pull out the PMI stats URL, but a cursory search should find the latest stats.
Long term plans do not work very well for sure. But they're not _meant_ to. Long term planning is meant to give people an idea of what's coming after.
This is important because what's coming after may change the implementation of what you're doing now. Some people in the team may say: "hey if we did 3 before 1, then we'd have 2 for free".
Estimating the time it will take to do things is also important cause you may think that you know what's coming after, but if you don't know how much time it may take (apply a 0.5-2 multiplier range), you may actually never have time to do it.
Keep making plans. Keep selling them to stakeholders, and keep telling them that it's just a rough plan and that details will be very different.
In any case, it'll cost you more pain to fight your CEO and tell them that you don't want to make a 1-year plan, than to actually making a 1-year plan...
Of course long term plans/road maps have their place when everybody agrees on that it is an "idea of what's coming"
However most long term plans I have encountered at my last two companies have absolutely been treated as commitments to detailed plans two years ahead of time, before we have no idea what we really want.
This is causing project members constantly stressing/hurting about not meeting plan still years after everyone knows that the plan does reflect real life anymore.
On the other hand having only short term "agile" plans can on the extreme end turn us reactive and without any focus. If we are dealing with a "big" problem this is a death sentence for the project.
If the project is big complex and hard to predict we have to be able to be agile on both the short term and the long term, and sometimes on the really really long term, all at the same time. Oh, and also for the group and the whole organisation at the same time.
It just works very well for us.
Long term plans "work", but by sticking to them you might be giving up opportunities to do something more profitable. They can also "work" in the sense that the culture encourages abandoning them if something more profitable comes up, but then you've spent time planning for something that doesn't happen.
How often do you decide to abandon your long-term plan for something more profitable? And how often do you decide to pass up on something more profitable to stick to the plan?
That is an issue with your company, not plans themselves. I'd agree with avoiding long term plans in a disfunctional organisation.
Yes and: Strategy & Tactics
Beyond the inability to reason about stuff, not even asking Who What Why When Where and How, the inability to divide & conquer, the hostility to verifying assumptions (eg will any one buy our stuff?), etc. etc.
I've met very few people, any where, in business or politics, that can war game scenarios. Much less reason about tactical decisions. Or even know the difference between strategy and tactics.
My hunch, totally unvalidated, is a strategic thinker isn't especially smart or talented, so much as everyone else is fantastically, tragically inept.
I always marveled about the rise of Microsoft. Sure, they did some good stuff, made some good moves. (And then later was simply criminal.) But OMG their competition was terrible. Ashton-Tate, WordPerfect, Novell, Lotus, and probably a zillion others. So many defeated themselves. Microsoft was like the Bolsheviks; they found power lying on the street, after every one else imploded.
This is precisely the problem though. Your statement is contradictory because if (as you say) long term plans don't in fact work, that "having an idea of what's coming" is complete fiction.
And trust me, confidently believing in fiction is much much worse for effective planning than proactively preparing your product for uncertain outcomes.
If I am 100% sure our product will be doing X and not Y in 18 months, I'm going to build that product with a strong bias toward X and zero consideration for Y. If I don't know what's coming, I'm going to build it with weak contracts toward both and a heavy emphasis on being refactor-/pivot-friendly. Which of those approaches will serve my company better when we unexpectedly end up switching to Y after a year?
I am pretty sure there are teams / projects for which one methodology is better than the other.
Stating that there are no situations in which it is beneficial for some team to make long term plans is simply too strong a statement.
Still, I do think there's quite a large portion of detail-planning that can be radically different dependent on the high-level expectations, even where the range of high-level outcomes is small.
i.e. (random off-the-top-of-my-head example): I'm building a piece of software offering some kind of service to end-users. We're considering staff-curated -vs- user-generated & curated content & we opt for the user-gen approach as we don't think the first option will scale. As we get into the market, we quickly realise the demand for content is high, we're in a good position to adjust our pricing upward, but engagement in content-provision & curation activities is low. So we decide to pivot to staff-curation.
The above pivot doesn't involve a radical product change (the offering remains similar overall), but does involve radical technical changes under the hood. A long-term-planning oriented company may have invested heavily in building robust (expensive & complex) community features that may be thrown out later. A short-term-planning oriented company would more likely hedge their technical decisions - leverage some 3rd-parties temporarily during user-testing, maybe test earlier, be more sensitive to priority changes.
Even within the same organization, it’s such a gamble when:
- X might never come if the project takes too long or gets deprioritized. 18 months is a long time, perhaps half of an engineer’s average time in the company. X’s sponsor going away could mean the project stays in limbo for the rest of its life
- X might become Z when you realize midway that X wasn’t a good idea in the first place, or the assumptions behind X changed enough for the project to not make sense anymore. The org might not care for the cost to readjust now that X is gone, but you’re still worse off than if you weren’t waiting for X.
That’s something long term planning can give you a reasonable idea about. If your working on Madden 24 then the business model is about minor changes every year, while most games are one and done.
Absolutely TRUE - and this becomes a political problem in some organizations, depending on whether you're around people who can handle hearing the truth (whether they just don't want to hear bad news, or whether they don't understand complex webs of interdependencies that can cause time estimates to be wrong).
Some moments later i remembered, i had made a comic about exactly that. Searched for, and 5 (um no! way more years ^^) years ago we both sat in the kitchen, when i was writing a note after she confronted me with: 'you seem to forget too much!', after i had forgotten something. So i was writing when she ask me: 'what do you wrote?', and i told her 'A to-do-list'.
So she sayed: 'Show me...' i handed it to her, written on the sheet of paper was: 'What you can do in under two-minutes, do instantaneously !' (-;
edited:typo
If your plan is built with these assumptions you are not very experienced at long term planning.
The real reasons long term plans don't work well in real life is are:
1. People don't spend enough thought on strategy before putting the plan together [1]
2. The people assigned to make the long term plan often don't have buy in for the results
3. Most management teams have, at max, a 1-2 month attention span
The most important result of a long term plan is that it produces a collection of important, documented, well understood projects and their relevant priorities and approximate costs.
[1] See comments on "Why don't we have a strategy?" https://news.ycombinator.com/item?id=32094469
You’re suggesting that plans fail due to poor execution, he is saying long-term plans are pointless when you don’t know where you’re going in terms of market fit, design, feature set, which is usually the case (and arguably should be the case if you want to build a competitive product).
Proper long term planning EXPLICITLY includes:
Risk Planning for "1. Nothing will go wrong"
Provisions for Product marketing/Spikes/UX Design to address that fact that "2. Product developers [DON'T] know precisely what they must build"
Padding and provisions in estimation errors to address "3. Product developers know exactly how long each task is going to take"
It's like Long Term Planning 101 to address these things.
The point is that even “proper” long term planning doesn’t work for the former. You never have enough information for the plans to actually materialize, it’s not simply the planners fault.
Long term planning "works" everywhere ... you just have different plans: sometimes less detail on the 3-12 month items, sometimes you need a detailed plan out for a full year or more.
I like to sum it up as the tension between two contradictory yet true axioms:
(1) Failure to plan is planning to fail.
(2) No plan survives contact with the enemy.
You can’t just abandon long term thinking because it’s hard. Grow up. You’re an adult. Life is hard. You still need to have a destination in mind. The path to getting there probably won’t look like the one you planned, but your odds of success are much better when you both have a plan and are ready to adapt and evolve that plan as you go.
> Grow up. You’re an adult.
Being an adult is also about taking paths that you don’t know where they go, but have enough resources, experience and confidence you’ll make it work somehow. I think your point has merit, but it’s not that solid to match such confidence in it.
In virtually all initiatives, we don’t know where we’ll end up. Not really.
But the best way forward, the best way to set yourself up for success, is to develop a plan based on what you do know. It’s incumbent upon anyone responsible for keeping others employed that we don’t dive into things blindly. We make informed bets, and hopefully we’re right more often than we’re wrong.
I’d like to add that you were far more respectful of me than I was of the OP. I appreciate your respectfulness, and I’ll strive to do better.
At the start of each year we have a plan, but it's a rough plan. We know we have certain external constraints that need to be met, for example system A is moving from sending XML files via SFTP to a REST API in June. If we already know the scope, we'll have some rough dates for when we should be ready for testing and so on, if not we have some (much) earlier dates for studying documentation to determine scope and requirements.
We also have some internal goals we would like to meet, for example making a new module for doing X. They also got some rough dates attached.
This yearly plan is then used to ground our short-term planning.
However, I didn't get the feeling that it was this sort of long term plan the article had in mind.
> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget
"The plan does not look at the usefulness of work done. The plan decides in advance on a time frame and budget for each feature."
> Consequently, to make up for these delays, teams are pressured to deliver the next feature in less time than they originally estimated.
"The plan must be rigid with respect to unforeseen bugs. Scope or time frame cannot be adjusted."
> Consequently, long-term plans either force you to stick to useless features or pressure the team to accelerate the following features to compensate for the delay created by listening to feedback.
"The plan does not allow adjustments based on feedback."
With such a solution:
-You can start dogfooding early on.
-There's less to go wrong.
-There's less sunk cost in those of the features that don't make it to the final product.
Integrate one of all those payment processors that were required, one external API and move on. Also don't do fancy, handcrafted components on the frontend. Or component libraries for that matter. Have separate tickets for validation.
Once you're finished with that you'll find that in the meantime the Nth payment processor went bankrupt, Nth external API was deprecated and UX finally managed to convince the stakeholders that a color picker the shape of a peacock following the mouse with its gaze is not the best solution in terms of user experience.
hahahahaha
That prioritization does not come out of nowhere, there need to be some business goals and a strategy. Those are longer term things that change less often. Often that is summarized in some kind of roadmap. A roadmap is also not a plan but more of a tool that you use to align short term planning with long term goals. Ours is adjusted on a quarterly level and we tend to try to figure out the two or three most important things that we need to make some progress on. And we set some targets based on that.
But a list of items that you want without a clear idea of how you are going to do these things is not a plan. Simple reality: unless you do waterfall, you won't have such a plan. And if you do, it's likely a bad plan. Adjusting plans regularly and figuring out business goals is something that happens a lot in software engineering. A classic misunderstanding is that that is a problem that needs to be fixed. It's a feature, not a bug.
Building software is simply not like manufacturing, architecture or other engineering disciplines where you work off blueprints on predictable schedules. Until those blueprints are done, planning an engineering project is not doable either.
You are not going to start building say a nuclear power plant without a very detailed plan and some blueprints and lots of analysis having taken place already. Of course, creating such a plan typically takes years and represents a massive investment in itself. And of course a common complaint with nuclear plants is that the planning stage is expensive, runs too long, and seems hard to plan. Agile nuclear plant design seems to be not a thing but if you think about it, the process of coming up with detailed plans for a nuclear plant has some similarities to how software projects work. Lots of uncertainty, constantly changing rules, requirements, legislation, and other factors. Maybe they should be more agile?
Anyway, in software, the blueprints are the main thing that you build. That's why it's called software. It's an executable specification of some sort. Building that specification is the whole work. Having a blueprint for the blueprint is not really a thing (though of course many have attempted this). You might sketch out bits of it on a whiteboard and do some mvps, prototypes, and what not. But that's not the same as a detailed plan either.
What's interesting is that some engineering companies are actually applying agile practices. E.g. the way SpaceX rapidly iterates on their prototypes seems a lot like the chaos you see in software companies. It seems to work for them and is very different from the way some of their old competitors work. What has changed there is that a lot of the work has moved inside computers. They are iterating on software, cad designs, using simulations, etc. Modern engineering inherently involves a lot of software. And you need to plan accordingly.
Could you people on HN share some numbers? If I get a lot of good responses I might present a summary later.
1. How long do you usually spend making your long-term plans?
2. How much time does one of these long-term plans cover?
3. How often do you make these long-term plans?
4. How often do you end up abandoning a long-term plan to do something more profitable as it comes up?
5. How often do you pass on doing something more profitable because you choose to stick to your long-term plan instead?
1. A plan took roughly 40 person-hours to make.
2. The plans were meant to cover 6--18 months, although a bit unclear at times.
3. These plans were generally made 5--6 times per year.
4. 100 % of the plans were abandoned for something more profitable.
5. About 80 % of the time when something more profitable came up, we chose to pass it up to stick to the plan.
Halfway through my time there, we had a change of process which moved emphasis much more toward short-term planning. The long-term plans became much more flexible. I would summarise the outcome as
1. The long-term plan is built in 4 hours.
2. It still covers roughly 12--18 months.
3. The plans are adjusted to agree with reality every 5 weeks or so.
4. The long-term plans are still abandoned around 100 % of the time.
5. We now pass up on around 50 % of the more profitable things.
1. There's a few weeks every summer where planning is a major focus, but then evaluating and adapting that plan might take up to half a day a week on average throughout the year. Basically: What assumptions underlie the plan, and have those assumptions changed? Maybe we assumed wrong, or maybe facts changed. So I try to keep an eye out for things that require an adjustment in our direction.
2. I have 10 year goals, 3-5 year milestones, and 1 year plans. I'd like to push that to 18 month plans, but at the moment I only go into any detail for 12 months.
3. Once per year in terms of formally planning the subsequent year.
4. I can't think of a time where I completely abandoned a plan (as opposed to adapting it to changing data).
5. Interesting question. I would argue "never", because if there's a truly more profitable option on the table, then the plan needs to adapt and take that into account. But are we talking about short-term or long-term profitable? I very rarely change my plans in response to short-term opportunities, because that's a great way of killing long-term profitability.