Thursday, July 07, 2005

Software development is not construction

Three days ago I've posted my opinion that technical competence is required for PM managing IT projects. Of course understanding technology is not enough. PM should be aware of an essential difference between software development and traditional construction-type projects.

Software development is not construction engineering, where most activities are repetitive and can be described in a detail by the procedures or automated. Kidd distinguished such kind of procedural work from the effort of knowledge worker, who's job is based on creativity and communication. Therefore software developer should be considered designer because, as Reeves pointed - code is the design. Moreover, in software all the effort is design, as stated Fowler.

Every design activity is more similar to research than the production. Design is hard to schedule, because of its very nature. Conklin and Weil have studied the designers behaviors and concluded that solving complex problems (design is such activity) is non-linear, chaotic and nearly impossible to plan - "the flow of their [designers'] thinking was full of upredictable leaps" (Conklin, Weil - "Wicked Problems: Naming the Pain in Organizations").


Figure 1: Actual pattern of problem-solving activity of one designer - the "seismograph" (source: Conklin, Weil - "Wicked...") [click to enlarge]

Also Fowler says that creative processes are not easily planned, and so predictability may well be an impossible target. This could be one of the reasons of the failure of applying the deterministic project management techniques to software projects.

It is important to understand the essential difference between traditional construction engineering and software development. Those who don't get it, won't see anything wrong with building a bridge an agile way :).

UPDATE (2005-07-18): Mishkin Berteig pointed me to the article supporting my argument. Really worth reading. Thanks Mishkin!

Tuesday, July 05, 2005

Can you manage something you don't understand?

As a leader managing IT project you must have technological background or - at least - deep understanding of project domain and technology used by your team. Without clear vision of what and why your people do, you won't be true leader. You won't be able to freely communicate with your team.

Goleman describes 6 leadership styles (Goleman et al, "Primal Leadership"). He values the visionary style as the most effective. Visionary leaders lead through inspiration of the people to achieve common goal, they move them towards a 'shared dream'. But Galford and Drapeau claim that the real leadership takes more than inspiration - it takes a trust between the leader and his team. The first step to build trust is to show understanding of the needs of team members and the group as a whole (Galford, Drapeau, "The Trusted Leader"). How can you understand their needs if you're not able to understand what they do?

That was Machiavelli who said: "And therefore a prince who does not understand the art of war, over and above the other misfortunes already mentioned, cannot be respected by his soldiers, nor can he rely on them." (Niccolo Machiavelli, "The Prince").

Dilbert would probably get my point :)