RE: project management in small teams (couch.io)

This my answer to a blog post by Jan Lehnardt from couch.io

Hi Jan,

kind of funny that you are asking for ideas how to do project management in small teams. We at NMMN were growing from two (Thomas and me) to six people working on our resource management system eUNIQUE. The same question raised and it was me to push this topic in a (hopefully) good direction.

I don’t know much about SCRUM or the principles of agile development in depth but as far as I am concerned, these methods are good. The question is, when are they good or when are they over sized? But an even more important question is, will one be able to start with project management techniques like SCRUM from the very first beginning. In my opinion, a new team or company has to learn the simplest things first and then grow to “bigger” solutions … like SCRUM.

What is the homework to be done? First of all it has to be clear what kind of project you have. Let’s say it’s a software development project. The questions are:

# who is in the team?
# who is the team (project) leader?
# who is responsible for the customer communication?
# who is writing the technical specification of the software (in german: Pflichtenheft)?
# who is testing?

and so on …

These are some common questions for a project. But before that, you have to work out and write down (kind of a “project management company policy”) how you will manage all projects you start. Some questions there are the following (in no order):

# which version control system will be used?
# where are the repositories placed (network)?
# how is the documentation done and where is it placed (network)?
# how are the tests done and where are the results placed (network)?
# where are all the project documents placed and how is the (folder)structure for each project?

and so on …

A very important topic what has to be discussed is furthermore the internal communication. How often are meetings held and where are the results placed (very important: a meeting without a result or without a written report never took place)? What is the rule when communicating with customers (who has to be set to the CC: list and so on)?

As you can see, there are a lot of questions in principle. In my opinion these (and more) fundamental questions have to be answered when starting a business and managing projects in teams at the beginning.

These short summary or experience is a collection of things we were (and are still) faced when starting different projects in our growing team. The main problem is to set the “rules” or “contracts” up so that everybody is accepting them. If there is just one person in the team who is kind of “against it”, the house is collapsing.

And in this concern a real important thing is the need of always following the set up rules. On one hand everybody is used to work in this way and on the other hand, you will save a lot of time when searching for project related documents and so on. The result is a transparent working environment for every project member, for every employee and for the customer.

The last thing I want to write here is the fact, that imho the communication with the customer is one of the hardest tasks and should be handled with the biggest care possible. Usually the customer is not speaking techtalk but likes to sound like he is. It is really important to write everything down (as short as possible but as detailed as needed). After some work has been done (parts or the whole software), let the customer test, get feedback, correct stuff, let the customer test again and ask for an ACK (written!). I call this “feedback loop” and I am assured that this is the best way to save stress, money and unsatisfied customers.

Allready five years ago I was reading a small book by Pascal Mangold called "IT Projekt Management kompakt". Imho this is an awesome small book with extremely good advices how to get your projects done. He is also a fan of eXtreme Programming and agile project management techniques but has also some critical words to say about these techniques. I really recommend reading his book.

Conclusion

Doing good project management is not a hard task imho. There are some approved and well known rules of thumb you should follow to create a successful working and project management environment. Important is to start creating this environment at all, learn out of the experience you’re making and adapt them to correct your rules or policies. Using techniques like SCRUM, waterfall project management, agile development or others is cool but requires to understand them in depth and “live” them each time exclusively. If these techniques are adequate for your company or team is a question you have to answer by yourself honestly …

So, hopefully you can get some meat for further thinking, ideas or discussions. Any questions out of these lines - go a head and get in touch with me ;-)

Cheers Andy

Published: February 23 2010