If you have more work than you can possibly get done, as many of us are in IT, you may find that the structure of Project Management can be very helpful in creating organization from chaos. Formal project management generally functions using repeatable processes which fosters consistency among your projects. Believe it or not, the additional work put into creating structure and repeatable processes will be well worth it as it will actually reduce re-work because quality will improve.
Here are few practical suggestions you can implement to get you started.
Don’t Allow Email Requests
Requests for items like data base changes and code table changes should be formally tracked either in your work tracking system or a spreadsheet. This little bit of formality will keep requests better organized and prevents missed requests. It also reduces the stress of the person(s) responsible for handling the requests because they are not being bombarded with requests through email. Instead your work tracking system will provide a common place for all requests and the statuses of these requests can be managed across all regions from development to production. You can add further accountability by creating a meeting standard for the developer to discuss the database changes and the impacts to the system.
Your Work Tracking System is not a Requirements/Design Document
In the rush of trying to get code fixes in, people will often cut corners. One of their favorite ways? Not documenting code changes, particularly for bugs, leaving the testers in the dark as to what to test. The result, testers test to a conversation rather than to a requirement. Empower the testers to have the following rule: They do not test anything without a document. To assist with this create a bug-fix template that is a simplified version of a requirements/design document. This forces the developer to state the problem reported, the bug found and the solution to the problem. In the end the testers can verify that the problem reported is now resolved.
The Requirements Document should be used as a checklist
If the requirements are written properly, meaning they support the higher level documents such as the Business Process and Business Requirements, it can easily be used as the anchor to the entire project for developers and testers. The developers should still create a technical design document that testers can refer to in order to understand how the requirements are being met, but the requirements should be checked off by both developer and tester when each is met. This holds everyone accountable, including the requirements writer. Just be prepared that the requirements person will have to stay engaged throughout the project in order to make necessary changes.
If you are new to IT development management or you are trying to figure out ways to improve your processes, the above strategies should help you get started. Overall, these changes will improve the quality of your product.