Specifying Projects (not just IT related)

[jamesrw]

Hello, just a work question for people who project manage things. To what granularity do you specify projects that your company does?

I'm finding at the moment I can't do things too detailed, to the exact thing because a lot of the time the clients I'm dealing with can't really visualise how things might turn out and don't necessarily want to agree to something.

Then on the other hand, if the requirements are too broad, I'm wasting too much of the budgeted time as I'm being messed around until they decide it's how they want it?

And for example how would you gauge whether or not something should be done even though it's not in the spec (however small)

I'm sure this is common so could someone please advise?

Thanks,

James

 

[DAVEM]

Hello, just a work question for people who project manage things. To what granularity do you specify projects that your company does?

I'm finding at the moment I can't do things too detailed, to the exact thing because a lot of the time the clients I'm dealing with can't really visualise how things might turn out and don't necessarily want to agree to something.

Then on the other hand, if the requirements are too broad, I'm wasting too much of the budgeted time as I'm being messed around until they decide it's how they want it?

And for example how would you gauge whether or not something should be done even though it's not in the spec (however small)

I'm sure this is common so could someone please advise?

Thanks,

James

Well it always comes down to a risk vs. benefit analysis IMO.

A project that is out of scope often has a higher dividend.

There are benefits in consolidating a project with your current portofilio and this should be considered.

In a wider sense you can take a few examples... if your a major bank, and you see a change to perchase an insurance company you are basically doing horizontal expansion, hence lower risk.

but at the same time you might have the chance to purchase a publishing company. It's higher risk as it's outside your knowledge base, but may have the potential of excellent returns.

Then you accept a project outside your area, then make sure you have relevent expertise to help.
David