[pmwiki-users] Project -- To Do Management with PMWiki

Sivakatirswami katir at hindu.org
Mon Nov 27 03:11:42 CST 2006


I'm looking for some recommendations from PMwiki users on project 
management.

Our context is that we have small work group of  about 6 core developers
1 in Brazil, 1 in California, 3 here in Hawaii and 1 in Australia.
These are *nix competent who have cmd line, terminal access to our
web box and all the PM wikis I have set up.

On top of that we have another "layer" of "helpers" who don't know
much more than how to run their browser, but they volunteer for
various kinds of data entry task, or web content development  tasks
where they are html-design + FTP competent, no nothing about
programming perse. And  then on top of that  we have few "seniors"
who need to keep in touch with what is  going on and make strategy
comments from time to time.

At any  point in time I may have (let me count...) 10-15 projects in
process that required logging documentation, runtime project management
with to do  lists for each project etc.

It's starting to grow and the octopus is getting harder to manage and I'm
looking for ways and advice to keep the  admin overhead down. And we
are looking to possibly hire on some more developers. At this point
is all volunteer.. so the chaos doesn't cost us  anything, but
when we move into paying people, I want to have something
that works in place.

So far PMwiki is proving very useful.  For  one major independent project
i have set up one completely independent wiki.  Another wiki has 
different projects
running under different groups: each project is it's own group.

Then on top of that I have the "admin" wiki where I log activity
on the server, configuration changes, history etc. and this wiki
is only open to the core group.

So we have three wikis running on the farm.. sometimes I think
I may be better off with a single wiki, but the  authorization
management for different  wikis is so simple (I just set them
as protected directories in Apache  and we are done.)

Ok so that's the context... We started to use the  Simple  TO DO
cookbook and it's a quite  good. but it has one draw back:
All of the TO DO's are in one group and if we start listing
tasks in a single TO DO list for different projects,
  the notes start to "blossom" into
semi-documentation that really belongs in  the main group
for that project... e.g. if we have a complete functional
specification on one page in the group for that web application.
Then we start assigning tasks to implement the design
in the TO Do list, now the  Notes in the TO DO list start to
gather key requirement changes-decisions that rightly belong in
the functional specification...

Also, if we set up a to do list for each project, then  for each of
the  team members, there is no single integrated  to do list.
We have  to go around like the guy on stage keeping the  plates
spinning on the sticks, ffrom one TO DO list  to another to
see what we have to do in each project. But as the manager
of the whole  team I'm not able to easily pull together and
prioritize a single TO DO list for each man on the team.
The prioritization for the work flow can get very dynamic at times
with priorities for tasks jumping from cold to hot within 24 hours, some
are long term... or need to be done today.
Some things have to wait, one man (A) building the back end CGI and 
PostGreSql stuff
may need to stop and wait while the "supers" and web design guys
sign off on the UI frontend... meanwhile he should be be able to easily
  change focus to tasks on another project  (2) while waiting
for the OK's, testing or design to be done. So we getting this PMwiki space
  where we are jumping all  over the place to find out what to do and write
down requirements and  log activity. It's workin  "kinda OK" but a little
more fragmented than we would like. I have to guard against people
putting more  time in jumping around on the wiki and writing stuff
down than they do actually getting the job done. Of  course anyone
who resists documentation will have to eat crow next year, but  still
we need to make it easy now...

OK, so I'm sure some of you have "already been there, done that."
and I'm looking for some advice.  There's once school of thought
that says PMwiki is just too unstructured to meet our needs, on the other
hand I see the flexibility of PMwiki as a strength in the long run,
not a limitation. Maybe I'm am wrong and we should move on to a more
structured project(s) management software application. I work with
some other projects run by others who are using "Base Camp" but
there model is even more chaotic than ours...

Help! I am more than a little out of my depth here and will much 
appreciate insights
the more experienced of  you...

Sivakatirswami
www.himalayanacademy.com





More information about the pmwiki-users mailing list