Description |
Take the mythical XYZZY corporation
-
they make toys and sports products.
It has a few different people:
Abigail, who is the Managing Director;
Bob, one of the five design team leaders (the others: Bill,
Brian, Bette and
Bruce (his real name is Eric, but he's Australian:)
Charlie, the financial controller
Deb, who is in charge of marketing
Edward, who is running internal production
Fran, who runs the logistics team (warehousing, distribution
and materials
sourcing)
So Bob,
who has just been assigned responsibility for development
of a new
scooter with a V8 motor, is probably a mechanical engineer
turned manager, and
is busy trying to assign his design engineers, drafters and
test equipment to
get the widget out in the time frame. He gets out kplato 1.0,
opens the
document that has all his existing work, looks at the existing
tasks, figures
out who can be re-assigned (full or part time), and builds
an outline of the
work tasks that he needs to accomplish to get the scooter
design done as a new
WBS element.
Bob then
calls a meeting, explains the new tasks to the relevant people,
and
assigns tasks using the kplato to KDE-PIM interface. When
an individual,
lowest level WBS element is completed by whoever it is assigned
to, the
KDE-PIM interface updates the kplato document, automatically.
Deb knows
that a V8 scooter is going to take some serious selling in
the
safety conscious marketplace, and decides that she needs to
sort out how it is
going to fit in to all the other marketing she has to do.
She also uses kplato
1.0, and links across to Bob's document to see when things
are going to be
finished with the design, since that is the earliest a prototype
will be
available.
[ This means that one part of Bob's project ("running
the team") becomes a
constraint on Deb's project. I'd consider that this means
that Bob's project
is a sub-project to Deb's project]
One of
the outputs of the scooter design that will come from Bob's
team will
be a Bill of Materials, that lists all the things that it
takes to make one
scooter. This goes to Fran, who has to get the materials,
and to Edward, who
has to assemble the scooters. Edward will also get some other
drawings, and
some assembly instructions.
Edward,
who is something of a geekboy, is running the new kplato 1.3
release.
Edward has the ability to insert the various assembly steps
and the Bill of
Materials into his kplato document, and has some extra interfacing
code that
looks at the current inventory status (maintained as a legacy
PostgresSQL
database by Fran's team, althought Edward hopes for inventory
management in
the upcoming kplato 1.4 release), the machine capacity and
the required
production numbers (from Deb's KSpread document), and can
then schedule all
those resources using kplato's constraint fitting algorithms
and a lot of CPU
cycles.
[This means that you need to be able to insert "modular"
work packages into
higher level documents. Those work packages are sub-tasks,
held as seperate
definitions, but instantiated as part of Edward's kplato document.]
Deb can
now take the production schedule from Edward's kplato document
(even
if Deb's 1.0 release can't see all the fancy work behind Edward's
1.3 release,
Deb can still get the fundamental schedule out) and schedule
the "rollout" of
the sales promotions and give-aways as part of her document.
[This means that Deb's database now has multiple constraints,
one based on
Bob's prototype delivery, and several based on Edward's production
runs.]
Charlie
can access the kplato documents of Bob, Fran and Edward to
determine
spend spread (when the dollars go out the door) for prototyping
materials and
equipment, raw materials, and consumables respectively. He
can then access the
kplato document of Deb, to see when the revenue is supposed
to come in from
sales. If this shows a problem, then they can all get together,
replan, and
resolve the problem. [ This means that Bob's, Fran's, Edward's
and Deb's
projects are probably sub-projects of Charlie's KSpread document,
since
extracting constraints isn't any different to extracting costs]
Abigail,
who isn't too good on kplato scheduling, but does like the
quality of
the Gantt chart layout, sends email to some of the people,
and gets some
dates, extracted by hand, from each of the other kplato documents.
These are
then cut'n'pasted into kplato, and the output chart is then
linked into
KPresenter, for a presentation to the Board. After she does
the kplato course,
she will know that it is possible to extract the dates automatically
and have
them linked. But she won't, since email is less work than
sorting through the
detail, and Managing Director's are like that :)
1. Plan
out the entire network at a high level of detail.
2. Do the detailed breakdown and assignment of resources for
the next six
months (as this about as far ahead as I can accurately guess
resources)
3. For the rest of the high level, I would assign estimated
duration based on
experience (i.e. other projects of similar size), and assign
a risk that
indicates my confidence in that estimate.
In order
to be able to do that we need to be able to associate a
risk/duration with a task alone. One way around this would
be to assign a
default resource to a task if there isn't one. We could then
enforce the
constraint that only task/resource pairings have durations
and risks (come to
think of it this is a good idea, and could solve some other
problems I see
arising).
I need
to do some thinking about this, because there are a few problems
to
solve:
1) The
constraint that assigned risk (calculated is another matter)
only
exists in a task/resource pairing.
2) An
effort is associated with a class of resources; i.e. adding
a computer
doesn't affect the number of man hours available.
3) Technically
a task alone does not have an effort (effort is assigned time,
duration is calculated time). Example "Develop x module"
requires 150
manhours -- this only makes sense if a developer is assigned.
|