Notice! This blog is no longer updated as such, and the new spot to point your feedreaders and blurry eyes are https://shelter.nu/blog/
This also means no more comments here, and especially not you spammers, you filthy floatsam of the internet!
Project Management is so many things that is really shameful to put it all into the "project management" pile, but there you go. In my case, I handle IT projects. IT projects have somewhat different requirements than other projects, but similar enough that basic training in the one can be used in the other.
Last week I attended some advanced Project Management for IT projects, and overal it was very good. I've got my own set of twisted ideas on how to do things, and certain trends in the PM "top league" pretty much matched most of these ideas, so for me it was a session of refining and finding agreement on my own thoughts;
Permalink (Tue, 30 Mar 2004 13:00:00 GMT)| Comments (0) | Project management
- It is all about people and social engineering. You can't have a team working together that only work on a functional level; they need to be comfortable with eachother, please eachother and cause eachother to perform. Social factors have been overlooked for too long in general PM, and is my biggest bugbear.
- Complexity of a project doesn't automatically mean expansion of the model used for control. Good models scale well, and some of the best models I've used that scale the best is rather slack attention to specific details, but strong attention to general details in all phases, simply because the latter causes better of the former. It is basic human psychology; push the easy to create more of the complex.
- Statistics lie; we all know this one, where you can represent any fictive outcome through statistics on even realistic values. Don't want to show your 1 week uncalled for vacation? Show the progress bars in cumulative histograms. In other words, try to create a defined set of templates for your statistics, and stick with them through the lifecycle of the project, even if it makes sense to change them.
- If something is easy to do, never delegate it, but do it yourself, right now. It is the trivial stuff that cumulate at the end, bringing any good project out of deadlines.
- Make reporting easy to the developers. Don't make them fill out a Word document which must be mailed back; create a HTML page that collects the info and store them in a database, having links to this page sent out on email to the team at given intervals. If something is slightly complex to do, it won't be done, and will cause a fuzz. A streamlined project comes from streamlined tools, which includes formatting the tools for the team.
- Never put meetings, deadlines and milestones at the end of a week/month/period. Something will come up, and you need time to handle it.
- Expect your project to fail a little (because if you expect it to fail completely, you'll work towards that goal); it makes the small success so much more pleasurable.