Discussion on:

Use these techniques when you have difficulty properly defining a project

I agree with this point of view and I believe that a crucial issue is to make the client understand that the ball is in their court.

These kind of situations can easily result in failing to meet deadlines, and putting the whole schedule in danger. The client must understand that they have to do their job (and do it well and in a timely manner) in order for the project to go forward.

It is a good idea to explicitly state the assumption that we expect the client will allocate time to carry out this work. And it should also be included in the project's risk list.

Lucas Rodr?guez Cervera - www.nevant.com

Scope at least should be identified before there is a project.

How, When and Who can be managed once you know what, and that is always the client/customers responsibility.

Unless scope has changed it's definition when I was working on soemthing else ?

If the scope isn't clear, and occasionally it won't be, then running a scoping study up front, as a project in its own right, makes a great deal of sense.

The client (whether internal or external) will hopefully see the sense on spending a little money on working out where to go, rather than plunging in and hoping for the best.

but that is not the job of the supplier. Seeing as the article was about making sure the client performs when you are a PM, you only need a PM when the scope is defined. You can fetch in a consultant to help, but it's not a project until the scope is scoped as it were. Well in my not so humble opinion anyway.
We want all our software to efficiently interact with our new export business is a scope. Though a very nebulous requirement
We wish to become more efficient is not.
Scope can narrow or broaden but it has to start somewhere, all a PM can do is tell you whether you are in it or out of it.

Defining the scope of the project is the first step. Without this definition, the project cannot proceed, estimates cannot be done and cost cannot be determined. I have found the following process has worked best for us: facilitate a joint requirements planning session which includes primarily business stakeholders and some IT stakeholders; create use cases from the requirements defined in the session(s); review use cases with all stakeholders. It appears that when they can see something other than words, our stakeholders get more involved.

Hi Mary,
Thank you for the input. I have one question... What is a "use case"?
Also, if possible the first step (in a perfect world) would be to develop your preliminary scope statement FROM the project charter. Although the project manager can be called upon to help create the charter, it is most often created by the project sponsor. The charter defines the project from the sponsor?s point-of-view. Once the charter is completed, it can be discussed with the project manager in order to fully understand the direction of the project prior to completing the preliminary project scope statement. The preliminary scope statement is the project from the project manager's point-of-view.
Your response is highly appreciated!!

Ivar Jacobson came up with the idea of use cases. He actually started this in 1967 already.
You start with an "actor". This can be a person or another system that interacts with yet another person or system. The actor "uses" the other systems/persons.

The other system uses some input from a diversity of sources (and is thus an actor in it's own respect) and has a certain outcome that can be used by the original actor.

A good reading on this is Ivar Jacobson's book "Object Oriented Software Engineering, a use case driven approach" ISBN 0-201-54435-0 Publisher is Addison Wesley. It's a 500+ pages book.

Defining the REAL problem is the first step. Way too often I have seen that a project was well defined, the software was developed and delivered (sometimes even in time)... and the business case was still not solved. Looking back then it made clear that the whole real point was missed altogether by the customer, the PM and the development staff.

Defining the real problem will go a long way to completing the business case that has to be the basis for the project.

In only 20+ years of experience I found that the first and foremost virtue in any type of project is good communication.
Indeed so many customers define their problem in terms of a solution... which NOT nessecarily needs to be the best solution.
If the vision where to go is blurred then the steps to be taken are totally unknown ALWAYS.
So, in my not so humnle opinion the PM should make a point in guiding the customer towards a clear and concise goal. And oh wonders, sometimes it then becomes clear that software is not needed at all or against a much lower price after all.
Bottomline is that good thinking ahead saves lots of money, and that too is a good PM responsibility.

There are some prospective projects that need to be taken out of the abstract and converted to some early implementation - whether a protype, pilot, etc. Many managers can react effectively to something tangible. Rapid Application Development can be extremely useful in this context.

they react by saying that'll do.
RAD was meant to be iterative, but becuase of it's concentration on the front end in most projects, it usually stops there and you end up with QAD. Good old iterative or XP is a better way of getting something of solid quality done.

"That'll do..." is justy good enough for my Border Collies .

What you need to do is use prototyping indeed in the phase where you need to design the screens for the END-USERS.

In my experience working with end users one-on-one asif you work in XP methodology makes prototyping work well enough.
You can then present the work as it is, to a bigger group of end-users and have them shoot at the screens you and other end-users designed.
This also means that in the design phase one should NOT gold plate the screens/forms/reports. Chances are too big that they will change anyway.

RAD and prototyping do NOT work in earlier stages of the project as only for database design, but that is something under the hood that most end-users do not/will not understand.
Hense the advise by many others to develop big projects in small steps.