Forum OpenACS Development: Re: Preliminary vision statement open for discussion

Collapse
33: Re: Preliminary vision statement open for discussion (response to 32)
Posted by Jeroen van Dongen on 03/18/03 08:50 AM
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.

Collapse
41: Re: Preliminary vision statement open for discussion (response to 33)
Posted by Jade Rubick on 04/03/03 02:05 AM
More on the question of whether or not team members can update their own progress:

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.