Do not tidy up, just don't mess

I met a guy this weekend that was so impressed after inspecting a German factory that will produce machines for them. He asked the guy showing him around what was the secret behind tidying up so well.

He got this answer: We don't ever tidy up. We just don't mess.

And I think he was not even close to joking. Gotta love ze Germans.

In terms of project management and creating software, and maybe life in general - but that might be a tiresome effort, doing it right the first time is something we all strive for. Maybe thinking about not having to clean up the mess can make us get it closer to right, at least?

Everyone loves a wish list?

Sometimes the only ones enthusiastic about methodology sit on the vendor side. What do you do if you get that 1000-yards-stare back when you mention "agile" or even try selling the idea of using "Scrum"? For sure you don't start talking in detail about building product backlogs and items making it into a future sprint backlog!

What I have found may work in such settings, though, is introducing the concept of a wish list and some very simple rules to govern it. YMMV, of course, but something along the lines of:

- Every suggestion or idea, no matter how great, goes into the wish list right away
- At certain points the wish list is reviewed and the highest value items are scoped for delivery

Of course there is the risk of being perceived as a stubborn bastard, but maintaining such a wish list can help you structure a "backlogish" approach even where no-one wants to hear about it and it can be good for business (on both sides, actually -- as it makes priorities clear) and often separates what is included from what is paid for. Give it a try.

Make the desire to win bigger than the fear of losing

I was recently made aware of some research about penalties in football (soccer, for any US readers). How can this be relevant in project management? Maybe it is a stretch, but I think it can learn us a thing about motivation. Let's see.

I cannot find the original Norwegian source now, but the basic content was this: When the last penalty is taken in a football penalty shootout, the likelihood of scoring is almost twice[1] if your team will win if you score than if your team will lose if you miss[2].

Even though generalizations from non-related fields is risky and I am a fan of brutal honesty[3], I will take my chance on this one: This can learn us to make the desire to win bigger than the fear of losing. If your project team feels scoring that goal (be it completing their component, polishing that presentation, or something else) will win the game, it is better than if they fear their mistake will drag the entire project to a failure.

So making each team member feel that their contribution is essential, but creating an environment where everyone is sure someone else will pick up the ball (!) if he fails his current task, sounds like the winning formula. Maybe not rocket science (it is football science, after all!), but a good reminder?

Now go on and win your game.

[1] - Again I didn't manage to find the original numbers, but they were something like 40 % and 70 % likelihood of scoring. Will update this blogpost if someone pings me with a link to data or original article. The source is as credible as it gets in Norwegian mass media, at least (A-magasinet from Aftenposten) - and it seemed to reference valid research.

[2] - I.e. the statistics were for the tenth penalty, and equal score before the penalty will give the first situation and the team not having the shooter being one goal up would be the second.

[3] - For the record I am also a fan of a lot of praise. But being direct about the negative also gives credibility to the praise. Maybe a separate blog post on this later!

Old, grumpy and agile – the ideal combination?

This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?

Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?

I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version[1]. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.

It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.

My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days"[2] (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").

[1] - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.

But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.

[2] - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.

Portfolio planning: Create storms, not forms

I said some time ago that strategic portfolio management goes beyond what is typically achieved in a project management office (in my 8th "brief tip" for project management). My best attempt at formulating this in a rememberable way comes here: Create storms, rather than forms.

I think better value from a project portfolio can come from creating storms - honest discussions between people that typically own the day-to-day business operations that the projects are about to change - than using very detailed sign off procedures and authorizations. Rather than requiring many people to sign off projects of a certain size, have them take part in the regular meeting that is the only place such projects can be authorized for initiation.

An important outcome of such meetings is which projects not to run and also to create visibility of the most important projects for senior management. Ask top management: "What are your current major running projects and which are the top priority ones?" Getting any kind of stuttering as a response is a big red warning light.

If you just take the form-based "PMO coordination" approach, there is a danger that all projects will just be administred - not prioritized. One useful way of visualizing projects can be as a radar, with distance showing the expected end date and the size of the dots showing the size of the project, possibly with sectors for business units. Over time, some rules of thumbs might evolve about how many major project the organization is able to digest, which types of projects require the most coordination across business units, etc.

A weak point of the method of de-facto giving the line management power to decide which projects to run, is that often only the needs of current customers will be heard. This is similar to Christensen's Innovators Dilemma. You may make your self obsolete through many incremental innovations of the status quo, that by them self make sense - but fail to capture big shifts. This is really a separate discussion, but one solution might be to separate early stage R&D projects both organizationally and from the project prioritization process.

A final word, maybe to avoid any unintended storms (!): Forms can also be useful. The most obvious example I can think of is that a suitable template, or form if you will, can contribute to getting the project owner to think in business case terms when arguing why it is a good idea to run just their project... And PMOs can of course be useful facilitators for the decision process. Also, I am not suggesting to get rid of documentation or preparation for the meetings, but I still think that the main point is valid: Prefer storms over forms, decisions over documentation, and prioritization over administration.

Summarizing my brief tips for project managers

So, that was the 10 posts. Here are my 10 brief tips for successful project management summarized (each sentence links back to the individual post):

1. Do not forget that it is the people in the project teams that actually deliver successful projects
2. Be sure to use every chance throughout the project to manage expectations
3. Be sure to put conclusions in writing immediately, even if not using documentation heavy methods
4. You can never communicate too much as a project manager
5. Keep a close eye on risks throughout the project and use a visual risk log as a communication tool
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
7. Establish checkpoints that you follow in each of your projects, even if operating in an agile way
8. As a project manager, try to add value beyond administering the project
9. Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on
10. Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

When I look at it now, what do I feel – should I have changed something drastically? I think I might have created one specific post on goals. I think it is really important to have the goals clearly defined (and on the right level) and understood across project team and stakeholders. That is maybe buried a bit in the “managing expectations” heading in the current list of tips. Make sure to have it clearly visible in your mental checklist.

Apart from that and to be sure to communicate roles and responsibilities very clearly (and also to always work in stages or increments, but that is sort of given and an underlying assumption in everything that I have written so far, I think...) I am quite happy with the list as it has developed. But you might not be, and then the best way to show it would be leaving a comment. :-)

The always challenging question of summarizing it all in a sentence? Well, how about: Be proactive and care for your team, choose common sense rather than legal fights and have fun!?

Final brief tip, #10: Look beyond the project

I must admit that I love projects. I find them energizing and really enjoy going from the unavoidable feeling of uncertainty if it is feasible at all, to a successful delivery. I also like to be able to finish off, and then start a new one – with clean sheets (for the joy of Norwegian readers, I’d like to add a reference to Alf Prøysen, who came from a place close to my mother’s, at this point: “Du skal få en dag i mårå”, which I would say translates more or less to “You’ll have another chance tomorrow”).

Even if it you are like me and are happy about finishing off the project and then start a new one, possibly a different place and in a different field: I urge you to try to win the war, not only the battle… Thus my 10th and for now final tip is worded like this:

Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

You can be sure no-one will thank you for delivering on your formal mandate, if the product you delivered does not really leave behind anything valuable or useful when the project is terminated.

For me a key aspect of project management, as well as management in general, is to pursue continuous improvement, both within the project and across all projects of the company. The more mechanistic aspects of this, with Lessons Learned logs etc., are well covered in most project management methods. But it is of course even better if you can adjust course rapidly (agile, if you will…) as the project goes along, and that is as much a question of attitude as of hefty templates.

Another classical fight is the one between short terms requirements (“give me that functionality, and give it to me now!”) and long term demands of architecture and maybe even cleaning up some old mess. Again, trying to eat the elephant in smaller pieces is key – try to build architecture project by project and if you have a large code base (and they are never only pretty), leave it just that little bit better every day. Oh, and when estimating the cost of your next project: Make sure to estimate the required time and cost to improve architecture as you conduct the project.

I am considering writing a piece about project portfolio management, arguing that this is really more than what can be achieved in a project management office or similar structures. I hope to do this sometime before Christmas. Please come back to have a look. My next piece, though – and hopefully in just a few days, will be summarizing the brief tip series of posts.

Brief tip 9: Ensure buy-in and reconfirm along the way

Wow, a new post not that long after the previous. Another brief tip coming up, which is is simply going to be worded like this:

Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on

The first part might be too self-evident, but make a mental note of the second part. It is in fact easy to forget this in the spur of the moment, and a project can often be nothing but a long sequence of hectic moments. Taking the time to involve key stakeholders, getting their opinions and buy-in (adjusting the course as required) will give you back the effort tenfold later – which may in turn contribute to more control of the hectic moments later in the project...

I think the tip is relevant on both a team level and an executive level. On the executive level, you might find yourself trying to mitigate different and conflicting interests. When this is not feasible, you hopefully have set up escalation mechanisms to get to a decision and move forward. This process also ties closely back to the second PM brief tip of managing expectations closely.

On a team level, reconfirming tasks, responsibilities and estimates are all important. This will also be a self-reinforcing loop, as team members tend to take on more responsibility when given the trust. Of course, you will have to work hard to create a context where the likelihood of succeeding give OK odds – if not the responsibility will be more like Scott Adams demonstrates for Dilbert as shown below:


I also think the principle of reconfirmation and no surprises can be used to contradict what some people seem to think about “that great final presentation of the project”: My take is that there is absolutely no point in such a “big bang" final presentation aimed at impressing and surprising the audience (often CxO-level). Share your thoughts (and software, if your project is developing any) early as much as possible, refine them along the way and deliver the final presentation knowing that the message will be understood.

Brief tip 8: Add value beyond administering

A little while since my last post. Looking back (wine, food and beaches in Tuscany and later Spain - then a surprise U2 concert as a birthday present from my wife), I can't say I got the priorities wrong. Good project management. :-) Anyway, here is another "brief tip":

As a project manager, try to add value beyond administering the project

The last year, I have completed my PRINCE2 Foundation and Practitioner certifications. In PRINCE2 there is a pretty clear advice that the role of the project manager “…is to manage, not to do”. While I see it as important that the project manager don’t loose her view of the big picture because of working on details, I actually think that it usually works better if the project manager can add some subject matter expertise or otherwise contribute beyond administering the project.

Some project managers have a technical background before being promoted to their own level of incompetence (the Dilbert Principle in all its beautiful essence). For these, taking part in architectural roles or detailed design may be a good way to be involved beyond the project administration. Others may contribute to testing, others again will have a strong hand on the business case and marketing plans.

I think you get some things for free if you as a project manager participate actively in the project (“doing”, if you will…). For instance if you take a role as a tester[2], you get project content and status under the skin “for free” that you would otherwise have actively worked to obtain.

For the team to see that the project manager is working along them (a Scrum master might very well be a developer for the most part of his time) can also be motivating and it shortens distances for communication and makes it easier for the project manager to detect problems early through informal channels.

[1] – PRINCE2 is a trademark of the Office of Government and Commerce in the UK and other countries

[2] – I do agree with PRINCE2 that the project manager should not be the same person as responsible for quality assurance though. If at all possible, it will make life easier for everyone knowing that there is two different persons filling those roles.

Brief tip 7: Choose your checkpoints

In my current job at PA, we have checkpoints, forms and procedures to ensure quality and avoid taking too much risk. That is all very fine if you have the machinery to handle that, as is the case with PA. But what if you don’t? I think you still need some sort of checkpoints (often commercially focused), even when you operate using agile methods.

I’d like to share with you what we ended up with when selecting some checkpoints for our projects at Inspera and hope you will find it useful. These are, more or less, the mandatory checkpoints we ended up with:

• Starting work on a proposal
• Delivering a proposal
• Project initiation/kick-off
• Periodical reporting of progress and budgets (here it was monthly, YMMV)
• Project sign-off, with a simple client satisfaction survey and handover to maintenance

What if you are not ready even for this level of formalism? If I should keep just two checkpoints, I think I’d go for proposal delivery (Who approves this in your company? Rules of thumbs for estimate breakdowns? Have cross-project coordination of resources been taken into account?) and of course sign-off. This would probably be in a very small environment where surveillance of risk and project status would be done rather hands on by the general manager anyway.

I guess one wording of this tip could be:

Establish checkpoints that you follow in each of your projects, even if operating in an agile way

“Even in an agile way” might sound strange, but while the almost automatic checkpoint built into many agile processes (such as the sprint review) can be combined with commercial ones, that does not happen automatically.

That was my tip #7, written at Bremen airport in Germany - traveling to Belgium this weekend with my wife who currently works in the Netherlands. If you don’t agree or have something to add, please leave a comment.

Contract templates as project placebo

There was recently an article in the Norwegian (and Norwegian language) publication Computerworld claiming that the legal framework, which was based on a template from the construction business, had helped making a large IT project successful. I wrote a response to this, together with colleague Jakob Markussen, that you can read here (Norwegian).

We put forward that project management techniques including risk management, well-defined processes, iterative development, and last but not least the collaboration and communication is more important than the legal framework template that is chosen for a project. After all, as any of us that have struggled with contracts know, the real work is in the appendices – and if you don’t have to revisit details of the contract to resolve conflicts, even better!

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):

The missing link between management information and agile methods

It is now pretty much accepted, and to some degree starting to be confirmed by actual empirical data, that agile software development can lead to better bang-for-the-buck than the traditional requirements gathering -> analyze -> design -> develop -> test iterations with comprehensive documentation in each step of each iteration. The concept is rather simple: Do not spend time on details you are unsure will have value, and always make incremental improvements to a working product that you get up and running as quickly as you can.

Also, by involving the product owner directly in prioritizing product features, adapting to changing customer requirements will be built into the process. Another element of many of the agile methods is cross-functional and often self-managed teams that respond to a changing environment, rather than following a detailed plan. When you think of it, the conceptual leap from lean manufacturing as perfected by Toyota to agile software development is maybe not that large – at least not in underlying principles.

But, even if the customer’s senior management accepts the notion of increased value and efficiency through flexibility, they are often not willing to accept the notion of just developing in a broad direction to create as much valued functionality as possible until the money runs out. Some more structured planning and reporting is expected. So how do you handle this as a project manager? This is the topic of this post and I will not go any more into the details of agile methods as such here.

Often the solution chosen, if you cannot get the customer to choose an all agile approach (which I believe in practice often means a time and material type contract), will be a hybrid. Pragmatic as I am, this is an approach I have used in some of my projects. The problem is that this often results in a missing link between the software development process and the management information. This leads to the classical situation so often captured in the Dilbert cartoon, where engineers and management live in two distinct worlds with little communication coming across with the intended information still present…

This presents you as a project manager with two challenges:

• How to translate the legal obligations and high level plans into meaningful guiding for the day-to-day work for your developers, without falling back to a detailed pyramid of specifications and the team spending a too large part of its time producing documentation that will not be used
  
• How to translate the actual work done and progress made into a world with more structured plans with fixed milestones

These challenges are of course not new, but what makes them different than just a work breakdown type of task is that the details of what happens in the execution step is not planned upfront. It thus take a lot of skill to be able to agree the right high level milestones, so that they can be reached using agile methods for the actual execution. It really is a challenge to be as specific as necessary for the customer to be confident the value will be delivered as agreed, but not so specific that it kills the whole concept of agility upfront. In my view, this is maybe more an art than a science – so I am afraid I can provide no simple checklist to achieve that goal, but it helps to know that it is a challenge and think about it upfront.

And there is no reason to paint it all black. It is indeed possible to provide those missing links. For instance the burndown charts and list of completed issues of Scrum in the agile world provide excellent input for a Highlight Report in the structured planning world of PRINCE2. Similarly breaking down a PRINCE2 Stage Plan into a product (and later sprint) backlog of Scrum or a similar method can work just fine. However, there is of course tension between the different basic philosophies that you should discuss with your client. But as long as your client buys in to the idea that you actually deliver more and more relevant products, even if she might not be willing to let go of more traditional planning, I think that this hybrid model can work better than not trying to achieve any of the benefits of agile software development at all.

Agility as a more general term is certainly a key treat for a project manager to be successful. However, my take is that the toolkit of the agile software development movement often fall way short of covering what the customer needs to feel comfortable with her project. To avoid the situation with the missing link, the project manager must be comfortable operating in both worlds and tie them together in a coherent whole, while enjoying the trust of both the developers and the customer. Then the situation will hopefully not be exactly as Scott Adams sees it below:

I have heard some argue that the role of the project manager is obsolete when moving to agile/lightweight software development methods. I’d like to argue that it is more important than ever, but more demanding – as you have to be comfortable in a broader span of processes and skills than before. I will probably return to the role of the project manager and the mapping to roles in Scrum in a later post (should she be the scrummaster or the product owner do you think?).

Remember what Keynes once wrote: It is better to be roughly right, than precisely wrong. Agile methods are a way of achieving just that, but the direction you go must be managed along the way and senior level management may not want to adapt 100% to this new way of working. As the project manager, you thus have to be the translator and understand both worlds – in other words be, or at least provide, the missing link proposed by the title of this blog post.

Let me know what you think by leaving any comments you have below. As always, I hope to learn a lot from them.

Alignment of project dimensions: A balancing act

When writing the promised piece on agile methods and management information, I found that I wanted to present some thoughts about alignment of different dimensions of projects to avoid having to make the other article longer than necessary. Thus this post first.

I have found it useful to think about the alignment of some project dimensions before signing the contract and kicking off the project. The dimensions I will consider here are contractual terms (pricing), collaboration and strength of relationship, and the software development method to be used. Your selection of variables may vary, but I insist that trying to take such a bird’s eye view is useful when assessing the risk of project failure.

Below (click to see it in full size) is four actual projects placed in these dimensions. They are all software development projects, but differ somewhat in terms of complexity of integrations, amount of front end vs. back end programming, etc. as well as size. So they are by no means a perfect academic sample set, but they are projects that I know because I have worked and lived them.

As you might guess from the topic header, my hypothesis is that some combinations of the dimensions fit better together than others. Which of the projects above would you be afraid of taking on as project manager or team member? Which did you think get into trouble?

In retrospect, one of the possible “doomed to fail” projects actually didn’t (number 4). I try to cover the reason why in my next post. The other prime suspect, number 3, did actually fail spectacularly in terms of profitability. In fact, I took over this project midway (that is when just about 110% of the budget was used…) and even without drawing out the diagrams, the missing alignment was striking. However, the end product developed was to the customer’s satisfaction and new projects will be conducted that hopefully will be better business as well.

Another way of viewing the above dimensions could be in a 2x2 matrix (I am currently a consultant, after all!). Below I have tried to do that, with development method on the vertical axis and contract/pricing horizontally. The color (blue=”colder” customer/supplier relationship, red=strong partnership) of the dot indicates the form of collaboration, to avoid fiddling with three dimensions.

In danger of over-simplifying, I’d like to make the following remarks about these quadrants:

• The bottom left quadrant is just fine, although maybe a little bit old-fashioned. You could consider discussing with the client if a more flexible approach could be more suitable (moving up and right in the chart) and delivering more value.
• You should be extremely careful if you are in the upper left quadrant. You must then be absolutely sure that you and your client have found a good way to manage scope adjustments. I would also never conduct a project in this space if it is not a strong relationship with the client, i.e. a "red dot" above. Without these two in place, this is the “doomed to fail”-quadrant.
• The upper right quadrant if the place you probably want to be operating most of the time with agile methods. Especially with a strong relationship with your client (red dot). Be sure to manage expectations both upfront and at every increment, though. Often it doesn’t help to have the legal contract on your side if your most important client is not close to satisfied after all funds are burnt doing iterative improvements.
• The lower right quadrant is probably just fine, but it indicates that although there is client/supplier trust, indicated by the choice of time&material pricing, there is actually no belief in the gains promised by agile development methods. Thus, one gets the formal overhead without really needing it to handle pricing and legal issues. But formal specifications can absolutely be a way to handle the expectations management mentioned in the previous bullet point. Some target price regimes might fall into this quadrant, but not all (for example, project 4 was a target price regime).

Another related way of looking at this, is through the classical project management pyramid – TRQ, time, resources and quality/scope. The basic idea is that you cannot change one without adjusting the other accordingly. So if you fixate time and cost, certainly the details of scope can be a variable throughout the project. This view fits quite nicely with what DSDM preaches and on the development level this is the way I find working with Scrum-like approaches most fruitful.

Of course, my comments about the sample projects at this point are with the power of perfect hindsight. But let’s look again at project number 3, where we obviously tried to do flexible development with slim specifications with a completely new customer (collaboration form is not always a function of length of the relationship, but the two are usually strongly correlated and in this case it was a new customer) at a fixed price as if it was a classical waterfall approach we were using. Was it very likely to succeed if judged upfront? I think not.

Please do not read my comments only as a way for vendors to maximize their profits and minimize their risks. The assessments of the project dimensions should rather be discussed openly with the client before kicking off the project. It is after really understanding your customer’s need you will be able to make the best trade-offs for that particular case. Project management methods, and legal contracts for that matter, has large elements of tailoring after all.

There is a lot of fuzz about the specifics of each agile method proposed. Maybe too much. To me, agile software development is actually just as much about mindset and approach as it is about specific methods. And I do think that one should make sure that the mindset and the more formal frameworks (contract, form of collaboration and actual development methods being the three sampled here) match and discuss this upfront between customer and supplier.

In an earlier draft, I considered using project size as one of the variables. This could easily have been included for example through the size of the dots in the diagram notation. I considered about 10 projects I had managed myself and a few others that I know fairly well and I did not really see size (ranging from a few hundred to many thousand hours) being as important as the variables I have proposed above when considering if agile methods will be suited. But you might beg to differ? Let me know what you think by leaving any comments you have below. I hope to learn a lot from them.

Welcome to my blog about project management and related topics

This is my very first attempt at a blog, which can be found a projectmanagementmonkey.com or just pmmonkey.com for short. After more than ten years in the Internet and software industry, you might want to consider me late or even slow. Or maybe I’ve just been busy. I think that sounds better, let’s go with busy.

My focus will be on IT-related projects, both software development and other types. The focal point of my interest is on the linking of business and technology, so this is also probably where most of the topics of my writings will be. I might also write some pieces on other stuff more or less related that interests me, such as software business models and negotiations. My aim is that the content should be of practical use, and actually change the way you view, participate in and manage projects.

I am not very ambitious in terms of volume of articles, but I will try to post a handful of small articles during 2009. I also have a little idea for some very short and practical oriented pieces called “Brief Tip” that I hope you’ll find useful.

I look forward to learn from your comments.

Welcome to my blog.