[kplato] hierarchical project management (was: idea)

[Raphael Langerhorst]

On Saturday 22 January 2005 17:56, angeleyes at tvcablenet.be wrote:
> Hi,
>
> I'm actually busy to prepare a project.
> One idea appears in my head due to a real problem in a project
> manager.
>
> Could you integrate the following idea in kplato ?
> Imagine I have a project composed of several modules. Each modules
> depends of the end of the previous one. Then if a module need more
> time that prepared on a schedule we must move all the followed
> modules in the schedule. What a job. Then I think you could preview
> this situation and then if a module has a modified target date then
> it could (if configured as well) move all the next modules in the
> schedule. (it could also be able to automatically send an e-mail to
> a list of members given in the project contact as man who depends
> of the end of the project to inform them that due to some
> (configured text message) ... the project target date is reported
> to ...this date. And you could also prepare this idea (wich is
> better). Define a list of people by module for the project. Define
> who is responsible (more than one people) the module. Then the
> responsible (peoples) are able to modify the time length and also
> some informations about the project. The other member of the
> modules are just inform or can just look to the module evolution.
> There is also a list of people for the project. Also some are able
> to modify project information and others members can only be
> informed or look the evolution of the project without modify it.
> Then You could also consider that if no module member people are
> inserted in the module member list then the member project people
> list will give the people that are able to be informed and look
> each module evolution.
> Otherwise if a module need more time when the target date is
> modified by a people of the responsible module list then each
> responsible of the next module will be informed that the beginning
> of their module will begin later and all the other project and
> modules people will be informed that the target date has moved.
>
> It will be an improvement of the project management. Then a manager
> just need to modify a target date of a module and then all the work
> (module planning will switch in the schedule if asked in the
> project configuration other wise it doesn't move) and people will
> be informed automatically by e-mail given in the list (responsible
> people could receive technical informations about modification and
> other members coulds receive other information. Then if a module or
> project responsible modify a beginning or target date of a module
> he will receive a popup form asking the text to send for project,
> module responsible and another to give the text to send to the
> member of project, module).
>
> Thanks to read this and sorry for my bad english.
>
> See the attached file to see the idea.
>
> Bye

Hello!

I hope I understand what you mean. I think there are more ideas in 
your suggestion that we can elaborate on individually. Most of these 
ideas are probably necessary to make KPlato suitable for large-scale 
projects with many individual subprojects (modules!). This includes 
automated information flow, as well as automated rescheduling and 
synchronizing with subprojects. I also see some of the required 
infrastructure already present in KPlato.

You suggest some kind of hierarchical project management with 
half-automated information flow. I think this can be done with 
extending the current infrastructure of KPlato to allow each task to 
be a separate project  (what you call module) and start/end dates and 
project members of  this module can be synchronized with the project. 
So the parent project only knows the summary about each module wheras 
each module is again a full project with subprojects, ...

So far I can think about these requirements:

1) Definition of external tasks/projects
It should be possible to define a task as an external project. The 
external project is a full KPlato project itself with its own 
resources and tasks, etc.

2) Notification about changes
It should be possible to automatically send notifications for:
  * project members of this project
  * project managers of affected modules
You had three different types of notifications, do you think you could 
do with these two? Or you should express more clearly what the 
difference is between your suggestions (or I didn't understand it 
completely).
The notification must also notify the subproject "as such". This could 
either be through the notification of the project manager who must 
then approve the suggested change or be a separate notification(?).
The notification mechanism could be an email with a certain defined 
structure which is then readable by humans as well as the KPlato 
application (other suggestions for the mechanism are welcome).

3) Changing dates and resources of external projects
It should be possible to change Start/End dates of external 
subprojects and these changes should be propagated through some 
notification mechanism (see section 2), only if the project manager 
of the subproject has changed the schedule, the change takes effect 
in the parent project.

4) Synchronization
There needs to be a synchronization mechanism to propagate the 
information / summary about subprojects upstream to parent projects. 
This could either be done through loading the file of the subproject 
in the main project and reading the required information, or through 
other notification mechanisms (for example like in section 2 through 
emails).


Summary:
Through this mechanism a hierarchical project structure would be 
possible where each project hides all complexity to the parent 
project. Also notifications make sure that requested or performed 
changes are propagated.


What do you think about these requirements - or wishlist? Would this 
provide your desired functionality? Please add additional 
requirements if you still have any. I think when we finally have a 
list of requirements (which we think are generally *possible* to 
implement) we can file these things as wishlists for KPlato on 
http://bugs.kde.org


Regards,
-- 
Raphael Langerhorst, JID: raphael at jabber.pilgerer.de
G System, The Evolving Universe - http://www.g-system.at