hierarchical project management (was: idea)
Raphael Langerhorst <[email protected]> Tue, 25 Jan 2005 15:56:20 +0100
| Newsgroups | gmane.comp.kde.kplato |
|---|---|
| Message-ID | <[email protected]> |
On Saturday 22 January 2005 17:56, [email protected] 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: [email protected] G System, The Evolving Universe - http://www.g-system.at