Enterprise-Level Business Systems Development Standards
Although you may deliver quality systems without following any formal process or standards, having standards in place greatly increases the chances that you will design, develop, and deliver those quality systems.
Your implementations of enterprise applications will likely vary from those you’ve read about. Use these differences and similarities to help you better understand why standards in general are important and specifically why corporate standards are critical. Compare the various standards to your own organization’s standards. How are they alike? How do they differ? What changes might you want to make to your organization’s standards to help them be even more effective? Why?
At Pfizer they are constantly announcing an upgrade release – then backing off on that date because an error was discovered the day of the release! Sound like Microsoft? Pfizer programmers are all contractors, hired for 3-6 months for a specific project then sent on their way. They had nothing to gain in maintaining the integrity of their work, often not even seeing it deployed.
At Bristol-Meyers Squibb there used to be a position called a Process Manager, and one was assigned to each of the company’s pharmaceutical divisions. This is the person who made sure that applications to be released to the users were functioning properly and compatible with existing systems. These people made sure that the software was needed, amended and tested properly, tested with the system, and tested by users before it was allowed to be installed on any user’s machine. There was a lessons-learned review afterward – what errors occurred after the release, and what can be/was done about the errors. All of this was documented at each step. This is the way it should be done, especially in large companies where so many users would be affected. Hundreds of applications were released daily to different departments; if a full-scale deployment, such as MSO to all desks, was planned, all other deployments were held off until it was completed. If all process managers were on their toes (and daily telecoms as well as a Change Control Committee ensured they were), B-MS ran as smoothly as NASA. Programmers and other IT staff were long-term if contracted, but most were in-house. Contractors were often hired into FTEs, so they always had a stake in the outcome.
Pfizer does have one great preparation. Since I wrote test scripts for system and user testing, they had a special setup in their IT headquarters; there I would enact a system test script and each key stroke would be ‘recorded’ into an electronic script. This way, when they wanted to change an OS (operating system), they would execute these electronic scripts on all the versions of software currently in use, to see if the new OS could handle the applications; where it couldn’t, the programmers would have to write new code for the application.
In these difficult economic times, a process manager is overhead; usually this role is taken over by a Project Manager, who is selected from a related technical or business department strictly for that project. This can lead to disaster, since these people often don’t have the nerve to admit weaknesses in knowledge (could cost him/her his/her job) of either side of a software development project. The team for a project is often ‘dictated’ from above. Therefore there may be good programmers in with lousy testers and vice versa. It is up to each member of the project team to not only do his/her best, but to assist others on the team who have less experience.
The problem of program size can be addressed in one of two ways – either have in-house programmers who “own” their programs (doing all new versions, corrections or enhancements), or use an outsource with a track record for the type of program you are interested in.
Pfizer, as I said, hires short-term unknowns for its programming, resulting in badly written work with grammatical and spelling errors in the user interfaces. The Requirements Document must reflect failures in previous programming and their solutions, as well as immediate plans for upgrade. I think Pfizer is also open to a security gap by hiring these strangers and giving them access to sensitive information.
On the other hand, General Dynamics set up a separate division, called the Data Systems Division, with setups in all major cities, just to write programs for General Dynamics. The result was a bunch of programmers who really got to know the business systems of their local divisions (like the building and maintenance of helicopters or submarines), a ready set of SMEs (Subject Matter Experts) from the Navy, and a library of standard code for adaptation to specific needs.
Risk analysis is probably the most challenging part of project management, but it helps avoid pitfalls. And it should include the weaknesses of the resources, such as a programmer who is new to the application.
In conclusion, standards apply not only to particular software applications, but must equally be applied to the people involved in a systems development project. The client company should have standards of the business responsibilities, and the development team should have standards as to what they will deliver and how.
Standards need to also be applied to hardware and software to be delivered. A good enterprise will have a series of standards that need to be met in documentation, format, methods and responsibilities. This expands if the company is overseen be a federal agency such as the FDA or the EPA. When a company has a set of standards on hardware and software, the subsequent projects have a much greater chance of success.
Standards should be based on best business practices, and should have as a goal the maintenance or improvement of a company’s integrity.
Copyright 2010: Bonnie-Jean Rohner. This text may not be copied in whole or part without written permission of the author.
