Tim Lister on Project Sluts and Strawmen

cramco writes "Tim Lister, principal of Atlantic Systems Guild and co-author of 'Waltzing with Bears: Managing Software Project Risk,' and 'Peopleware: Productive Projects and Teams' talks about the patterns that help determine software success or failure. Patterns good and bad include project sluts, Brownian motion, the strawman, and the safety valve."

Comments

Yet another /vertisment..

[NeuralAbyss]

Looks like yet another slashvertisment for an upcoming book/conference.

It's a nice start, but lacking any real depth - the article could be summarised in one or two sentences, listing a number of good and bad practices. I know it's stripping people of their $DEITY-given right to derive fiduciary advantage from relaying information and opinion, but can we please have some /real/ in-depth software engineering articles for once in a while?

Re:strawman

[Shados]

I had to quit a job because of that. My boss kept asking me to make prototypes to prove concepts, which I did...then ask me to build entire ERP and CRM systems around the prototypes, which obviously was impossible within the constraints given, and definately impossible to keep maintainable, and mostly secure (they were web based systems exposed to the net, and the prototypes were not security aware...). I quit rather than take the responsability behind that...

Re:Isn't that basic Project Management?

[JaredOfEuropa]

So aspriring project managers do not need books like Lister's, they can just read your post and know all there is to know? The point of books like these is to take a critical look at the set of common practices you call "basic project management", examine the good and bad parts, and suggest better alternatives.

You get the people for that project. You work to form them into a team that can handle that project.

Lister talks about getting the right people for that project, and that means that you don't fully staff it before you know what you're going to need.

You adjust the specs as the project evolves until it either dies or hits the target.

There are still managers out there who think that the specs that were agreed up front are set in stone, and not to be changed. Even if you do change them, when do you adjust the specs and how do you go about it? As far as I can see from the short article, these are questions addressed by this book.

There are enough managers who still royally screw up the "get people", "build the team" and "adjust specs" jobs, to warrant a book on the subject. There are a fair few out there already and I haven't read this one, but if Lister's previous work is anything to go by it might be a worthwhile read.

And getting together with your co-workers after work just so you can bond? Fuck that. If it happens, it happens. But do NOT try to institutionalize it. All you'll do is end up with a bunch of people waiting for the first person to leave so they can all go home to their families.

I tend to agree with you there, but you can be a bit more creative than either doing nothing to socialise or saying "we *are* having drinks this Friday afternoon". A manager can certainly make a difference in how a team bonds, and for those managers I have three magic words: "during office hours". Take the team out for a nice 3 Martini lunch, or an afternoon of paintball. The cost of doing this during work hours looks daunting on the spreadsheets, but it will generally earn itself back a few times over.