A few years ago I was doing some work for an organization that held sporting events for developmentally disabled people. This organization needed some software to manage an event they were staging and during the RFP (Request For Proposals) process, there were, to the best of my knowledge, only two finalists. One was a company which had already written the software for the organization and had used it successfully to run several events. They had done this for free because they believed in the organization’s mission. They were only charging for the extensive setup, configuration, and data entry that would be involved.

The other company was newly involved with the organization, didn’t have any software written and their proposal was at a considerably higher price as a result. This company, however, was donating a large amount of money to the organization, even though they hadn’t worked with them much and didn’t understand the actual needs of the organization. Guess who won the contract? The company with the proven and free software, or the company who was donating a lot of money but had no software and little experience in this area?

The company with no software took the organization’s rule book and used this as a spec for the software they were writing. They went away for several months and they came back with software that everyone agreed matched the rule book yet was completely useless. After several improvements, the software still failed to be useful. Why? Humans. They forgot that they were dealing with people instead of rules and they didn’t talk to the people who actually ran events.

Just imagine that you’re working for an organization and someone with an IQ of 80 doesn’t complete a form correctly or shows up at a race 5 minutes late. Do you disqualify them? No. Mr 80 IQ doesn’t understand and, in any event, that’s not what you’re there for. Heck, some of these people, after the race started, would just stand at the starting line, just happy to be included in something, anything. These were wondeful people who were happy just being around other people. That’s what it’s really about; it’s not about a rule book. The organization that went “by the book” failed to realize that they needed software that accomodated humans, not the other way around.

This is actually one of the largest problems in project management today. In one project I worked on, I was the new employee who didn’t have a clue what was going on so I took the advice of my boss and had face-to-face interviews with everyone who knew the problem domain I had. I not only finished early, my piece of the project was the only piece that worked when the million dollar plus project was later cancelled. Does this mean I’m brilliant? Not at all. It meant that my boss, though he wasn’t in the project, knew that face-to-face communication trumps all.

This is the problem with so many project management systems today. Project management, at its core, is a process by which we try to produce the greatest value at the lowest cost. That’s it. And how does project management do this? By lowering search costs. In economics, search costs are the costs of acquiring information. Whether you pay for it, research it in books or on the Web or just discover it for yourself, the more time you spend searching for information the less time you have to develop your product. How many times have you had a project blocked while you’re waiting for information? The strongest project management systems focus on making it clear where to quickly get information at every stage of the game. Sure, some project management systems use their Gant or PERT charts, UML diagrams, network maps and reams of detailed specifications — sometimes down to the API level — but while those tools are sometimes useful, they’re a means to an end, not the end itself.

One fun trick you can use to verify the importance of lowering search costs is to have a developer sit down with someone who is actually going to use the product being developed. I’ve heard plenty of developers proclaim that they know their software much better than their customers do and those developers are right. When they make this almost useless claim, what they forget is that the customer usually knows their job much better than the programmer. I can’t tell you how many times I’ve heard of developers who’ve sat down with a customer and walked away being able to make a much better product. They went to the source of information and lowered their search costs (having layers of bureaucracy to pass this information on is the adult version of the children’s telephone game). This also explains why so many outsourced projects fail. Outsourced labor may be cheap, but unless you can solve the search cost problem, you’re in big trouble.

Given all of this, why do so many Extreme Programmers swear by by XP? Because XP helps to lower search costs. XP teaches that you want to have a customer available. Not always easy, but if it works, it’s great. XP recommends pair programming — this is effectively a continuous relevant training course for programmers (one which is sometimes problematic, to be honest). XP recommends daily stand-up meetings — no more discovering “too late” that you’re breaking someone else’s code. XP recommends release early, release often. You get immediate feedback on what works before finding out that months of work is useless. XP recommends story cards. It’s often much easier to get an overview from a story card than to search for section 7.3.IV.a in the project specification produced months ago.

If you want to be an effective project manager, lower your search costs. Have people talk to people who matter — not sit around in meetings that don’t matter. And on that note, I’ll leave you with one of the most politically difficult meeting management strategies you can have, yet one of the most valuable: leave when bored. If the meeting doesn’t pertain to what you’re doing, you know you’re wasting your time and you get bored. When that happens, you should be allowed to leave. Have everyone who calls meetings respect the “leave when bored” policy. After having a few meetings of half the people getting up and walking out, managers will learn quickly how to keep things focused or their managers will ask them why they keep holding useless meetings.