1992 – 1997: Technical Team Leader

I worked for a project funded by the Ministry of Education of Israel with a mandate to review and approve educational software products for use in K12 schools.

I was hired to work on a technical QA process that would complement the academic review process that was already in place. I was required to both shape and execute the technical review process. Over time the scope of work grew and required a small team. I was responsible for hiring, training, and managing the team.

I also provided PC technical support and system administration services to the project. There were typical office PCs and an additional computer lab where teachers came in to conduct pedagogic reviews of the software products. This meant a constant cycle of installation and cleaning up of PCs. This too grew and became a team effort.

I was also asked to take on a systems analysis project and work with an external provider (a DOS application built with a DB app called Magic) an information system for the administrative processes within the project. The relationship with the external provider did not yield good results. I started experimenting with building an alternative system based on Windows and MS-Access (which at the time were new, unproven, and sometimes challenging to use in Hebrew). Over time, that became the primary information system.

Design Challenges

As the MS-Access based system unfolded it gradually met and answered strategic challenges.

Process Implementation and Auditing

Each software package that was submitted for review went through a set process that included first a technical review followed by an academic review. Each review yielded a report of issues that needed to be addressed. Each report led to another version being submitted until the software package was approved (by the project) or aborted (by the maker). The information system was designed to monitor the process for each software and guide office administrators in implementing correct procedures. This included design and integration with a physical filing system.

Bi-Annual Print Catalogue

The project issued twice a year a printed catalog of software products that were authorized for schools to purchase using government funding. Initially, this catalog was created laboriously in a DOS text editor. This proved both technically and procedurally challenging. When it matured, the information system was able to assimilate all the information that was collected in the authorization process and convert it into two huge reports that were generated with a click of a button.

One report was a reference book where each software package was described in detail.

The other report was a book of indexes that allowed searching for software packages based on academic criteria (eg: subject matter, age-groups, languages, etc.)

Later the package of two books was enhanced with a CD (Visual Basic) application that enabled searching the database and creating shopping carts that were used for budget-planning in schools.

Physical Storage Space

As the project grew and more software packages were submitted a physical storage space was encountered. Software packages included digital media (diskettes and CDs) and manuals (and sometimes other educational accessories). They were stored in physical modular drawers. This presented two major problems:

  • Re-organizing the physical drawers (by subject matter) became a constant hassle.
  • Because of the varying dimensions of the physical objects each actual software package (for each software numerous revisions were sumitted) took up much physica empty space in the drawers.

The solution involved a separation of the different kinds of physical materials into dedicated storage spaces: Special modular boxes for diskettes and CDs and dedicated shelves for printed materials. When a (version of a) software product package was received numbered labels were printed for each of the physical elements and they were separated into their specialized storage spaces. The materials were accessed through the information system that would indicate which physical items were needed in the archive to assemble the software package. In this format, the archive required a much smaller physical space and was able to grow indefinitely and efficiently.

Leave a Comment

Your email address will not be published. Required fields are marked *