Project Characterised by Major Ambiguity and Uncertainty

[Paul]

Hi,



Would be grateful for any advice re a project I am about to start planning &
scheduling.



The project is one of those "innovation" type "projects" i.e. where the
objectives are very unclear and what is to be done is unclear (lots of
uncertainty and ambiguity). more a give a few things a go and take it as it
comes type of affair. Also most of the tasks are difficult to define and so
the amount of "Work" isn't what is really driving the schedule (eg We'll be
telling a couple of analysts to work on requirements for a couple of weeks
to see what they can come up with rather than thinking that there is 20 days
of work on requirements so 2 people can do it in 10 elapsed days).



I am also quite keen to "time-box" so want to see what we can do in 2 months
and then take stock.



My approach is to do the following:



Set all the tasks to default to fixed duration and use these fixed durations
to drive the scheduling.. But then I want to fix the end date, define the
project logic (ie dependencies/critical path) and schedule backwards from
the end date.



I hope this would give us a tool where we could play "what-if scenarios" (eg
what if we make the requirements shorter, what if we did a shorter build
phase etc!)



My questions are: 1. Is this a sensible approach for this type of problem,
2. What type of dependencies etc do I need to use to get it to schedule
backwards from an end date (I am used to scheduling forwards!) 3. do I need
to set effort driven = no? and finally are there any other
approaches/suggestions for doing this type of "project" where the "bridge is
being constructed as you walk on it" and where there is little past
experience to base durations and best approach on?



Hope this makes some, grateful for any thoughts.



Thanks



Paul

 

[Rod Gill]

I would go totally agile for this project, don't even think of traditional
critical path etc for the whole project.

I assume you have an IWiKIWISI customer? [I Will Know It When I See IT] If
so I would do an evolving prototype method. Start by brainstorming the wins
any stakeholder might get and then the losses any stakeholder might get if
the project fails. The wins are your business deliverables, the losses your
business risks.

Now split the project into a number of iterations (10-20), each of a fixed
number of weeks (1-4 is good)

The first iteration is brainstorming ideas and developing a very high level
approach and architecture.

Iteration 2 must start delivering a prototype. If the project is software
development then write production quality code for the prototype because it
will evolve into the final product.

Have a key customer or two constantly available and constantly evaluating
and providing feedback on the prototype: no customer involvement then no
project! Present the prototype to all stakeholders at the end of every
iteration. Stakeholders and management get to agree what will be in the next
iteration, but stick to the iteration's fixed duration as much as possible.
Reserve the last iteration or two for system testing and de-bugging and
releasing.

Use Project to schedule each iteration to make sure you finish on time and
to know when to cut functionality if too much has been asked for in an
iteration. If it's important enough move it to the next iteration. Do
highest risk goals in the earliest iteration possible.

By all means look at the critical path for the current iteration, but no
more than that. I would stick to Fixed Units and Effort driven off. These
are the most flexible settings and the ones I use almost exclusively. I only
change task type for individual edits of assignments.

The most important documentation is the business case and user instructions.
This is an evolving prototype and the customer can change direction every
iteration or cancel the project or say "That's enough for now we'll run with
what we have for a while". Remember the Poppendieck's quote: "80% of people
use only 20% of features", so if you can code just the 20% you can finish
80% quicker!!

 

[Steve House [Project MVP]]

I've got a problem with that approach in that you have no way of knowing if
you're on the right track or not viz-a-viz your organization's buiness
objectives and strategy. It almost seems like you're trying to say you
define the project's outcomes on how much work you can afford to devote to
new development instead of deciding what you should develop and whether it
fits into the company's long term strategy. Work drives the schedule when
you know what it is you want toi accomplish. But it sounds like you're
saying "we can afford to do 500 hours of work, what could we do with it?"
letting the affordable work define the objective and calling that a project.
HOW to accomplish an objective may very well be a moving target in
innovative endeavors, that's why a phased apporach to scheduling can be a
good idea. But it seems to me that clearly defining the objective itself -
in concrete, quantifiable, objective terms - and making a go/no-go decision
based on whether it contributes to the long term strategy of the firm simply
must be a prelude to anthing else. (Just because you can do something it
doesn't mean you should do it.)