In Closing... | ||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
||||||||||||
 |
[ Login/Subscribe ] | |||||||||||
 |
||||||||||||
 |
 |
 |
 |
 |
 |
 |
|
 |
||||
 |
||||||||||||
Features
Departments
Executive
Resources
|
Home > Departments > Methods & Means
Whether you call it the post mortem, a lessons-learned session, or the end-of-project review, a formal closeout process that gathers and preserves project data is a crucial step for all initiatives. It not only details what went right and wrong but also why.
Sean F. was a seasoned project manager. In his 30 years in project management, Sean had consistently been given responsibility for larger and larger projects. And his sheer talent had earned him some plum assignments. For the last three months, Sean had been spending day and night at the office of a new software house, wrapping up a project he’d inherited prior to joining the firm. It was a good project — the release of new software that helped Web designers write code, and Sean, by and large, was happy (though he felt that better coffee was called for in the break room).
Then all hell broke loose. A week before release, Sean found a small piece of code that, when called, caused the software to crash. And not only did it cause the software to crash, it caused the user’s system to tank as well.
But there was another, more vexing problem. No one seemed to know who wrote that code, or how it got there.
Please login/register to read the entire article.
| |||||||||||||||||
|
Privacy Policy Contact Us User Agreement