[kplato] Functional Breakdown (comments)

[Brad Hards]

Jim Sabatke wrote:
> 
> By making a task, or tasks, into a seperate project, they could easily
> be dependencies in multiple projects.  The WBS codes would probably be
> different, so they would have to be computed when the project is loaded.
>  Come to think of it. WBS codes would change everytime tasks are
> inserted or deleted, even in a project with no sub-projects.
Lets look at a couple of non-programming examples.
Remember that each project has (typically) a single project manager, with
certain control and span of authority. 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 :)

Comments?