All Pain, No Gain | ||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
||||||||||||
 |
[ Login/Subscribe ] | |||||||||||
 |
||||||||||||
 |
 |
 |
 |
 |
 |
 |
|
 |
||||
 |
||||||||||||
Features
Departments
Executive
Resources
|
Home > Features > Case Studies
Focusing on a higher-level definition of project success (including an understanding of the client and context) can do a lot to prevent unnecessary requirements. But some will creep in anyway, so you may need to find a way to gracefully resist.
This article is one in an ongoing series that invites project professionals to share practical advice, personal insights and pet peeves based on their experiences in the field. Anonymity, if desired, is assured. To submit an article for consideration, contact the editor.
It was late morning, second day of the review, when I first smelled something just a bit wrong with this project. It was a critical project, one that was needed, well, yesterday, because it was the replacement for an earlier system that hadn't worked as well as planned. More precisely, the earlier system hadn't worked at all, so getting its replacement out the door and into the customers' hands was beyond critical. Alas, even though the review was being held early in the design stage, the project was already behind schedule; the best estimates were that the system would ship nearly six months after the original target date.
The problems seemed to center on data integrity — in particular, integrating a commercial software package that would maintain and continuously update duplicate copies of the database on separate disks. Please login/register to read the entire article.
| |||||||||||||||||
|
Privacy Policy Contact Us User Agreement