Ensure PC software is up to date
During a recent consulting engagement, my task was to enhance a production system written in an aging technology. (They chose me for the project because I'm the system's original author.) The engagement's objective is to add a series of reports that would be easy to develop and deploy. However, to achieve this goal, I would have to use and leverage the technology that is in place. In my opinion, that's a bad choice. Continuing to develop and enhance a system built on obsolete technology is a recipe for disaster, which is a difficult but important fact that I delivered to my employer.
If your organization finds itself in this situation, you only have one choice: to replace the current system. Staying with an aging technology, regardless of how well it meets prior requirements, means increased cost and risk. Even if the organization is willing to accept this, you're only delaying the inevitable. At some point, the increase in cost and risk becomes insurmountable, or requirements change enough that a new system is more cost effective.
Even so, the decision to move to a new system isn't necessarily cut and dried. Many times, there is an external reason for delaying a system replacement. Other times, a new system doesn't exist that meets specialized requirements. (This is a real possibility in specialized applications.) Other examples include a pending technology shift such as moving from one hardware platform to another, merging with another IT shop, or even waiting until the next budget cycle.
Replacing a system that is in this situation requires a larger initial cost investment, but it also provides the opportunity to address many secondary requirements that may not have been technically feasible or considered too costly under the old system. The actual solicitation and procurement process is similar to that of a new system, except that the system requirements are well known. The project itself becomes a full system implementation with all the necessary project management requirements.
The above scenario is all too common in business today. Large organizations that rely on well-developed portfolio management systems for their enterprise applications often ignore or simply don't know what is installed on the desktop. Other organizations rely on departmental management of the organization's desktops. In any case, without proactive review by knowledgeable personnel of all business production applications, this problem will occur.
To assist organizations in avoiding this scenario, I recommend some level of organized portfolio management. Standardization of desktop applications for common business functions such as email, word processing, spreadsheets, or other applications will limit what the organization needs to maintain. It's also necessary to identify the organizations' specialized systems, including its software and hardware technology requirements.
Finally, a portfolio isn't worth its salt unless someone actually manages it. This includes performing routine comprehensive audits of all systems to ensure the portfolio is up to date and organization is adhering to standards.
Scott Withrow has more than 20 years of IT experience, including IT management, Web development management, and internal consulting application analysis.