In Articles

When businesses turn to software developers to modify reports, workflows, and general system functionality, they too often find themselves saying, “It still isn’t right!” The truth is, developers often think in ways that are unfamiliar to those who don’t have a technical background. If there are any holes in receiving development requests, the technical team is left to fill in the gaps by making assumptions. These assumptions are rarely correct and often result in frustration from both sides.

This same principal applies to visiting a foreign country without speaking the native tongue. Google Translate is quick and easy to use, but not 100% effective in conveying the message. Translation tools give literal interpretations, but sentence structures vary across languages and idiomatic sayings are rendered meaningless in word-for-word translation.

Businesses can avoid miscommunication and thus the burden of costly, wasted development time by following these steps:

1. Conduct discovery sessions

Business areas often communicate development requests in passing or between meetings, and a true understanding of the request is lost. Schedule a formal meeting to discuss new development efforts so the development team can fully understand the issue. During discovery sessions, the business should provide a visual of how data is currently displayed and how it should look in the future. Pull in a projector and walk through software and reporting portals to ensure developers understand how data is presented in the user interface.

2. Document business requirements and establish a timeline

Following discovery sessions, the development team should create requirements documentation. Present documentation in a consistent format that outlines the purpose of development requested, business use, general requirements, business rules, and an expected completion date. The business must sign off before development starts. This will ensure the technical team is not left to make assumptions, which generally results in the business paying for wasted development. Signatures show both sides understand expectations for delivery.

3. Keep a development log

A log of development requests allows the business to track tasks currently in progress and mark backlogged items. Finalized modifications should be marked complete in the log and communicated to business users impacted by the change.

Development logs are also a useful reference tool. New team members can refer to the logs to understand what standard software functionality has been enhanced along with business justification for the updates.

4. Perform preliminary testing before releasing to UAT

It is common for development teams to only verify coding changes in backend databases where they are most comfortable working. To be thorough, development teams should also verify that changes are displayed on the front end where information is available to the business. Check for updates in both places to mitigate the risk of having users test updates before they are ready.

5. Require business signoff to promote updates to a live environment

After coding updates have been verified, they should be released to a clean testing area where the requester(s) perform User Acceptance Testing. During this time, the business will run through test cases and scripts to ensure the updates do not impact the full end-to-end process. The assigned tester should provide proof of the successful test run, which will indicate that the fix is ready to be promoted to the live environment.

Working with a development team can be difficult for non-technical people. IT vernacular can be as intimidating as a foreign language, but running through these simple exercises will eliminate wasted development efforts. Trenegy works with businesses and development teams to smoothly manage large-scale system implementations.

Recent Posts

Start typing and press Enter to search