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

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 and sa…

Managing dot-files with vcsh and myrepos

Say I want to get my dot-files out on a new computer. Here's what I do:

# install vcsh & myrepos via apt/brew/etc
vcsh clone https://github.com/tfnico/config-mr.git mr
mr update

Done! All dot-files are ready to use and in place. No deploy command, no linking up symlinks to the files. No checking/out in my entire home directory as a Git repository. Yet, all my dot-files are neatly kept in fine-grained repositories, and any changes I make are immediately ready to be committed:

config-atom.git
    -> ~/.atom/*

config-mr.git
    -> ~/.mrconfig
    -> ~/.config/mr/*

config-tmuxinator.git  
    -> ~/.tmuxinator/*

config-vim.git
    -> ~/.vimrc
    -> ~/.vim/*

config-bin.git   
    -> ~/bin/*

config-git.git          
    -> ~/.gitconfig

config-tmux.git  
    -> ~/.tmux.conf    

config-zsh.git
    -> ~/.zshrc

How can this be? The key here is to use vcsh to keep track of your dot-files, and its partner myrepos/mr for operating on many repositories at the same time.

I discovere…

The End of GitMinutes (my podcast)

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well:

I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there.

It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences.

To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer science a…

Joining eyeo: A Year in Review

It's been well over a year since I joined eyeo. And 'tis the season for yearly reviews, so...

It's been pretty wild. So many times I thought "this stuff really deserves a bloggin", but then it was too inviting to grab onto the next thing and get that rolling.

Instead of taking a deep dive into some topic already, I want to scan through that year in review and think for myself, what were the big things, the important things, the things I achieved, and the things I learned. And then later on, if I ever get around to it, grab one of these topics and elaborate in a dedicated blog-post. Like a bucket-list of the blog posts that I should have written. Here goes:
How given no other structures, silos will grow by themselves This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies without the…

Always use git-svn with --prefix

TLDR: I've recently been forced back into using git-svn, and while I was at it, I noticed that git-svn generally behaves a lot better when it is initialized using the --prefix option.

Frankly, I can't see any reason why you would ever want to use git-svn without --prefix. It even added some major simplifications to my old git-svn mirror setup.

Update: Some of the advantages of this solution will disappear in newer versions of Git.

For example, make a standard-layout svn clone:

$ git svn clone -s https://svn.company.com/repos/project-foo/

You'll get this .git/config:

[svn-remote "svn"]
        url = https://svn.company.com/repos/
        fetch = project-foo/trunk:refs/remotes/trunk
        branches = project-foo/branches/*:refs/remotes/*
        tags = project-foo/tags/*:refs/remotes/tags/*

And the remote branches looks like this (git branch -a):
    remotes/trunk
    remotes/feat-bar

(Compared to regular remote branches, they look very odd because there is no remote name i…