Software Quality for a Moving Target (Part 2 of 2)

>>>Software Quality for a Moving Target (Part 2 of 2)

Editor’s note: Last week I brought you the first half of the 7 best practice tips that help with the moving target. If you missed it, you can find it here.

To recap, within this post I presented the first 3 of the 7 best practices from my perspective:

1. Quantify expectations when defining the Service Level Agreement (SLA)

2. Determine clear criteria for sign off dates

3. Plan for contingency when there is a risk of not meeting the SLA

Hopefully you’ve had a chance to digest the information. And, without further delay, here are the remaining four tips:

4. Set shorter development sprints early in the project. This enables the customer to see their ideas transforming into reality early-on. It also provides more control in steering the software in the right direction. As with any building exercise, the foundation needs to be strong and sturdy for the project to progress effectively. It is increasingly difficult and expensive to make changes to the underlying architecture of the software as the project develops. If changes are required, it is best to incorporate them as early as possible. At the end of each sprint, a formal demonstration is good practice. Informal walkthroughs along the way are also a good way of setting customer expectations and correcting deviations.

5. For each sprint, set a requirement cut-off date. If changes are requested after the specified date, incorporate them into the following sprint. It is essential for all parties to realize that a change is similar to a new requirement and can potentially take a significant amount of a resource’s time to incorporate into the project. Additional features, no matter how trivial they may appear, need to be carefully considered before being committed. It is, however, important to note, that last minute changes can sometimes take a project from good to great and should be evaluated for their value and not “kicked to the curb” simply because additional costs or resources are required.

6. Every project has changes and new requirements. It is, therefore, a best practice to set up a Change Control plan. This will help to determine what should be considered a trivial versus a significant change and determine the best plan of action accordingly. The Change Control plan will allow the team to define additional resource hours required and the monetary and schedule changes in budget to accomplish the new requirement.

7. Stay in constant contact with the client. It is imperative to keep communication lines open. Don’t allow circumstances such as location or schedules to hinder communication. Make use of technology to communicate frequently and effectively, especially when personal presence is challenged. Use effective visual tools to present a roadmap and maintain strong communications for completing the project. Again, staying in sync with your client and listening to their needs and changing requirements, will allow you to meet or exceed their expectations. This will help to build a trusted relationship and provide opportunity for future work.

In summary, remember to keep your plan change-friendly, conduct the necessary research to get better estimates for required resources, schedule adjustments and costs, and keep the client actively involved throughout the process. From my experience, these best practices are the key to providing a high level of software quality under dynamic or ‘moving target’ conditions.

Roshni Datta is a Consultant II at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact Roshni at with any questions on this blog post or to further discuss software development.