Enterprise Rock Talk

Institution / client name: Plymouth Rock Assurance Co.
Project name: Enterprise Rock Talk: Intranet for 8 Companies
Date: Summer 2004
Role(s): Interaction Design, Technical Architecture, Programming

The enterprise version of the intranet features 8 different sites that use the same code base and the same content database. Note how both use the same tiles, but the layout and color scheme are different.

I created a configurable version of RockTalk, Plymouth Rock's intranet with the goal of generating more usage. The project was so successful that employees of Plymouth Rock's other subsidiaries began lobbying for their own version. The heads of all the other subsidiaries were asked if they wanted to participate, and all said yes. In addition, each subsidiary company was going to provide a staff member to be primary liaison, and the parent company provided a staff member to coordinate among all of the other liaisons. And so the enterprise version of RockTalk, or eRockTalk, was born.

There were 2 primary goals for eRockTalk: 1) provide the intranet services to all Plymouth Rock staff and 2) help foster community and encourage communication across the enterprise subsidiaries. These goals meant that we would have to expand the technical architecture of the existing configurable RockTalk (both code and database design) to allow for eight subsidiary companies, and we would have to create a business process to allow for the updating of content across all subsidiaries.

Since we had the luxury of one responsible party at each subsidiary to do maintenance, we needed to establish a password protection scheme to allow only appropriate people into the updating or configuration process.

Our first design step was to establish the overall business process, and then let the needs of that process inform the technical design document. One of the simplest ideas for eRockTalk was to allow one person to post a message or announcement to all staff members of all subsidiaries. This simple idea brings forth many other difficult questions: can one message be posted to some of the companies (all Boston companies, eg), and what if one subsidiary doesn't want these messages posted on their site? How is the message taken off the system, and who does that?

The first part of the question meant that we would like to keep all content for all subsidiaries in the same database. The ramifications of the question led us to institute an ownership policy. Each bit of content was "owned" by one subsidiary and could be displayed on any other site. Therefore, each site would maintain status of whether a particular piece of information was "active" or not. We decided (at this point - and changed later) to allow the message creator to send the message to whichever subsidiaries he or she felt appropriate, and we would rely on the judgment of the individual not to send inappropriate messages

However, we did decide that each subsidiary would have its own configuration tool that allowed access only to one subsidiaries data. This was important to both stem accidental data manipulation of a different company's data and helped ensure a clear division line between subsidiaries, allowing one subsidiary access only to its employees, for instance. However, as a practical matter, there were some departments that needed access to all employees. The corporate HR department, for instance, serviced most of the HR needs of the subsidiary companies, and hence needed access to all databases. Forcing the HR staff to constantly log in to one company's configuration system and then log out and log in to another company's configuration system to edit their employee data was out of the question. Therefore, we needed to develop a master configuration tool that allowed access to all companies as well.

Another issue was that each site had to have a different appearance - yet we wanted to maintain use of a single code base and a single data base. Therefore, each site had its own color scheme, but the shape of the graphics was the same. In this way, users of one site would also be more able to use the other company sites.

Finally, Plymouth Rock wanted the ability to pull reports on usage of the system in a simple way. There was a rudimentary hit counter built in to the original configurable RockTalk, but it was not easy to use at all.

After we discussed and thought through all of the requirements, we developed an action plan to build the new system. One of the critical parts of the action plan was to establish a community of intranet updaters. We were using a liaison at each subsidiary company to get us company specific content. These liaisons were also going to become the individuals who would maintain each subsidiary site - these updaters were going to turn into the community.

Each updater would need to be trained in the use of the tools. We scheduled a 3-day meeting to train all the updaters and to begin discussions with each other about using their enterprise wide intranet. The group met each other, learned the system, and developed a standard etiquette among them. This allowed them to take some ownership of the updating process, and drew a line between system development, and day-to-day maintenance operations.

After system deployment, I assisted the team in ramping up their skills as intranet updaters. The system worked beautifully, has been a smashing success among all staff members, and is still in full use and remains fully updated to this day.

Browse list of items from configuration pages. Note the owner company column. This allows multiple companies to share the same database and hence, post announcements cross-enterprise.
Screen to enter / edit data for a homepage image. Note owner company field, which is not editable. Note upload link (next to the image name field) to automatically upload the image file. Note too the check boxes to choose which companies can see the posting,

phone: 617-697-7527 — e-mail: ben@dubrovsky.name — ©2007, 2008, 2009 Ben Dubrovsky