The Art of Project Management - Scott Berkun
ISBN: 0596007868Date read: 2006-11-19
How strongly I recommend it: 5/10
(See my list of 360+ books, for more.)
Go to the Amazon page for details and reviews.
The best book on how to oversee projects to completion.
my notes
=========== SCHEDULES ============
Schedules serve 3 functions : allow for commitments to be made, for people to see their work as a contribution to the whole, tracking of progress.
Schedules give the team a tool to track progress and to break work into manageable chunks.
Big schedules should be divided into small schedules to minimize risks, increase frequency of adjustments.
Breaking things down into one-or-two day sizes helps people understand what the work is that they need to do.
A good schedule gives a clearer view of the project, flushes out challenges and oversights, and makes it more likely that good things will happen.
For ANY project, break the available time into three equal parts: (1) DESIGN, (2) IMPLEMENTATION, (3) TESTING.
The zero-sum nature of projects surfaces : adding new features requires more than just a programmer implementing them, there are unavoidable design and testing costs that someone has to pay.
The earlier estimates are made, the less accurate they are, but rough estimates are the only way to make a starting point for better ones.
When schedules slip, there were hidden or ignored costs that were never accounted for.
Schedules should be made with skepticism.
Create detailed schedules for limited periods of time only.
A schedule doesn't have to be perfect, just good enough for the team and leaders to believe in, provide a basis for tracking and making adjustments, and have a probability of success that satisfies the client.
If leaders acknowledge weak estimates in the schedule, and are comfortable with greater schedule risk, there's nothing wrong with weak estimates. On smaller, faster projects, rough estimates may be enough.
Good estimates are everyone's business, and it should be the work of the entire team.
Lack of clarity on higher-level objectives has a direct influence on the low-level assumptions programmers make.
QUESTIONS THAT HELP CATCH SCHEDULE PROBLEMS:
* Were sick days, holidays and vacation time for all contributors included?
* Do individuals have access to the schedule, and asked to report regular progress?
* Is someone watching overall schedule on daily/weekly basis?
* Does the team feel ownership and commitment to the schedule? (If not, did they contribute?)
* Do leaders add more feature requests than they help eliminate? Do leaders say "no" to new work and provide a philosophy to the team for how to respond to new (late) requests?
* Are people on the team encouraged to say "no" to new work requests that don't fit the goals and vision?
* Are there moments in the schedule when adjustments and renegotiations can take place by leaders?
* Are specs and design plans good enough for engineering to make good work estimates?
* Is engineering trained in making good work estimates?
============= WHAT TO DO : REQUIREMENTS, STATEMENTS ==============
The hardest single part of building a software system is deciding what to build.
A requirement is a carefully written description of a criterion that the work is expected to satisfy.
Good requirements are easy to understand and hard to misinterpret.
Vision documents directly define the "what" of a project.
Specs define the "how" of a project.
Work breakdowns define the "how" of a project, from a team perspective.
Specs are complete when they provide a workable plan that engineering can use to fulfill requirements.
A vision document is where all of the perspectives, research, and strategy are synthesized together.
The simplest tool is the use of requirements.
A requirement is anything the team (and client) agrees will be satisfied when the project is completed.
Problem statements are 1-2 sentence descriptions of specific end-user issues, written in a format that identifies a problem or need from the customer perspective.
Problem statements are broader than bugs, because their goal is to capture what's missing from the customer perspective, instead of only what's broken from the technical perspective.
Problem statements should remain purely about customers and their needs.
Problem statements need to be converted into feature statements / scenarios.
Feature statement is a short description of something a customer will be able to do as a result of the project or tasks they will no longer have to do because the project automates those tasks for them.
Avoid any description of how these benefits will be achieved.
Feature statements should never describe a specific solution or design, but should instead explain the solution's impact on the customer.
Require a temporary ban on solution proposals during discussions of problem lists and scenarios.
Postpone discussion about design alternatives. Focus on clarifying the real goals of the project, ordered by importance.
Problem statements and scenarios are a simple way to define and communicate requirements. They are easily converted into design ideas without losing clarity about what's important and what isn't.
============= WRITING THE VISION =====================
The challenge of project management is not only to get things started up in the right direction, but also to keep it headed that way.
Writing things down makes it possible to define engineering work or capture the overall objectives for entire teams only once, then reuse that knowledge many times.
SIMPLYFYING : The vision should have a simplifying effect on the project. A good vision will provide answers to the core questions individuals have, and will give them a tool for making decisions in their own work.
GOAL-DRIVEN : A well-written goal defines a clear intention. Enough information is provided in the goal itself, that people will know when it's been completed. The fewer high-level goals, the more powerful the vision document becomes.
Try playing devil's advocate : ask how a project can still fail if its goal is satisfied as written. Consider if there is a way to more carefully phrase the goal.
INSPIRATIONAL : Give the reader a clear understanding of the opportunities that exist. Provide a solid plan for exploiting it. Make everyone understand the real-world problem to be solved, not just the technical one.
MEMORABLE : The ideas need to make sense and be interesting. Resonate with the reader. If the vision is too complex, it's impossible to achieve this effect. Be direct and honest. Clear and confident. Give the team strong concepts and ways of thinking about the work.
KEY POINTS TO COVER:
* What is the one sentence that defines this specific release of this specific project?
* How does this project contribute to the goals of the organization?
* Why is this project more relevant than anothers that also might contribute to the goals of the organization?
* What customer features are essential to this project? (Priority #1)
* What customer features are desired but not essential? (Priority #2)
* What solutions for customers have been requested but will definitely not be a part of this project?
* Who are the customers?
* What problems does this solve for them?
* How will customers get their job done without this project?
* Why will these customers buy this service?
* Who are the competitors?
* How will this project compare to theirs?
* How is this NOT a technology in search of a problem?
* What is the project NOT going to accomplish? (List things people might assume would be part of the project, but won't be.)
* What are some likely ways for this project to fail, and how will they be avoided or minimized?
* Who else is this project depending on in order to succeeed?
* Who else is depending on this project in order to succeeed?
* What assumptions are being made that the project depends on?
VISUAL:
We forget the power of images in expressing ideas.
The best vision documents include visual images.
Filmmakers use storyboards for the same purpose.
Showing a sketch of the final thing allows ever individual to put his own work in a larger context.
If this end result cannot be visualized, the vision is not clear.
DAILY WORSHIP:
Keep the vision visible : the few core goals should be up on posters in highly visible places.
Ask the following questions at every meeting:
1. Does the vision accurately reflect our goals and intentions for this project?
2. Is the vision helping people make decisions and reject requests that are out of scope?
3. Are there changes to the vision docs that would make #1 and #2 true?
The vision should not be modified frequently. Major changes should be rare after the project is moving at full speed.