Page 11 -
P. 11
Tell Everyone the Truth All the Time
The most important principle in this book is transparency. A project manager constantly
makes decisions about the project. If those decisions are based on real information that’s
gathered by the team and trusted by management, that’s the most likely way to make sure
the project succeeds. Creating a transparent environment means making all of that infor-
mation public and explaining the rationale behind your decisions. No software project
goes exactly as planned; the only way to deal with obstacles is by sharing the true nature
of each problem with everyone involved in the project and by allowing the best solution
to come from the most qualified people.
But while anyone would agree with this in principle, it’s much harder to keep yourself
and your project honest in practice. Say you’re a project manager, and your project is run-
ning late. What do you do if your boss—much to your surprise—announces to the world
that your project will be done on time? Unfortunately, when faced with this situation,
most project managers try to change reality rather than deal with the truth. It’s not hard
to see why that approach is appealing. Most people in software engineering are very posi-
tive, and it’s not hard to convince them that an unrealistic deadline is just another techni-
cal challenge to be met. But the passage of time is not a technical challenge, and if the
expectations are unrealistic, then even the most talented team will fail to meet them. The
only real solution to this problem is to be open and honest about the real status of the
project—and that’s going make your boss unhappy.
And so, instead of telling the truth, many project managers faced with a deadline that’s
clearly unrealistic will put pressure on their team to work late and make up the time. They
silently trim the scope, gut quality tasks, start eliminating reviews, inspections, and pretty
much any documentation, and just stop updating the schedule entirely. And, above all,
they wait until the very last minute to tell everyone that the project is late.., hoping
against hope that luck, long hours, and a whole lot of coffee will correct the situation.
And sometimes it works... sort of, until the users have to work around bugs or missing
features, until programmers have to start patching the software, and until managers have
to go on a charm offensive in order to smooth over rough relations among everyone
involved. Even if the deadline was met, the software was clearly not really ready for
release. (And that’s assuming the team even managed to squeeze it out on time!)
That’s why the most important part of building better software is establishing transpar-
ency. It’s about making sure that, from the very beginning of the project, everyone agrees
on what needs to be built, how long it will take to build it, what steps will be taken in
order to complete the project, and how they will know that it’s been done properly. Every
tool, technique, and practice in this book is based on the principles of freely sharing infor-
mation and keeping the entire project team “in the loop” on every important decision.
INTRODUCTION 3