One of the most important jobs of the project manager is to delegate project tasks. This is specially important when the project manager has a heavy technical background. It these cases, the temptation to do something because you can do it (and you are comfortable doing it) is very strong. Most of us (if not all) have been there before, and we find lots of reasons to justify what we are doing:

• I can do it much faster than anyone else
• The quality will be better if I do it
• There is no one else who can do it, or they are very busy
• I don’t have time to ask someone else to do it

The truth is that all this reasons are excuses, and while in the short term it might work, the result in the long term is negative.

Think about it.  Are your reasons the real problem?  Or are there other underlying reasons?  Let’s analyze some of them:

• I can do it much faster than anyone else:   it might be true today.  But aren’t you doing it because it is easier than teaching someone else?  Or even worse, are you afraid that the person you teach will do it better than you in the near future?
• The quality will be better if I do it:  when you say better, do you mean your way?  or maybe you had bad experiences in the past because you didn’t specify well enough what you wanted.  And in that case it is normal that you don’t get what you expected
• There is no one else who can do it, or they are very busy:  was this task planned?  Was it assigned to someone?  In many cases this reasoning shows a lack of planning.
• I don’t have time to ask someone else to do it:  this sounds similar to I don’t have time to plan.  Teaching someone else to do something is not a waste of time, it’s an investment!  Think of the time you will be able to save in the future having this person well trained.

And you also have to think that the more indispensable you are, the more difficult it will be take advantage of new opportunities, such as a promotion or a new interesting project in your department.  Do you think your boss will let you go if there is no one ready to take over?

I hope I convinced you to delegate more.  It is not easy, but in the end it is very rewarding for you, and for the person you trust to delegate to.

Decision making is one of the most important tasks the project manager has to deal with.  Everyone would agree that these decisions have an impact on the project, but it is sometimes overlooked that how the decision is made is also important.

What should the project manager do?  Do a quick analysis and act fast to keep the momentum of the team or do a thorough analysis of the problem to make sure the right decision is made?  As usual, there is no universal answer that works in all situations.  But there are some guidelines you can follow.

First of all, the project manager has to understand that not all decisions are created equal.  And what makes the difference between them?  Their consequences.

Imagine you are managing an SW project and you have to decide:

• The color scheme used in the interface.
• The programming language and framework you are going to use.

How can these decisions affect the project?  Even if you choose a horrible color scheme and have to change it in the future, the impact should be minimum.  A few hours?  A day?  But what about the programming language?  A wrong selection may make the project be late, over budget, below the quality standard or all of them!  So it looks that it wouldn’t be smart to use the same decision making process in all situations…

My recommendation is to adapt the time we spend to make the decision to the possible consequences the decision has.  If we take the two extremes:

Unimportant decisions:  don’t spend time on them.  Make a quick decision based on the information you have and forget about it.  You have to move on so that you can free your mind to focus on more important things.

Key decisions:  if you know that your choice can have a significant effect on the project, analyze it thoroughly.  It is better to stop and spend a few days gathering all the information you need.  The time you use for this analysis will reduce the risk to make the wrong decision, and you will (most of the times) avoid working in one direction to later find out that you have to start from the beginning.

Of course nothing is back or white, there are lots of greys in between.  It is sometimes hard to know what the possible effect of our choice is.  However, it is usually easy to know when we are dealing with an unimportant issue.  If you find yourself in that situation, don’t waste any more time!

And a last piece of advice.  No matter how bad the outcome of a decision is, don’t waste any time thinking that you should have done something else, or trying to justify why you made that decision, or blaming someone else.  All these actions won’t improve your situation.  Just learn from the experience and move on.

When you read the title, you probably thought of Requirements Management Tools like DOORS or RequisitePro.  This type of software is important and makes things easier, but we tend to focus too much on the tools and forget about the process they support.

Let me tell you a story that happened to one of my colleagues to illustrate where we should focus when managing requirements:

We were about to finish the production of one of our systems, so we had to order the boxes we use for the shipping.  It was the first time my colleague did that, so he carefully checked similar boxes to make a proper order.  He realized that the difference between the inside and outside dimensions was very big because of all the padding and protections.  So he measured that difference to take it into account so that our system fit perfectly.

Therefore, final dimensions = system dimensions + padding + protections.  Makes sense, eh?

After checking it once again, he sent the measurements to the guys who manufactured the boxes and to the company which had to do the shipping.

And everything was fine… until we received the box.  It was HUGE!!  But something had to be wrong, because the dimensions had been checked.  A phone call to the box manufacturer explained it:  he always works with internal dimensions, not external.  On the contrary, the transportation company works with external dimensions.  And, to be honest, it makes sense:  you specify the size of the item you want to put in the box (internal dimensions) and the size of box you want to transport (external dimensions).  So the problem was obvious.  The requirements of our box were incorrect.  Well, they were incomplete, as we never specified that the dimensions we provided were external.

Box Requirements

So if the outcome of a “project” as simple as box can go wrong because of incorrect management of the requirements, imagine what can happen in a system with hundreds or thousands of requirements.

And it is clear that no tool could have helped in this situation.  Tools are very useful for checking missing traceabilities, control the changes, allow only certain users to modify the requirements and many other things.  But in the end it all depends on the analysis we do of those requirements.  And if we don’t do a good job (not get the right people, do the analysis in a rush, not ask the customer if there is a doubt…) then the consequences can be disastrous.

The mission of the Project Manager is to get the project done in a timely manner, within budget and with the required quality.  In order to accomplish this mission, the project manager performs several tasks:

• Plan
• Monitor the progress
• Take appropriate actions

These tasks can be performed in very different ways.  A manager could plan the activities, communicate them to the team, control the progress periodically and push the team and “use the whip” when the progress is not as planned.
Another manager could agree the planning of the activities with the team, share the goal of the project with the team, control de progress periodically and help the team overcome the difficult moments.

As you can see, the basic work-flow is followed in both situations.  However, the approaches are absolutely different.  The first behaviour is close to a foreman  and workers are treated as “robot” workers.  In doing this, workers usually respond as requested, so they do their job but they don’t try to be creative and find new solutions for existing problems.  In today’s world of knowledge workers, most professionals are highly trained, and a project manager cannot afford to not get the maximum from every single team member.
The second approach requires that the project manager is a facilitator.  This means that the project manager helps the team to reach the goal.  Instead of telling everyone how to do things, the project manager shares the goal of the project and helps the team to find the way to success.  This help can have different forms: getting the requested resources, defend the team when there are problems, be a positive leader when problems arise…
The result of this approach is that the team is involved in the project and motivated, which boosts the performance of the team.

But does this mean that I can’t be demanding?.  ABSOLUTELY NOT!!!  Don’t forget that you are responsible for finishing the project in a timely manner, within budget and with quality.  But there is a difference between just demanding something and demanding something providing the necessary help.