Every project requires investments in terms of time, money, and other resources. This chapter will help you analyze the requirements of your project at hand, and decide how to proceed in light of the investments required to make it work.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:One thing that has worked well for us is to the a wiki for documentation.
Wikis are naturals. I'm proposing one for simple docs plus another based on Plone for more advanced uses -- though Plone is typically overkill.
So far: none have been deployed where I am, and I've had to deal with being grilled over how this will mesh with the required MS Word Doc-based requirements database. (Yes, I attempted to avoid Word as it is paper-centric and not easily searchable and was shot down.)
The key reason documents probably get ignored or lost is that it's too bulky to maintain or it's too hard to keep track of the current version or see how a document evolves and how changed what. Wikis solve this problem, and if you have the right wiki format, it's possible to generate your own reports (I like Dokuwiki because it doesn't use a database. You can just copy it to CD and take it anywhere.)
Thanks for the tip about Dokuwiki. The rest I agree with 100%.
Another value of wikis is that it's easy to use hypertext to provide more technical information as needed. This allows for a high level view to be created for managers, and a more detailed view to be created for implementors.
I agree...though one of my more stressful conversations was with someone who kept asking "how are we going to integrate PPT and Project?". His solution was to use something with attachments. Wikis allow that and some provide translation to a web-viewable format. His comment: How will it handle attachments? Grrrrr...
This being said, I agree with the rest of your response that project management is really people management. The success of a project depends as much as how you manage your project sponsor(s) and process owners as the work that actually gets done.
I also agree.
A dirty phrase -- "customer management" -- is really the key if you are on the contractor's side. It doesn't mean treating them like sheep to be hearded, but instead manage expectations and to focus on the unambigious parts (such as well written requirements). That way trust can be built...slowly...and you have less of a chance of having them think you are trying to screw them over. (That, and you really can't be a scum bag...people will only put up with lies and deception for so long. Well, they shouldn't put up with it as much as they do, though there's no reason to be that way.)
Member since:
2005-07-09
One thing that has worked well for us is to the a wiki for documentation.
The key reason documents probably get ignored or lost is that it's too bulky to maintain or it's too hard to keep track of the current version or see how a document evolves and how changed what. Wikis solve this problem, and if you have the right wiki format, it's possible to generate your own reports (I like Dokuwiki because it doesn't use a database. You can just copy it to CD and take it anywhere.)
Another value of wikis is that it's easy to use hypertext to provide more technical information as needed. This allows for a high level view to be created for managers, and a more detailed view to be created for implementors.
This being said, I agree with the rest of your response that project management is really people management. The success of a project depends as much as how you manage your project sponsor(s) and process owners as the work that actually gets done.