Show Some Resolve | ||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
||||||||||||
 |
[ Login/Subscribe ] | |||||||||||
 |
||||||||||||
 |
 |
 |
 |
 |
 |
 |
|
 |
||||
 |
||||||||||||
Features
Departments
Opinion
Executive
Resources
|
Home > Departments > Methods & Means
In the face of unrealistic schedules and ill-defined or changing requirements, defects on software development project are inevitable. But the rush to report a resolution can make the problem worse or create new ones. Here is a rigorous, six-step approach to issue-resolution that ensures 'fixed’ means fixed.
When it comes to resolving issues on software development projects, It is the project manager’s responsibility to exercise due diligence and leadership. While time is money, a quick assertion that an issue is resolved without proper verification often results in subsequent questioning by the client and additional time spent supporting your findings or, worse, backtracking.
Taking a rigorous, systematic approach to issue-resolution is imperative. The project manager must coach the technical team on what it means to say, “it’s fixed” — from both a client and application standpoint. The project manager must also take responsibility for first-hand verification that the issue is resolved, and for communication with the client and team before, during and after the fix. To state that an issue is resolved means that the project manager, technical resources and QA team were collectively able to complete these six critical steps:
1.
Please login/register to read the entire article.
| |||||||||||||||||
|
Privacy Policy Contact Us User Agreement