Skip to main content

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.

Comments

  1. Was this an elective course that you chose?

    I find it interesting that in Europe Project Management is taken very seriously to the point that some private high schools teach Project Management for their students. I have recently published an article written by a Project Manager in Austria teaching Project Management to teenagers, here's the article: teaching project management to students: objectives and benefits.

    Sadly in North America this still isn't the case...

    ReplyDelete
  2. Well, the course was mandatory for my particular studies (5 year long "profession" study). It's possible to get through uni without taking a course on PM, I suppose, but most schools and uni will have some classes that relate to that field.

    Personally, (although it's a point that deserves an entire article for defence) I believe that the project form is a bit overrated as the optimal organization structure/process for developing software. I prefer more evolutionary development processes where teams grow and shrink organically. Classic projects are way too much *boom*-*deliver*-*gone*, and leaves to much maintenance chaos in its wake.

    Even though students should learn PM, they should also be taught more pragmatic and agile practices.

    ReplyDelete

Post a Comment

Popular posts from this blog

Open source CMS evaluations

I have now seen three more or less serious open source CMS reviews. First guy to hit the field was Matt Raible ( 1 2 3 4 ), ending up with Drupal , Joomla , Magnolia , OpenCms and MeshCMS being runner-ups. Then there is OpenAdvantage that tries out a handful ( Drupal , Exponent CMS , Lenya , Mambo , and Silva ), including Plone which they use for their own site (funny/annoying that the entire site has no RSS-feeds, nor is it possible to comment on the articles), following Matt's approach by exluding many CMS that seem not to fit the criteria. It is somewhat strange that OpenAdvantage cuts away Magnolia because it "Requires J2EE server; difficult to install and configure; more of a framework than CMS", and proceed to include Apache Lenya in the full evaluation. Magnolia does not require a J2EE server. It runs on Tomcat just like Lenya does (maybe it's an idea to bundle Magnolia with Jetty to make it seem more lightweight). I'm still sure that OpenAdvant

Encrypting and Decrypting with Spring

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities . It "was decided" that we'd be doing AES with a key-length of 256 , and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet! The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE  in order to do 256 bits. It's a fascinating story , the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them. Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password

What I've Learned After a Month of Podcasting

So, it's been about a month since I launched   GitMinutes , and wow, it's been a fun ride. I have gotten a lot of feedback, and a lot more downloads/listeners than I had expected! Judging the numbers is hard, but a generous estimate is that somewhere around 2000-3000 have listened to the podcast, and about 500-1000 regularly download. Considering that only a percentage of my target audience actively listen to podcasts, these are some pretty good numbers. I've heard that 10% of the general population in the western world regularly listen to podcasts (probably a bit higher percentage among Git users), so I like to think I've reached a big chunk of the Git pros out there. GitMinutes has gathered 110 followers on Twitter, and 63, erm.. circlers on Google+, and it has received 117 +'es! And it's been flattr'ed twice :) Here are some of the things I learned during this last month: Conceptually.. Starting my own sandbox podcast for trying out everythin

The academical approach

Oops, seems I to published this post prematurely by hitting some Blogger keyboard shortcut. I've been sitting for some minutes trying to figure out how to approach the JavaZone talk mentioned in my previous blog-post. Note that I have already submitted an abstract to the comittee, and that I won't publish the abstract here in the blog. Now of course the abstract is pretty detailed on what the talk is going to be about, but I've still got some elbow room on how to "implement" the talk. I will use this blog as a tool to get my aim right on how to present the talk, what examples to include, what the slides should look like, and how to make it most straightforward and understandable for the audience. Now in lack of having done any presentations at a larger conference before, I'm gonna dig into what I learned at the University, which wasn't very much, but they did teach me how to write a research paper, a skill which I will adapt into creating my talk: The one

Git Stash Blooper (Could not restore untracked files from stash)

The other day I accidentally did a git stash -a , which means it stashes *everything*, including ignored output files (target, build, classes, etc). Ooooops.. What I meant to do was git stash -u , meaning stash modifications plus untracked new files. Anyhows, I ended up with a big fat stash I couldn't get back out. Each time I tried, I got something like this: .../target/temp/dozer.jar already exists, no checkout .../target/temp/core.jar already exists, no checkout .../target/temp/joda-time.jar already exists, no checkout .../target/foo.war already exists, no checkout Could not restore untracked files from stash No matter how I tried checking out different revisions (like the one where I actually made the stash), or using --force, I got the same error. Now these were one of those "keep cool for a second, there's a git way to fix this"situation. I figured: A stash is basically a commit. If we look at my recent commits using   git log --graph --