881Re: daily status blogs
- Feb 10, 2003--- In firstname.lastname@example.org, "Pascal Roy"
> Hi Mary,What didn't work:
> Can you describe what was not working? What useful features do you
> think would help remotely located teams?
> Pascal Roy
First of all, the project management system which was chosen was a
bad choice. It was clumsy to use and had a structure which made
relevant information difficult to find. It was laborious to set up,
so it was set up quickly and poorly. I imagine there are better
ones out there, but this one was chosen on the (mistaken) notion
that it could be used as a time tracking system.
Second of all, there was no motivator for using the system. It
never replaced e-mail and regular video conferences as the way to
exchange information. The biggest problem with most systems like
this is that no one NEEDS to keep it up to date or read it to get
information. Unless such a system becomes the only way to transfer
information, it simply will not be used, because it is an extra
step. And yet, it is not possible to transfer all or even most
information by writing it down. Since this system did not work
well, it was abandoned as the authoritative source of information.
I think that EVERY blog, WIKI, or bulletin board suffers from this
likely problem. Few become indispensable.
What did we need?
1. We kept and regularly revised use cases, because these were
what everyone used to communicate. They were very useful, but they
needed to be versioned and people had to know when a new version
affecting them was posted. The mechanism for doing this was so weak
as to be useless. Too bad, because assuring we were working with
the latest use cases and notifying the RIGHT people when changes
were made was not done very effectively. Everyone turned off the
notification system immediately, because it flooded them with
useless update notifications. In fact, full notification of any
file changes or discussion postings was set `on' by default. One
day I did a web file transfer of hundreds of files to fill the
database, and every single member got an e-mail of every single file
transfer. It brought down the e-mail server since most people
were in the same company similar to a denial-of-service attack.
2. We needed to be able to post issues questions that one
team had of a remote team, with the expectation that the team
needing to address the issue would know it was posted and address it
the same day. This is much more tricky than a threaded discussion,
but that was about the level of the tool we had to use. Again,
notification of an outstanding issue was a big issue e-mail always
worked better. But also, you needed to have a trail of the
discussion to see the progress of the issue, as well as a quick
summary of outstanding issues. Also, typically, issues were
assigned to someone to answer normally the person who should know
the answer. Then they would re-assign it, etc. The system needed
to support this, but it didn't.
3. The same kind of issue tracking system was needed to track
defects, with perhaps a few added features, like defect resolution,
date/build of resolution, etc.
4. We needed general threaded discussions also, but they
somehow never happened. Things like this batch process is really
tricky who knows about it? Pretty much it's hard to replace face-
to-face conversations in this regard.
5. Finally, there was a BIG DEAL as to whether or not the
customer should have access to the system. Because of the time
tracking (which never worked) and because some things were written
on the system that should not have been said in the presence of
customers, they were never allowed access which made the system
really ineffective. It was a bad decision, and not one I agreed
- << Previous post in topic Next post in topic >>