| Home Page | Contents | Index | Comments? |
| Chapter — Curmudgeon's Corner |
| Next — Seven stages of a project |
1. Define the problem before attempting to solve it.
2. Fix the problem, not the blame.
3. Use tools that help solve the problem rather than attempting to force the problem to fit the available tools.
4. Define the data model before attempting to develop tools to access the data. Conversely, it is impossible to know what should go into the model without understanding what you want out of it.
5. Data are of no value without metadata.
6. Document! Document! Document! Use common English instead of jargon and acronyms, though that has the disadvantage that others may be able to understand you.
7. Difficult as it may be, try to keep management and the Indians all headed in the same general direction.
8. Deadlines set exclusively by management will never be met. Get some feedback from the troops as to what is remotely possible before making blue sky promises.
9. Be prepared for earthquakes and other upheavals. They are a sure indicator of high stress levels and, if unrelieved, make catastrophes inevitable.
10. Integrate all the hardware, software, and team responsibilities at the beginning of the program.
11. Don't believe any more than 10% of any vendors promises, and be even more skeptical of your own. You are never in so much trouble as when you start to believe in your own infallibility.
12. Poor planning is never cause for declaring an emergency. However, it is commonly cause for reviewing project management.
13. Projects that give precedence to appearance over substance don't succeed.
14. My way likely isn't the best way. Your way probably isn't extraordinary either. But some combination of both, plus a lot of factors neither one of us considered, is probably a pretty good solution of the problem. Murphy will have a few things to say as well.
| Home Page | Contents | Index | Comments? |
| Chapter — Curmudgeon's Corner |
| Next — Seven stages of a project |