[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Help With Project
From:       Brad Hards <bhards () bigpond ! net ! au>
Date:       2001-06-13 6:30:19
[Download RAW message or body]

David Faure wrote:
<smip>
> As a former project manager, I had to create project plannings
> (with ms project). This is an activity one does alone, much like editing
> a word-processing document or a spreadsheet. It has not much to do with
> PIM and interacting with other people etc. Of the course the actual project
> is about other people, but the creation of the planning itself isn't.

I am no KDE developer (a mere luser, at best), but I am still willing to offer
some views on this, since project management tools are a professional and
personal interest. Sorry if this turns into a rant :)


Project management tools in context.
Project managers almost never want to create all those plans and schedules and
such. But they do so anyway. Why? For three basic reasons:
* They are compelled to. Higher management wants to see plans, schedules,
Gantt charts and progress. This provides higher management with the illusion
that things are under control.
* To provide direction for subordinates. This is essentially the same
principle as the first point, but the illusion is on behalf of the project
manager :) The concept here is that the project plan is used as a
communication tool.
* As a useful tool for making decisions. This tends to be mainly the
providence of inexperienced project managers, who often believe that the
guesses that they put into the plan actually have more meaning when they come
out of the toolset. More experienced project managers tend to rely on
professional judgement.

In my experience (mainly in military / defence projects, probably indicative
for organisations with heavy management structures and project durations in
months to years), those reasons are listed in order of decreasing importance
_to the user_.


The concept of Risk.
A Risk is an impact to a project. Another poster tried to capture this in
probablistic terms for durations, which is part of what I understand as a
Risk. It is somewhat difficult to explain Risk in a few words, but I'll give
it a try.

Normally people break Risk down into a probablility of occurence, and a
consequence of occurence. As an example, a risk for the KProject development
would be "Some freaking moron writes down a whole mess of stuff about
requirements, risks and context, and lots of developers decide that it is all
too hard, and go off to write an Adobe Acrobat replacement instead". The
probability of that happening is a number between 0 and 1 (or 0% and 100%, if
you like), and the impact on the project is probably a delay of X months in
releasing the first beta.

Risks don't always affect schedule (or just schedule). Depending on the
project type, you might measure risks in terms of "product quality" or
"supportability" or "dollar cost", or whatever metric is meaningful to that
particular project. Note that Risk is not always to the detriment of the
project outcome, or is in the same direction for each way of measuring Risk.
For example, a Risk might be "Someone posts a pointer to an obscure, already
coded and GPL'd scheduling algorithm that is provably optimal". That might
reduce the schedule (or increase it, depending on when it the pointer gets
posted, since you may have to rearchitect the whole toolset), might improve
performance, but might be really difficult to understand, and therefore reduce
supportability. 

So why is Risk important? Without some Risk analysis, the project plan is only
one expectation of the future. Given that the future has essentially infinite
possible outcomes, then the probability that the plan is right tends to zero.
Also, Risk assessment is really important for knowing which things you need to
manage closely, and which things can pretty much be left to themselves. In
certain applications, you can use Risk assessments to bid for "contingency"
funding, so you can fund rectification when things go wrong (which they will,
no matter how closely you manage the project).


So what does all this mean for KDE / KProject?
Based on all of the above, it is important that:
1. I can embed KProject outputs into other documents, and that you can use
other documents as input sources. In particular, it is important that I can
display schedule information (especially Gantt charts) in KWord and
KPresenter, and that I can source information (like costs and availability of
resources like people, test equipment, etc) from other applications and from
other KProject documents and a central database (remember that while
individual project manglers do their own planning for their project, it is
quite rare that they have sole use of all the necesary resources).

2. That I can automatically export tasks through kmail or kde-pim or whatever
(ideally to people using other apps, not just KDE ones), and that task
completion by whoever is assigned the task automatically (or with verification
by the project manager) updates the project plan to show progress against the
plan. This is important because updating the schedule becomes a huge drag on
any real sized project, and is often the reason for not using a finely grained
work breakdown structure.

3. That I can assign arbitrary risk categories (with schedule as a default)
and assign risks at any level in the work breakdown structure, from the whole
project to a single task, and get reports on total project risk.

In addition, it would be good if:
4. I could apply some Manufacturing Resource Planning (MRP / MRPII) techniques
(see
http://www.sei.cmu.edu/publications/documents/99.reports/99tn015/99tn015abstract.html
or just put it into Google). In particular, I'd like to be able to pull up
"standard modules" of work as a task, although a full MRPII system would be
nice :).

5. I could assign "skillset" attributes to people. For example, in a previous
job as a workshop production planner, we had around 200 people who fixed
around 700 different avionics components that we had to repair/overhaul. It
would be good to be able to ask for "people with spare capacity who are
trained on fixing HF couplers". Even better would be some form of constraints
approach, where I could say "I need to generate 18 stabilised platform units,
4 navigation computers, 1 HF coupler, 2 Pavetack pods, 3 TFR computers and 2
TFR displays; now assign the available people to optimise delivery schedule".
Now fixing avionics boxes is a lot like programming, and avionics techs aren't
plug-compatible any more than programmers are, but either you can add some
form of "efficiency factor", or (probably even better) you can ignore it in
the optimisation run, and just tweak it afterwards.


Where to from here?
I'd be more than happy to clarify any of this, if needed. This email is
Copyright (C) 2001, Brad Hards, and is released for any use relevant to KDE or
any other open-source development.

HTH
Brad

[prev in list] [next in list] [prev in thread] [next in thread]