Brief tip 6: Do the hard things early

As I mentioned, agile methods have some built-in capability of reducing risk by having a working version early and improving it in increments. In my experience getting an early version up often uncovers miscommunication and can minimize the cost of this.

However, I have found, both using cousins of Scrum and occasionally also methods maybe best described as the evil twin of the waterfall process (!), that there is often a tendency to postpone the hard tasks that we do not know how to handle. Don’t.

In fact, I’d like to advice as my tip #6:

Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one

Starting working on the hard tasks early has multiple advantages, which include:

• You learn more about the problem domain early on, often this helps finding the final solution even if it will not be finalized until a later iteration.
• Often the hardest tasks in a software development project involve complex integrations and multiple parties. Then it is often length of the calendar time that is required, with the hot potato being passed around, and not so much the number of hours worked that will help. Also the effect of adding more resource when already late has been questioned all the time since the seventies (“Mythical man month”, anyone?).
• Some times the hardest tasks are actually not possible (or at least not feasible) to solve. Finding the workaround or even scrapping the project or functionality early is so much better.

That was my tip #6. Please leave any comments below. My best wishes for the Easter also go out to everyone stumbling across my blog.

Brief tip 5: Use a visual risk log as a communication tool

Risk is most often defined as uncertainty of outcome (both PRINCE2 and PMBOK stress that both negative and positive impacts are considered risks). As a project manager you cannot always find appropriate actions to mitigate risks, but you should be sure to communicate your view of risks and their status.

One of the great things about agile methods is that they have a built-in capability of reducing risk by working in small increments. Nevertheless, risk management is sometimes overlooked by Scrum-masters and the like that was “born agile” that does not have the classical, old fashioned if you will, project pyramid theory under the skin. I actually think this is an area where the agile movement can be supplemented by methods from more traditional methods, such as PRINCE2 or PMBOK.

The steps in risk management are really quite straightforward: 1) Identify risks 2) Classify them 3) Select appropriate actions. I think it is important to separate risk identification and classification. If you don’t, the risk (pun intended) of prematurely ignoring a risk as already handled or not understanding its impact if happening it is too great. Risk classification will vary from project to project and organization to organization, but impact, probability and proximity (in time) will be safe bets as a starting point. Needless to say, the risk log should be a live document that you keep updated throughout the project – I would say that a weekly review is a minimum.

If you set up the format of your risk log, be it a formal risk log of your favourite project management method or a more informal overview you keep for yourself, in a practical way, you can automatically view the risks visually. I have found this to be a good tool for communicating the status of risks to project boards and the like. Below is a risk matrix for this blog post created by such a setup:


I have uploaded the excel sheet that I used to create the above graph. I hope you find it useful. As mentioned, I think the risk log and resulting matrix can be a great communication tool – even if the exact computation of impact and probability is not very sound mathematically. The idea is of course both to keep an overview, but also to move the risks down and to the left. But don’t let the matrix lull you into a false sense of control, of course.

That was my tip #5. If you don’t agree, please leave a comment. Oh and I almost forgot to formulate the actual tip, here goes:

Keep a close eye on risks throughout the project and use a visual risk log as a communication tool

Brief tip 4: Communicate early, communicate often

This tip is simply:

You can never communicate too much as a project manager

You should communicate clearly, often and repeat important messages even after you think everyone knows every little detail of it. They don’t. This is not because they are lazy or forget easily, it is just that most often they have not had the information internalized through lengthy discussions or working on the issue for a long time.

When the first members of the team smiles ironically when you repeat the message, you are not even half way through. When team starts to make jokes or even parodies of your most repeated messages, I would argue you are probably about three-quarters through getting a message out to everyone that will be sticky.

I also believe in sharing whatever information you have with the team early, even if you are still waiting for a conclusion of an external discussion. Even if one can argue that this can be confusing for the team sometimes, I feel it builds trust. Also, you avoid running into situations where you are unsure what you can say based on what you have said before. If you don’t do it, you will sometime have to make priorities that are hard to understand for the team. So I think saying “this is all that I currently know and I will share it now” is usually the best way of handling it.

This philosophy plays well with a notion of involving the team in decisions and to be able to make rapid adjustments of direction. You can formulate the principle of over-communication as a virtue the way I do in the title of this post: Communicate early, communicate often. As an added bonus, a little word play back to one of the principles of agile software development. :-)

That was my tip #4. If you don’t agree or would have ranked it differently, please leave a comment.

Brief tip 3: Now, write that down

Even if you use lightweight methods, which can be an excellent choice, with less focus on documentation it does NOT mean that you abandon writing down conclusions from meetings, internal discussions or how a difficult project issue was agreed to be handled. My most basic, but maybe the most useful, tip is:

Be sure to put conclusions in writing immediately, even if not using documentation heavy methods

I find over and over in projects that same discussions will be repeated throughout the project because participants are unsure what was concluded. To settle a discussion can sometimes be hard and time consuming work. Then you ought to think that writing it down and sending it by email just “to confirm and summarize my understanding of the conclusion” would be easy and done at once? The next time, do it.

Writing down conclusions is equally useful for internal architectural discussions and for external commercial ones. This is also related to the previous point about expectations and mutual understanding. You have the chance to use the power of definition. Your customer or your team will even thank you for it most of the time. Writing things down to document decisions will help you tremendously delivering projects, agile or not – it is what consultants like to call quick wins or low-hanging fruits.

That was my tip #3. Now go pick those fruits. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 2: Manage those expectations!

Excuse me for the use of the exclamation mark in the title. I promise not to do it again, but as this point was beaten to the #1 spot, I just had to do it. :-) I can’t say strongly enough how important I feel this is.

Let’s take a slightly academic approach. Let’s say that customer satisfaction relies primarily on:
1) What the customer expects
2) What you deliver in your project

Now, how long do you spend doing 1) and 2) during the whole life cycle of the project? Seriously, do think about it for a minute. I have found that it can sometimes be extreme. That holds true both on a project level, but also on the micro level – haven’t you sometimes spent hundreds of hours tweaking a feature that the customer didn’t actually find that important? Could you maybe just have negotiated that out, perhaps giving something more valuable with less work in return?

Typically I find that way too little time and effort is spent on managing expectations. One way to uncover misaligned expectations is to be explicit about what you are NOT planning to deliver or do. Expectation management is not an one-off in an early phase, but something that you continue to do at every chance all the way until the project is signed off. Thus I formulate my tip #2 as:

Be sure to use every chance throughout the project to manage expectations

The process of managing the expectations all the way through the project is not only to the benefit of the supplier. Another expression for managing the expectations could actually be to really understand the customer’s needs. So if it is more politically correct, feel free to change the title of the point to “ensure mutual understanding”…

You can talk about managing expectations internally as well (for instance for the team or line management if you are in a matrix organization environment), but I won’t do that here.

That was my tip #2. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 1: Don’t forget the people

I promised to deliver the tips in a roughly prioritized order. Thus, I had to start with this one – especially since most of my other tips will be somewhat more focused towards the harder aspects of delivering successful projects. So tip number one is:

Do not forget that it is the people in the project teams that actually deliver successful projects

The softer skills, needed to foster a team environment everyone will enjoy, contribute to project success at least as much as methods, templates and processes do. Motivated and happy team members run in circles around their dissatisfied and demoralized cousins! They take responsibilities and grow in a self-reinforcing virtuous circle. When you have gained trust early on in the project, they start raising issues as early as they even begin to sense them, instead of just before they blow up on you all.

Often the role of the project manager will be more of a facilitator than a more traditional manager. Also, if you operate in an environment and/or framework that command traditional top-down thinking, getting the balance right with bottom-up empowerment is important.

You should not only cultivate your team internally. Remembering to take good care of people and show a behaviour that helps people feel valued are equally important when dealing with people outside the team, for instance the customer if you are a supplier. If you run intro trouble, and almost any project of a significant size will at some point during its lifecycle, it will be so much easier to settle and move on if you already have established a platform of trust and maybe even a type of friendship with the client at this point.

And by the way: Don't try faking it. You will get caught and nothing will destroy carefully earned trust faster. So you have to really love your job and care about your team...

That was my tip #1. I look forward to read any comments, but you will have a hard time arguing that people are not important – even if you can present hard facts or rankings to back them up (this is one of my top five favorite Dilbert strips of all time, taken from “The Dilbert Principle” book by Scott Adams):

Introducing the “Brief tip” series

I am today kicking of a series of posts, aiming at a total of maybe 10, containing practical tips for day-to-day work managing projects in general and software development projects in particular.

Some of the posts will include a specific tool, procedure or checklist, but most will be more general in nature. Hopefully they will all be thought-provoking. After all, I do not believe in any silver bullet procedure for ensuring top quality project management or software development. That being said, procedures and checklists can help a top quality project manager when used with thought. :-)

I will be writing the posts in a roughly prioritized order (meaning that I write a piece when I find the time and about a topic not yet covered!). I hope you will find them useful, and look forward to your comments even if you don’t agree, or maybe particularly if that is the case.