Software Project Management - Why it's Different!

Worthless presentation. What a waste of time.

Pointless barrage of buzzwords; no actionable inputs. Save your 4 minutes; you can thank me later.

Tepid analysis. The biggest factor that determines project management style is task certainty. The more task certainty, the more proactive your management style can be, and (because output is a good measure of effort/competence alone, rather than effort/competence and luck) the more distantly one can manage a project. The less certain a collection of tasks, the more of a reactive (Hah! I said it and I'm GLAAAAAD! GLAAAD DO YOU HEAR ME!!! GLAAAAD I TELLLL YOUUUUU!) component has to be in your strategy. Also, the more you have to have technical people judging the work closely to discern effort/competence from bad circumstances.

In software, the most uncertain projects are those that depend on emergent behavior. That is, you specify A, B, and C, with the expectation that a certain kind of behavior will emerge. So QA must determine that A, B, and C are accomplished, and also that the expected behavior has resulted. Sometimes the only way to know if it does result is to sew the monster together. Sometimes you just have to pull it off the slab after it opens its eyes, and spend extra time teaching it to dance.

Here, the dichotomy is, 1) Did the analyst specify a simple report, where all of the work is in the functional specification; or 2) Did the analyst specify a time machine, where all the work is in the implementation? Watch out for the second kind!

I have question
Sending a robot vehicle on Mars to search for signs of life is a project or not?

Nice work

Nice explanations, thank you

nice

Eye catching video

Junk presentation. It sounds like it's the first time she talks about a software project. I've never seen a shop that doesn't track bugs and defects. 

nice work