Technical Temptation to"Solve" Problems

It is very tempting to jump at a technical solution right away, especially for those that love solving problems.

Given a new project that two teams in separate buildings need to work on, how can you get them to work together? This question came up in one of my project management classes and answers from IT students included Web-based software and networking the buildings.

The instructor wanted the class to consider low-tech solutions. Maybe the teams could be consolidated into one building, for example.

As a non-academic example, I'm working with a team dealing with missing data in a text-based data file that's preventing them from connecting two systems. The temptation is to "solve" the problem with a script or batch job. I'm glad the team considered this but has a preference for a more robust and "supportable" solution.

In context, the specific software connects multiple systems involving five or more parties including telecom, database and server administration, a support partner, the software vendor, and a hardware vendor. The team doesn't want to introduce a customization that could slip between the parties when it's time to troubleshoot issues.

The business concern for supportable interfaces trumps an "easy" fix. From a project-perspective the quick, clever, or brilliant technical solution doesn't always meet the business needs.