Monday, October 31, 2005 

Teaching SOFTWARE Project Management

Over the years, a number of customers asked me to teach project management techniques to their team leaders and project/product managers. The reason is quite simple: traditional project management techniques don't work so well for software projects. Sure, you are better off if you know how to use PERT and GANTT charts, and you may still benefit from some traditional lecturing on risk management, but software is different. The best reason for software to be different comes from Armour: software development is a knowledge acquisition process, not a product manufacturing process. That's a huge difference.
Despite the large number of requests, I've never committed myself to create a set of PM slides. For more than a few years, I've been firm into telling that I knew enough to run a successful project, and even enough to advise on how to run a specific project, but not enough to teach how to do it in general (which is what I would expect from a PM course).
In the last year, I've spent more and more time thinking on what I could actually teach - valuable, modern, software-specific techniques that I've tried in the real world and that I can trust to work. It turned out that I knew more than I thought, but also that I couldn't teach those techniques without first teaching some (even more fundamental) conceptual tools, like Armour Ignorance Orders or Project Portfolios or Option Thinking, and so on.
In these days I'm polishing the slides I've created, and trying to create a natural bridge between those slides and some of my material on Requirements Analysis. This is probably a good chance to review that material as well, along the lines I've envisioned a few months ago. So, very soon I'll have a new, short, hopefully fun course on PM appearing on my course catalogue.

Labels: , ,

Comments:
Per dirla in altre parole, noi analisti programmatori cadiamo sempre in piedi... Quando sforiamo non è colpa nostra, ma della materia che trattiamo. Complessa ed in continuo divenire tutta permeata dall'imponderabile che mal si adatta alle comuni regole di questo mondo ;-)
 
Incuriosito dal post di Carlo ho sfruttato google per scoprire cosa fossero quelle arcane parole (Option Thinking ecc.)

Per condivisione:
http://www.ii.metu.edu.tr/~is526/course_material/papers/The%20five%20orders%20of%20ignorance%20-%20armour.pdf

http://www.cs.vu.nl/~x/knipselkrant/gantthead.pdf

http://www.daag.net/pdfs2000/jerrylieberman.pdf
 
Romano: non ci andrei cosi' leggero con i softwaristi :-). Ma ti rispondo (piu' o meno direttamente :-) nel post di oggi...
 
Carlo, considerando il software development un qualcosa di diverso dal processo di realizzazione di un prodotto, in che modo le attività di risk management, planning e altre pratiche mutuate dall'"ingegneria dei prodotti" cambiano e/o si adattano?
E' un cambiamento strutturale o un semplice tailoring?
 
Direi che e' un cambiamento molto profondo. Arriva ad influenzare il linguaggio con cui parliamo delle attivita' da svolgere (vedi ad es. i concetti di "ignorance level" di Armour, i concetti di progetto Dog/Skunk/Colt/Cow/Bull di Landmark Graphics, ecc), ed i conseguenti schemi di pensiero. Fa capire meglio come pianificare un project portfolio all'interno di una release, bilanciando rischio e valore. Evidenzia meglio alcuni rischi specifici per il software. Ecc. E' un argomento un po' lungo, anche perche' nella mia visione va completato con un altro aspetto centrale, ovvero la creazione del software come creazione di valore. Prima o poi ne parlero' piu' diffusamente...
 
Post a Comment

<< Home