In vast majority of cases yes. Maybe even in all of them. Even when there's no scrum master or anyone else playing the role of project manager. But you can get answers like that:

> Are We Done?
- Nope.

> When will we be Done?
- God knows. We've planned for 9 months and it looks like we're going as we planned but it hard to say for sure since it's still impossible to do any end to end test with any hardware.

> What will it cost when we are Done?
- Amount of time spent on the project multiplied be the salary of a developer working on it.

> What does Done look like for the customer?
- There's hardly a customer for that at the moment. Actually when there is a customer they won't see any functional difference between current and future application behavior.

> How can we recognize Done when it arrives?
- We'll be able setup our application in specified scenarios on a Linux machine (instead a Windows one)

> How can we be sure we can get to from here Done?
- We can't be sure. That should be feasible as proper analysis was done, and technically we see no blockers at the moment. However as we learned from the history vendor of our hardware doesn't always support each function on both platforms.

> What are the impediments to getting to done?
- At the moment none.

And for me in specific environment:
- It's a good plan
- You need no project manager or project management methodology whatsoever to complete the "project."

And yes, the example is real. Work was completed successfully and on time. I wouldn't say we had a methodology supporting the process. Answers to your questions were in our heads although no one asked them loudly to make it more formal/proper/whatever.

If you asked Google or 3M engineer working on her 20%/15% project what's her project management methodology she'd answer "none." If you asked her your questions she'd be able to answer them although answers would be probably as vague as in above example. That doesn't mean it's managed poorly. Management is proper to its size and maturity.

I don’t say you shouldn’t manage a team at all. If your team is doing a couple of big projects and in the meantime you have a few small tasks to do (e.g. patch requests or change request as we used to call them) you won’t be able to succeed if you don’t plan these small projects in any way.

If your team is 100% loaded with big projects you either won’t complete patch requests or will have a slip in main tasks.

However if you’re lucky enough you can spend one of your experienced developers to work on small tasks only you probably don’t have to manage this project. Or do you?

Of course when estimating tasks one should never assume that resources will be available 100% of work time. There will happen something unexpected or a developer will have to help his colleagues or discussion in the kitchen will be so fascinating it will take a couple of hours. Anyway with patch request you most likely has your estimates already agreed with the customer so the thing you can (and should) do is to verify whether your estimates were good and adjust them another time if needed.

One way to handle it was to only make the core developers 70% available, another way was to dedicate individuals to maintenance, while the new important project retained dedicated talent. Having too much invisible work will impact your ability to keep on-track with deadlines for your more strategic projects.

As for those large architectural changes, the only sane way to make those changes is to phase them in incrementally. That way, they do eventually get done and you can track the investment against potentially competitive or supporting objectives. A by-product of tracking projects is that it demonstrates to your project teams that the team can simultaneously handle operational and strategic demand, which should increase morale and retention.

I remember when I changed a job once and I came to a completely different environment. I had to change my visions to implement old, well-known MSF since it was irrelevant in that company. Anyway it was an eye-opener for me.

I agree with you. Too often people in the project management profession focus too much on methodology. The last time I checked, there were no PM methodologies used in WWII, founding MSFT or executing 9/11.

There were clear and compelling goals that clarified what people needed to do and people did what they needed to do. I suppose of someone wants to call having a clear and compelling goal a methodology, they can.

There’s a saying in America: “he put the cart before the horse.” Personally, I think people who spend too much time agonizing over methodologies are over analyzing the cart when they really should be hitching up the horse.

They end up with too much cart that they’ve put in front of too little horse.

I see the point although that's not something we usually consider as the project management methodology. We think more about what activities we should exercise than how we define Done. You can go with a piece of paper with a couple of requirements and have all the rest in a head of a developer and it would fit your definition. I guess we wouldn't find many people calling that a project management methodology.

Talking about R&D projects I included only a part of them on purpose. There are big full-blown R&D programs which often need more careful project management than standard commercial projects. On the other hand there are tasks which:
- are about to check some technology or to develop some low-priority high-potential application in spare time of a group of developers
- aren't restricted in any way as they're rather a part of company culture than a focused effort (Google 20% projects fits there)
Then it's hard to define Done, because project-wise goals are vague. The real goal is somewhere else: to learn something, to check feasibility of some idea or to make developers more happy. There's no need to treat these tasks as standard projects because they're completely different.