Today while reading the [sigia-l] mailing-list, Donna M. Fritzsche uttered some wise words;

I would point to a few specifics:

1. The wrong people making high-level technical architecture decisions (purchasing products before the right research has been done.)

2. Not paying up front to hire the best people for high-level positions.

3. Not allowing your team leaders to put together the teams that they see fit.

4. Underestimating the time it takes too pull off a project of this magnitude (including preliminary testing, beta-testing, etc.) (I dont mean user testing here - but rather technical testing/simulation, user-testing too would be great).

Another project management nugget.

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;

• 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.

The purpose of this article is to a) give people - like project managers, sales, customers and other developers - an insight into what a web user interface developer does and doesn't, shoulds and shouldn'ts, and b) give web user interface developers insight into methods, best-practices and decisions me and my colleagues at bekk not found. do every day.