While the modernization that is being discussed here is dated, the lessons to be learned still applied.  Prior to web-based systems, the previous phase was client-server.  Transitions to client-server were made from mainframes, which were green screen and virtually no graphics.  Actually, the client-server was the first technology to use a graphic user interface (GUI).  This transition from mainframe to client-server was being done within a center responsible for collecting scientific and engineering information and making it available to scientists and engineers within the agency and the research universities.  The modernization also included the early uses of the the Internet, at the time reserved for research institutions and government.  Actually, the work done here was recognized in both the use of the Internet and the early implementations of the client-server.

Challenges that arose in the transition included:

• Developing Technology – Technology was changing rather quickly.   Object oriented languages were being developed.  Pascal was an early language and Borland was using Pascal as a basis for its development platform Delphi.  This was one of the first Rapid Application Development tools on the market.  It provided developers the ability to layout the screens without code, only providing the logic for the business part of the application.  In fact, our team was one of the very earliest users of this technology.  Also, the Internet was just developing, so there were early attempts as to how to use it effectively.
• User Resistance – The systems being replaced were 20-25 years old.  The librarian users were vey serious: “Three contractors had preceded you and promised change.  They left without any difference.  And you will, too.”  In addition, we were talking about moving from “green screen” with a very strict menu interface, to a graphics user interface with much more flexibility.   Because the user had no basis on how to recommend doing things, with this new approach, we needed to be able to help them imagine the change.
• Development Team Resistance – Developers are like everyone else.  Much of their job is part of their identity.  They can be very smart, but they can be just as resistant to change.  In this case, many of the developers saw the move from the massive mainframes to desktop equivalents of clients and servers as a major step down.  And though they were picking up the technology, they could not bring themselves to work on these “lesser” machines.  There was also a concern that by removing the redundant coding used to place items on the screen, there would not be enough of work for the team.  In actual fact, the coding for placing objects on the screen would have been a distraction from the focus needed on building the business logic.  And, unfortunately, we were very strained for resources to complete the development on time.   Actually, the use of Delphi, with its reduced coding requirements was what was needed to meet the deadlines.

This project was highly successful for the following reasons:

Governance/ Culture – The agency’s program management was committed to the modernization.  There was a defined need in their mind that the users have a system that was more responsive to their needs.  This alone provided incentives from everyone else to try to develop an effective approach.  Because of the directive from the agency’s program management, the librarian users, also contractors, would listen to the IT designers on approaching the problems.  Ans while there were developers that had a problem seeing themselves in a new environment, others saw the new platforms as an opportunity to participate in the new technology and upgrade their skills.  According to Malcolm Gladwell, once the Innovators, Early Adopters and Early Majority exceed 20%, Change has reached its tipping point.  At the same time, we did see about a third of the development staff quit because of the problem of not seeing themselves in the new environment.

Processes – To some degree, we were lucky that funding was a bit slow.  That meant we could spend more time preparing the organization.  It is difficult to obtain input from the user when the user does not understand the new protocol of the environment.  Designers and developers have a problem when they do not understand the new design approaches.  Each group has a tendency to move back to their comfort zone.  The result would be the new environment looking like the old environment in how it responds.  Extensive time was spent on both groups on introducing the new approach.  When you talk about user-centered design, sometimes there is a need for a select few who can see the potential and understand the business so that the results can be converted into an effective, efficient design.  But be prepared to accommodate  issues and prepare to make changes as the process develops.

Feedback/ Reporting (Metrics) – A Roadmap had been established for developing and moving into the new environment.  Again, because of funding, this would be a three or four year project.  We did use the waterfall approach (Agile was not really developed back then).  On the other hand, a focus was made on restricting people to a limited number of objectives so “something got done”.  While an overall design had been put together, since this was new technology, a lot of detailed design was accomplished just in time.  Objectives were tracked on at least a weekly basis, and in some cases daily.  Annual plans were updated during the Christmas/ New Years period, where they were realigned, if necessary.  Because of the continual unexpected challenges (new technology) weekly plans were dynamic to compensate for unexpected surprises.  Regular discussions were held as to how to improve the process.

Management – Communication, communication, communication.   Flexibility, flexibility, flexibility.  New environments are going to be challenging.  And there is not always the ability to lengthen to schedule.  If one thing is delayed, look for another to take its place.  Communicate throughout the organization when something needs to deviate, why it was necessary and how you are meeting the challenge.  If issues are repeating, identify them and their resolution.

Planning –   Continuity of service.  Training, not just for the final system but in preparation for the development.  Disaster/ recovery.    We knew what we wanted to accomplish.   A plan was set up with very specific goals.  And we paid attention to the risks, daily.  Plans were dynamic, to compensate for the constant change as it occurred.

This project was very successful!!!  As we were moving off the contract, the person who had said we would never make a change told me that if they try to take the new systems away, they would quit.  That is probably the best way to measure success.

(Image by Pete Linforth from Pixabay)