Where I work (a large, global corporation) a project is usually something that is so large that it requires it's own budget and involves so many different system dependencies that it is unfeasible for different teams to manage between themselves within the normal line of work. A project manager is assigned to it and he or she gets directions from a steering group, and there are multiple milestones to check if the it is ok to proceed to the next stage. Usually, in these situations it also motivated to have an assigned architect, an assign requirement specialist and an assigned test lead to take overall responsibility in coordinating respective areas.

If it happens that the scope is actually not large enough to motivate a project setup, this will be wasteful and inefficient. But if the opposite happens, that the scope is very large but it is not implemented as a project, it can lead to disaster. Typically, the solution will not work end-to-end because no one have had the complete picture.

EDIT: Forgot a word

I spent almost two years on a project of such a nature at a ginormous company in the low 8 figure budget that changed on an almost daily basis and was killed at the last second - in order to start an even larger and looser project, while simultaneously starting a second similar project in insane fashion. Coordination is mostly a hostile battle between high level execs, with lots of promises of this time it will be different and never is. I always question decisions if I can but often you get no access from a technical level to the people deciding (and battling about) what is to be done, so often you can only deal with lower level decisions in your area. Sometimes you win a little but often your winnings are lost in a sea of terrible decision noise.

Then again I've been in tiny companies with low 6 figure budgets for projects and you still wind up powerless to ask the right questions.

Sometimes you have to settle on getting your part of a giant project right and sigh your way through the rest.

The word project has a specific well known meaning in business. It is a work effort with at least these criteria:

* A start date

* An end date. Every project has a termination date, otherwise it is described as something else.

* A stakeholder.

* Business Requirements Document (BRD).

"too much upfront planning" is one thing I've never experienced before. perhaps, you mean wrongful planning or indecision?

I'm not a programmer/dev, however ...

You can plan and plan and plan. Then start and realise that you should have _tried_ earlier because that informs the planning more (close the loop, iterate, go again). That's why prototypes/MVPs are a thing, surely.

I can see how this is possible, but I've never experienced it. On the contrary, I see people just do and do and waste effort and redo because of things that could have easily been foreseen with a plan based on input from all stakeholders. Meaning, yeah, I see someone make a plan on their own and inflict their plan on others, but that is just a bad plan.

It easily develops into subcategory of "wrongful planning". I.e. planning things the people doing the planning do not have the expertise to make decisions about, but they felt like they needed to plan it. And now you're stuck with it, because otherwise someone would have to admit they didn't know what they were doing while justifying a change from the announced plan to the customer. (yes, there's a lot more than that wrong with the situation in that case)

> "too much upfront planning"

Maybe bad assumptions, or a general unwillingness to validate assumptions?

(IE, "Too much planning," not enough iteration / stakeholder feedback.)

Not the GP, but long term plans are at best inaccurate, worst case completely wrong. Plus, you spent all this time planning instead of implementing/discovering.

Both mindsets are necessary, and it's also possible to go too far in both directions. I've been on teams that took planning to an absurd end, which resulted in obsolete plans as soon as implementation started. I've also been on teams which went around in circles because they didn't have any direction and their implementation/discovery wasn't focused on a clear goal.

Long term plans are only inaccurate or wrong if they're over reaching. Plans, like every other part of a project, have to be able to change and grow throughout implementation. It's not long-term planning that is the issue, it's the stagnation of overbearing plans.

> Long term plans are only inaccurate or wrong if they're over reaching.

True, but for me the real problem is actually identifying that ideal amount of planning for some project.

It's easy in hindsight to say something was over reaching or not enough planning was done, but not always that simple prior to starting a project.

Ideal planning vigor and scope seems super context sensitive to me and even with experience I often feel I get it wrong.

There's no such thing as perfection, only the pursuit of perfection.

Hindsight is a crucial part of making sure you don't make the same mistakes. Don't worry, you'll have plenty of opportunities to make brand new mistakes.

Funny you say that. The way it goes with my boss is :

- boss: Yeah, don't spend too much time on planning it will be at best inaccaurate

- me: ok; I make a plan and, well, there are known unknows

- later on, my boss: why have you those unknowns ? don't you think it's obvious that unknowns are a problem and that we can't show our customer we have unknowns because we're-professionals-we-know-what-we-do ?

- me: err... well...

I think you've gotta put yourself in the customer's shoes. If you ask a vendor when a project will be done, and they respond "well we have some unknowns haha", what are you supposed to do with that? It's not a very useful answer.

"Here's what we've accomplished this month. Would you like to continue the engagement for another month?" Better than lying about knowledge of the future.

They're inaccurate, but they're fundamentally fate altering when you can put some pieces of information together to generate a non-obvious conclusion that prevents a huge disaster. Good planning is not about assuming something works, that's where most of the time the plan is wrong, it is to assume something doesn't work, and what can be done to forge ahead in such a case. Good planning is also revising plans any time new information is learned.

Technically, project is any task with a start or an end...