What I learned about Project Management in school

Back when I started studying at uni, I took a course called "Organization and management of technical projects" (Norwegian course page link). The course was structured in a very interesting way, and dealt with a measure of topics which are still very relevant for me today (team psychology and leadership, project planning, estimating, etc). It was also held in parallell with a practical software development project (Norwegian link).

I won't write too much about the course itself, but I want to write about the final "exam". We were asked to write a ~15 page essay reflecting on the subject based on our experiences from the practical project combined with the curricular theory.

I handed in my copy in June 2004, just about as I started earning money as a software developer. Some times recently I've wondered if there are any nuggets in that essay (entitled Project management for the Nintendo generation) that I can still reason about today.

(Skip to the bottom of this post if you would rather read the whole original essay in Norwegian).

The essay is primarily about Projects, clearly apparent from the oozy introduction:

Software is no longer only a tool. It is a product in its own right, and project work is what produces it.

Very flash. There are also plenty of footnotes, like:

Svada (Norwegian word a bit like claptrap): A field of knowledge that consists of obivous'ites and only exists for the purpose of its own consultants.

Hello satire! There are also some interesting psychological aspects of project heroism, showing some self-insight:

There were times [in the project] where I saw lack of management, and again I hungered to take control of the project to get the work going. I wonder whether this need was rooted in my task-oriented, or self-oriented self. The task-oriented part wanted control to get the job done, wile the self-oriented part wanted to put me in the hero-role so others could see my skill.

There is also some skimming of the nature of legacy systems:

It is a well known fact that extensive requirement specifications and customer interaction is necessary for a successful product. We have [with our project] confirmed this yet again. Even though it can be useful to re-use existing resources and design, it is healthy to engage upgrades of IT-systems as entire new projects.

Hmm, notice at this point that I might not fully agree today with what I wrote 4 years ago. This notion continues in the next section:

It is within the complex nature of project work that a comprehensive and documented plan is necessary. The project plan should be the project group's bible. It should be a reference guide and framework for all things regarding control, activities and mangement in the project.

Quite. But hey, later on I reframe the view somewhat:

It is easy to speculate on what a project plan should contain, and one often ends up with a project plan containing a lot [of stuff]. There is a trend of plans growing so heavy that they are ignored as soon as they are complete. The project team believes that the plan contains a series of obvious facts that are only relevant for management and customer, and feel no ownership in the document.

Hear, hear. Now, later on I described the project implementation in some detail, and this is where I'm particularly proud of my younger self:

The implementation phase is often experienced to be the biggest part of the project. It is then one actually makes the product. While being a concrete and actual task, it is still very unclear in the beginning. By the completion of the product, it is odd how clear the approach was when one looks back to the start.

Implementation never goes as expected. It is like finding the easiest way out of a circle drawn up by the analysis [earlier project phase], and naturally one follows the radian directly outwards.



The larger reqirements and analysis, the larger the circle becomes. Throughout the implementation, the developers analyze deeper and extend the requirements on their own. The analysis [circle] will grow and move depending on how thorough the original analysis was. Often it will become appearant that another angle out of the circle (meaning different technology or architecture) will be shorter, and in the worst case, especially early on in the implementation, one has to turn around entirely to follow another direction [out of the circle].

Today that looks to me as a strike for agile development :)

I also complained about my fellow students unwillingness to embrace English as language used in code, noting "It would be interesting to quantify what effect this has on Norwegian system development". This very day I'm working with projects that are suffering from having large masses of Norwegian code, while external consultants are struggling to figure out what's going on. Oh, and it's still a "company rule" that all code must be in Norwegian. Get a grip, you nitwits! Your Norwegian code won't protect you when outsourcing threatens. Rather it will be an good reason for throwing your code out, and you along with it! Learn English, or learn a different profession! [sorry for ranting]

The essay contains some glorification of the project as a working structure, and the project manager her/himself. I drew a prallell from the project manager to ancient human traditions of tribal leaders, and how a project manager appeals to our natural order. A practical assignment demonstrated that the team was actually less efficient when all had insight into the orchestration of a task. Today I'm not so certain we should prominate the project manager as the leader role it is set out to be. Scrum trainers have on several occasions claimed that there is no place for project managers in agile projects.. but that is all thought for another blog post.

Finishing off the essay, I gave a brief summary on each of the seven sections:

Expectations should not be built too high, but the team should be made aware that the project will demand full attention, so they anchor their devotion to a high level.

Humans have different motivations. Their true roles should be discovered so they can receieve proper motivation and fitting tasks in the project.

The mission must be well studied/understood. Stable customer contacts and project management must be used in the customers best interest to achieve the best product.

The plan requires quality over quantity. A good plan is used continously by management from start till finish.

Implementation is the goal of the project and can quickly become the hardest part. The team will find themselves within valleys of shadow [dødsskyggedaler], and it is important for the project manager to involve her/himself, maintain motivation and synchronize development with the requirements of the customer.

The end of the project should be emphasized. Before the team is disbanded, they should analyze their experiences and document what knowledge they have acquired throughout the project.

Leadership demands a person with a multitude of talents. She/he must be fully focused on the project. Both the team and external actors must be duly stimulated for the project to succeed.

.. and then I finished very dramatically:

It is important to remember that we do not use this form of management [meaning project] for its own sake, but because it brings out the most productive in humans.

Projects are our generation's way of organization for system development. It is important that we prepare ourselves for the real world by doing projects in a realistic atmosphere so we may experience that leadership is important, and not just another chapter in a textbook.

It would be fitting to end this arcticle in the same manner as it began; by the wise words of David Hume:

"Teaching has suffered greatly from having being locked up in Universities and expelled from the World and good Company."

Very fitting end to an essay I handed over to a professor, don't you think? Mind that the Hume quote is doubly translated back from Norwegian because I couldn't find the original source right now.

For those who wish to read the essay in Norwegian, it's available on Scribd.