Jacob Sparre Andersen skrev:
> Rune Allnor wrote:
>
> > While no one knows everything that will happen in the future, I do
> > agree with you that changes in goals should be avoided, as far as
> > possible, during project lifetime.
>
> But there is a significant class of projects - at least in failure
> visibility - where you beforehand can be practically certain that the
> goals will change during the project lifetime: Projects which shold
> manage public sector policies (i.e. payment of unemployment benefits,
> health insurance, taxes, ...)

Do such activities satisfy the definition of of a project?
As far as I remember, a project is defined as something like

"An activity with a priori specified goals and resources,
that takes place once, and that is of limited duration."

The activites you describe seem to be programs, to me. Somehow,
I have the impression that the words "project" and "activity"
are on their way to become synonyms.

I prefer to stick to the definition of a project, with a priori
known goals and resources, and handle the changes as "deviations
from plans". Labeling the changes like that, may put some pressure
on planners to get their estimates right the next time, or make
them choose to organize the activity as something other than a
project.

> PS: Isn't this discussion a little bit off-topic for "comp.arch.fpga"
> and "comp.dsp"?

I don't know about comp.arch.fpga, but the last few weeks the
threads on comp.dsp have not been all that on-topic, not least
thanks to me.

Every now and then, threads of more "philosophical" nature occur.
I think project organization and company policy are very important
parts of engineering projects these days. Every now and then,
such questions, rather than technology, are the roots of the
problems. I don't necessarily see this thread as off topic, what
comp.dsp is concerned.

But then, I'm a major contributor to the noise on comp.dsp.

> »What fun is it being "cool" if you can't wear a sombrero?«

Indeed.

Rune