[pmwiki-users] Project -- To Do Management with PMWiki
katir at hindu.org
Mon Nov 27 03:11:42 CST 2006
I'm looking for some recommendations from PMwiki users on project
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
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
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
the more experienced of you...
More information about the pmwiki-users