Forum OpenACS Development: Re: Preliminary vision statement open for discussion
I've found this article on the MS Project 2000 Database Format. Describes a bit about the MS Project datamodel... even has a bit on calendar data. I'm not suggesting to use this datamodel, but to keep it in the back of our minds for when we decide to import/export MS Project data using XML. MS Project allows project data to be exported to XML. I can't find the XML schema just yet, but this will allow us to import MS Project data into our proposed "project repository", and conversely export to MS Project.
Someone mentioned are we planning to replace MS Project. In short... no we are not. MS Project is an application used by PMs to schedule, plan and monitor a project. But is it the right tool to be used by all members of a project team? The project tools that we want to develop for dotWRK should allow project team members to update their "actual" progress. This will allow the PM to compare the differences between "estimated" duration and "actual" duration, and if the project is not on track, then the PM can take the appropriate course of action to get the project back on track. With this sort of project reporting (from team members) at a micro level, the PM is able to estimate Earned Value more accurately as well. This kind of feature will make the dotWRK PM tools quite powerful, as the progress of a project becomes more transparent.
My vision of the PM tools for dotWRK is a fully integrated suite of PM tools. This can be achieved through a unified data model, as proposed for the "project repository" package. There are very few PM tools that are fully integrated. Those that have used Rational tools will know where I am coming from, as they are not fully integrated, and do not exchange data between applications very well. (A possible marketing avenue to explore?)
In designing the project repository package, we need to establish a datamodel that will encompass all data associated with a project. Secondly, an API needs to be designed to allow other applications to retrieve or modify project data. Finally, we need a web interface to administer this package, with sample use cases such as creating and initiating a project. I'm working on a project specification document that will better explain the purpose of this package.
Cheers,
Nick.
Sorry if the below sounds a bit like a rant - it's not meant that way :)
""" In short... no we are not. """
I agree, but for different reasons.
"""MS Project is an application used by PMs to schedule, plan and monitor a project. """
And that is indeed the job of the PM, although I'd say replace 'monitor' with 'control'.
""" But is it the right tool to be used by all members of a project team?"""
No - and they're not supposed to. The tools in the kit that are for 'them' are things like documentrepository, (collaborative) todo/task-lists, timekeeping, perhaps chat/forum/wiki.
The wbs, scheduler and nice views are for the pm to maintain. They may see them of course, but should not touch them.
""" The project tools that we want to develop for dotWRK should allow project team members to update their "actual" progress. This will allow the PM to compare the differences between "estimated" duration and "actual" duration, """
That won't happen. Only way you can get project members to report accurately is to link it with the timekeeping system and link the timekeeping system with their payroll. And even then :(
""" and if the project is not on track, then the PM can take the appropriate course of action to get the project back on track. With this sort of project reporting (from team members) at a micro level, the PM is able to estimate Earned Value more accurately as well. """
How many projects did you lead where 'reporting at a micro-lvel' actually worked? In my experience pm is 80% communication. If you /need/ the tools to tell you what went wrong, you should not've been the pm in the first place imo.
For that particular reason it's important to keep projectteam size within you max. span of control - typically not more than 10-15 people (for an experienced pm that is). If it gets bigger, divide in subteams and manage the subteams/subprojects, not the people or the whole project. And at that stage you get a project that consists of interdependent subprojects, where the teamleaders maintain their own schedule, which you incorporate in the main one.
""" This kind of feature will make the dotWRK PM tools quite powerful, as the progress of a project becomes more transparent. """
A clear plan of approach, good reporting, having a well maintained risk register make them transparant. Micro-level updated GANT-charts don't.
Then why do I agree with "we're not replacing ms-project":
- indeed because of the collaboration-angle
- and it's too bloated. Having a good foundation on top of which we can build more advanced stuff later (i.e. when there's actually demand for the advanced stuff) is far more valuable imo then the everything-but-the-kitchen-sink approach.
It seems to me, with my limited experience in project management that we have a structure like this:
Project A - Manager AA
Project B - Manager BB
Project C - Manager CC
Inside Project A:
Start date: April 1, 2003
End date: June 1, 2003
List of subprojects:
Subproject a
Subproject b
Subproject c
List of tasks/tickets:
Task aa - assigned to abc, deadline April 15, 2003
Task bb - assigned to bcd, deadline April 30, 2003
Task cc - assigned to cde, deadline May 15, 2003
Dependencies:
Task bb can't be completed until Task aa is completed.
Each employee has a list of tasks/tickets. They work from those tickets, and have the ability to update the deadlines (of course this sends an email notice to their manager and anybody who has tasks dependent on theirs).
Whenever they close their tasks, or change the deadlines, they make comments on what they've done. This is in fact micro-level updating, and not by the managers. The managers are certainly able to do this, but the team members themselves are able to manage their tasks.
The managers thus get a list of projects, and can look at gant charts, see what's happening on each project, etc.
The employees get a list of their tasks, and they can click on them to see more information about the project, and what depends on their task being completed. The employees work from their task list/ticket list, and mark each task as closed when it is completed.
Does this make sense as a work case scenario?
I'm pretty new to formal project management, but this is the scenario we're thinking of at my place of employment.
We're already doing this using the old ACS 3.4 intranet, and it works okay, but it needs to be reworked greatly to REALLY do project management the way we'd like.
