Scheduling with weak dependencies

[Bradley L]

I'm working with an organization that has very weak dependencies
between its deliverables. For instance, though the technical design
theoretically ought to wait for the completion of the requirements, it
oftens begins prior to that point as the architects begin to get a
flavor of the system.

What's the best way to schedule in this situation? Obviously, I can
build dependancies based on the theoretical project flow, but since it
doesn't reflect reality, what's the point? On the other hand, because
the initiation of tasks is informal, it's very difficult to predict
when they will start.

 

[davegb]

I'm working with an organization that has very weak dependencies
between its deliverables. For instance, though the technical design
theoretically ought to wait for the completion of the requirements, it
oftens begins prior to that point as the architects begin to get a
flavor of the system.

What's the best way to schedule in this situation? Obviously, I can
build dependancies based on the theoretical project flow, but since it
doesn't reflect reality, what's the point? On the other hand, because
the initiation of tasks is informal, it's very difficult to predict
when they will start.

This is a great illustration of the consequences of using Project and
doing serious scheduling. It quickly illuminates poor Project
Management practices. Your problem can't be solved at the scheduling
level, because it's a Project Management problem. It's a level above
scheduling in your organization's process. It's like a company that
makes low quality nails because they use low quality steel trying to
improve the process they make them by to fix the quality problem.
Can't be done.

To nearly quote Lewis in "Project Planning, Scheduling and Control",
"Giving an organization that knows nothing about Project Management
sophisticated scheduling software merely enables them to document
their failures accurately". What your organization needs is someone
who understands Project Management and an initiative to change.
Without some sort of structured approach to your projects, you won't
be able to implement a process, scheduling, that depends on
structure.

My guess is that you're also seeing a lot of rework as a result of
"oftens begins prior to that point as the architects begin to get a
flavor of the system." And other fairly predictable problems as well.

Hope this helps in your world.

 

[Steve House]

Adding a bit to Dave's response, it seems the flow of planning information
is moving the wrong direction in your organization. You shouldn't use
Project to try to predict when a resource will start an activity. Instead
use it so that the person responsible for steering the project to a
successful completion is able to tell the resource when they need to begin
working on an activity in order to meet the organization's business
objectives. Scheduling information flows from the planner to the resource,
not the other way around. The paradigm shift you need to manage is that
task scheduling must move from informal to formal with the schedule being
driven by the needs of the project rather than by the initiative of the
resources.

In your example, the planner should know enough about the workflow to know
if it is even possible for the technical design to begin before the
requirements documents are complete and if it is, the amount of overlap
possible should be built into the link between the two tasks by way of a
lead time.

 

[Jan De Messemaeker]

Hi,

I would set teh tasks small enough to allow for proper linking.
"The architects have a flavour" is generally the result of a first part of a
design task.
That can be the base for a proper link.
Hope this helps,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf

 

[Dave]

I'm working with an organization that has very weak dependencies
between its deliverables. For instance, though the technical design
theoretically ought to wait for the completion of the requirements, it
oftens begins prior to that point as the architects begin to get a
flavor of the system.

What's the best way to schedule in this situation? Obviously, I can
build dependancies based on the theoretical project flow, but since it
doesn't reflect reality, what's the point? On the other hand, because
the initiation of tasks is informal, it's very difficult to predict
when they will start.

Essentially this question is about risk management. Clearly, it is not
necessarily the case that the requirements have to be absolutely
finished before you can start on the technical design (those that doubt
that might like to consider what the risk is in starting 1 day, 2 days,
1 week before the completion of the requirements).

However, in starting the work early there is *some* risk and that has to
be managed by rigorous version control and ensuring that there is time
set aside to review the final version of requirements and assessing
whether or not any of the subsequent modifications have affected the
design work that has taken place.

In many real world situations, resources may be available today and you
either have the choice of using them and managing the risk or losing
them for a period. Whether or not you take that risk depends on what
harm would be arise from sticking out for the holy grail of completed
requirements.

Jan's approach is as always good. The problem is actually how to
describe the sub tasks leading to the requirements capture (in this
example) and their quality criteria so that it is decidable when they
are finished. One person's 'familiarisation' is another person's
architectural picture.

However, if you can partition the requirements into largely disjoint
areas and do something similar with the technical design then you can
achieve something along the lines you want. By having more complex
linking arrangements. This is of course more work for the Project
Manager, but this doesn't come free.

There may also be other constraints which allow you to do work early.
You may for example intend to build from an existing platform, or have a
certain sort of technology you would want to use or have a sufficiently
good understanding of physical or infrastructure or security constraints
to allow work to start.

Ultimately, it depends on how well you can actually model the process
you are using.