Or "Yes, You Can Mix and Match"

Just to reassure you: yes, you can use different techniques together. I will take as an example the usage of burn-down charts as described for Crystal Clear. However, this technique can also be found elsewhere, as in Scrum and Extreme Programming. A burn-down chart is a chart that reflects the progress made on development. It will list the number of features on the y-axis and the time on the x-axis. As time progresses, the line should go down.

In more plan-driven methods, an updated Gantt chart can be used to indicate the progress. However, I like the simplicity and effectiveness in communication of this style of chart. In one clear image it says it all about the progress of development. Another nifty thing is that you can indicate scope increase in a clear manner (second chart in the figure). If you are on a tight deadline but users keep on adding requirements (scope increase), you can just up the line for the number of features left to complete and draw a new estimate line. By leaving the original line in the chart, you
make it very clear to the sponsors that you are running late because of the increase in scope.

Regardless of which method you use, even if plandriven like PMP and Prince 2, you can use this method of communication.

Or Not Every Single Process Component Is Effective Alone

Although I propose picking different techniques and process components from every method that you can lay your hands on, this doesnt mean that you can just pick a single piece from a method and hope it will work.I stress that an issue should be tackled by the introduction of a certain process component. A certain risk should be reduced. So sometimes this means that you have to add another piece in tandem with the technique you had in mind. They go hand in hand, and one without the other would be useless.

Alistair Cockburn provides a nice example in his article, "Are Iterations Hazardous to Your Project?". Simply doing iterations in development without involving the users in the intermediate results is just wasting your time. Iterations are intended as a feedback mechanism; just iterating without the feedback part will make the techniques ineffective. In the words of Cockburn, "Danger grows when the results of the iteration are not directly linked to delivering the product to the end user".

Or Different Circumstances, Different Effectiveness in Techniques

Traditional approaches (read "plan-driven") will dictate that you first specify in detail what you want, before you start building the software. In the rigid approach, where you may not code anything before the design is approved, we call this the "Big Design Up-Front".

Photography by HouseOfText.

We all know that the Big Design Up-Front (BDU) that we all used in the old days is dying out. Its purpose is to define everything that has to be built up front, so the process is nice and predictable. In the last decade, we found out that this is not such a good idea after all. The requirements change or are even unknown, so what is specified up front will be wrong, anyway. BDU, as a tool for feedback to the end users on what has to be built, is dead (or should be). The lean and mean validation process of short iterations and close end user cooperation provides more promising results.

However, feedback and validation to end users is not the only purpose of BDU. The design is also used to solve risks of miscommunication between parties and can be used as a formal document (as for contracts). If you have multiple parties that are not in the same geographical location but are working in parallel on highly connected system components (like interfaces), you might need a big design in the beginning. It will function as the main source for all parties to perform their tasks.

If you are going to work in a highly political, blame-it-on-the-other-guy environment, you'd better over your back and create a large document in the beginning describing what you are going to create, to be part of the contractual agreements.

Some professionals might have the tendency to take an attitude like, If they can't tell me what they want, we shouldn't even bother. In theory, you should be able to get at least close to 80% on paper up front. But sometimes it is wiser to support the users in their "I know what I want when I see it" mood just to be able to proceed and to get something useful. This is better than forcing large requirements and design sessions and having binders of documents that are mostly hard to read for end users (if they read them at all).

This is a sample of how techniques can be helpful under different circumstances. Even the old techniques everybody complains about (or defends heavily) serve their purposes. Also, the agile alternatives to BDU (iterative, close user involvement, and so on) have their risks (in no particular order, and without any intention of being complete):

• Miscommunication when there is a distance in team members in time or geographic location
• More vulnerability to changes in project team members
• Shorter planning horizon, so more difficulty in planning/estimating costs for the whole (not every customer can handle this)
• Risk of requirements inflation (end user communicates directly with developer)

What is the most important task of a Project Manager? (makes a great dinner discussion if you want to get rid of your guests :))

Planning? No!
Control? You wished… NO!
Communication… HECK NO!

The answer is… allocation of scarce resources.

Come again?

You have limited time, your money pit is not without bottom, you have only a handful of team members, you have all those elements that you can only deploy in a certain way, and it's your job to allocate them in such a way that is most ideal in certain circumstances. 'Allocation of scarce resources" is the name of the PM game.

To be able to do this you need those risk analysis logs.
You need list of requirements that are prioritized.
You need a plan to see how decisions might affect current ideas about the future.
You need a clear goal to have a beacon to steer your project towards to.
You need communication to get the right information to base your allocations on.

You all need that. And more.

Still, on top of all this… allocation of scarce resources.

It is like a game of chess, it is all about moving your pieces.

And before anyone asks… most important PM skill is the ability to negotiate.

Project life can be quite frustrating when one day after another turns out not how you planned it. The software should be ready when you said it would. It has to. Otherwise you have people waiting, customers complaining and bosses getting annoyed. It is your reputation and ultimately your job on the line. If you just plan harder, more detailed, than the plan must be correct. Right? Of course not. I know, it is becoming some kind of mantra for me, but, yes, it is a shocker for a lot of people, you can't force reality in sticking to your plan. Forget it. It is not going to happen. Ever. Because it seems to be a habit hard to break, a state of mind hard to get rid of, it is worth spending a little closer look into this matter. Why can't we predict project future?
Read more

Managing Agile Projects is a book edited by Kevin Aguanno, a noted speaker and educator on agile project management. It describes techniques for managing projects in environments where the scope is constantly changing. This book is about techniques common to nearly all of the agile development methods (Extreme Programming, Scrum, Feature Driven Development, DSDM, Lean Development, Crystal Methods, Agile Software Development, Agile Project Management, etc.) that you can use to reduce risk, improve quality, and dramatically increase customer satisfaction in high-change projects. Chapters were written by the gurus of the agile movement: Scott Ambler, Alistair Cockburn, Ron Jeffries, and many others.

All author royalties from this book will be going to the International Red Cross for disaster relief.

A good time for me to have an interview with the editor.