Page 12 -

Trust Your Team

If you are a project manager, it’s your job to be responsible for the project. That means
that you have to do whatever it takes to get the project out the door. But it does not nec-
essarily mean that you know more about the project than everyone else on the team. Yet
many project managers act in exactly this way. They arbitrarily cut down or inflate any
estimates that they don’t understand, or that give them a bad gut feeling. They base their
schedules on numbers that they simply made up. And, most importantly, they make every
project decision based on how it will affect the schedule, instead of considering how it will
affect the software.
Managing a project is all about forming a team and making sure that it is productive. The
best way to do that is to rely on the expertise of the team members. Any project manager
who tries to micromanage his team will immediately get overwhelmed, and the project
will come screeching to a halt.

Every single role in a software project requires expertise, skill, training, and experience.
There is no way that one person can fill all of those different roles—she would need sev-
eral lifetimes just to gain enough knowledge of each discipline! Luckily, nobody has to do
it alone: that’s why you have a team full of qualified people. It’s up to them to recommend
the best course of action at each stage of the project; it’s up to you to make informed deci-
sions based on their recommendations.
If you don’t have a good reason to veto an idea, don’t do it. Usually, the people on your
team know best what it takes to do their job. The most important thing that you can do to
support them is to trust them and listen to them.
However, you cannot blindly trust your team. You need to evaluate their ideas in relation
to solid engineering principles. This is why the first part of this book goes beyond “tradi-
tional” project management (creating project plans, developing estimates, building sched-
ules, etc.) to cover all parts of a software project. Every project manager needs to
understand at least the basic principles of software requirements engineering, design and
architecture, programming, and software testing in order to guide a software project
through all of the phases of development.

Review Everything, Test Everything

Reviews get a bad rap. Many people see them as frivolous. “In a perfect world,” many
project managers say, “we would review all of our documents. But we live in the real
world, and we just don’t have time.” Others feel that the only reason for a review is to
force various people to sign off on a document—as if a signature on a page somehow guar-
antees that they agree with everything that it’s stapled to.

The purpose of a review is not to make a perfect document or to generate a page of signa-
tures. Rather, a review does two things: it prevents defects in the software and it helps the
project manager gain a real, informed commitment from the team. What’s more, it’s

4 CHAPTER ONE