How do engineering product teams stay on top of information a project generates without drowning? What kinds of communication tools help keep the team together on the same page? For answers, Integrated Measurement Systems, Inc. looked to the World Wide Web. Inspired by the Web's agility at providing vast amounts of information to a diverse audience, the Beaverton, OR-based developer of automated test systems for integrated circuit device verification created its own intranet, a mini-Web for tracking and organizing project data. In the process, it developed a highly adaptable tool for knitting together project teams and providing quickly-accessible data to everyone in the organization.
A multimedia hyperlinked database girdling the globe, the World Wide Web offers users a combination of text, graphics, and other media forms. It serves as part of the internet, that vast network of computer networks that allows any computer to communicate with any other. An intranet behaves much like a Web-site, except it is proprietary, restricted to a specific group of users. A typical intranet combines newsgroups, various home pages (the Web's essential building blocks), and mailing lists, allowing for easy access to many types of information, from documentation to drawings, status reports and task updates. Because intranets restrict access, users may share information freely.
IMS moved away from this approach through project-oriented electronic bulletin boards, or newsgroups, to which any project member could subscribe or post information. Says Batson: "We created tools to cross-post email messages to newsgroups, because some folks don't like lots of e-mail and preferred to catch up later on their own. The newsgroups were also archived for later access." He comments that this approach didn't necessarily provide universal access and depended on a variety of ideas about useful items to post. It did, however, start minds thinking about other solutions.
When IMS launched development of a second-generation product, says Batson, it was time to consider more radical ways of dealing with information issues across the product team. This consideration mattered considerably in a team (collocated but divided into smaller project teams) that grew from six designers in the design phase to a full complement of 40, spread out across some 6000 defined project tasks.
Batson says the decision to set up the internal Web site was a grass-roots effort initially championed by a few team members. The project team recognized its communication problems and sought ways to solve them that would adapt as much as possible to the variety of communication styles across the team. Many of the engineers on the team were familiar with the Web's advantages and thus saw the potential for crossover application.
Says Batson, "I chose to apply the technology to project management."
Initially, Eric Martinson, a senior engineer with the technical interest, set up the internal Web site, creating the original internal home page and the tools to enable others to use it. Martinson became the company's de facto Webmaster, while continuing with his regularly assigned projects. He maintained the site and trained others in its use until new champions emerged to help direct its development. For his efforts at keeping the systems alive, IMS rewards Martinson with additional compensation. Nonetheless, says Batson, "we maintain the site via distributed responsibility. I ask everyone on my team to contribute and to keep the information current. We also invested in the tools to automate that process."
While the intranet became the primary tool for posting information, Batson says it was not the entire solution to the team's communication problem. They continued to use e-mail, and project teams exchanged information face-to-face. From the start, not everyone was Web-literate or enthusiastic about using a home page to store and organize data. Batson reports the main resistance came from asking people to contribute: "Until there was a critical mass of information, some saw this as yet another place to look for something. I met the resistance by exploiting the tools to facilitate publishing. There is still some resistance--this is an evolutionary process that we haven't completed."
Like most project teams, Batson reports that the IMS group produced considerable documentation: a necessity but, without an easy way to organize and access it, potentially burdensome. Batson notes that the internal Web site reduces the burden of documentation in at least two ways" "First, we know where to go to find out what's current and available. Paper and e-mail get stale. Second, it allows a wide variety of people to access the information easily in their favorite way. Remember, we cross-post to newsgroups and e-mail. And some people still like printed versions, which they can produce with their favorite browser."
Project management documents on the IMS intranet fall into four categories: product-related (goals, systems specs, customer-oriented data-sheets, and feature set descriptions); project-related (plans, budgets, schedules, task lists, deliverables and status reports); technical/hardware (such as block diagrams and designs); and technical/software (white papers, interface references, release notes, requirements and analysis).
In addition, PERL ("practical extraction and report language") is a programming language that provides strong support for text files, enabling pattern matching and regular expression matching. PERL facilitates automatic publishing of a wide variety of pre-existing product and project information. Finally, the IMS team members were also able to use ASCII text files, enabling them to input information from inside their directories, their files, and their heads onto the Web site. This was especially important for people who might not yet be Web-literate, since ASCII text is a format familiar across the team.
A "project home page" provides on-line documentation accessible from one location. The home page included data on progress and plans, status reports, interfaces to project data and various documentation links, all formatted in a table of contents. A back-up system provides protection against failure. Batson says the IMS information systems function steps in to bring hardware back on line and restore files, if and when necessary; the engineering organization supports the software itself.
The project team met weekly in roundtable fashion to update everyone on the status of team tasks. By the morning of the meeting, team members input their status reports. Automated scripts processed the data, dissecting individual reports and combining them with information from other documentation. (As to the automated scripts, says Batson: "I've written many myself. We hired a summer intern to add some more. Our design process is somewhat free-form, doing whatever it takes to get the job done." ) The status reports became available the same morning, prior to the team meeting.
The team organized status reports according to tasks accomplished and progress made, upcoming tasks, issues and obstacles, discovered tasks and critical path status, milestones, technical discussion pending, and non-scheduled interruptions. The system's formatting facilitated easy organization and cross-referencing. Batson says this process got the team involved in thinking through status issues.
Immediately following the weekly meeting, team members updated their reports; Batson managed and maintained the overall format, adding meeting notes. Updated information appeared on the Web-site the same day, as well as via e-mail. E-mail's primary advantages here were providing abbreviated versions of the reports and making the information easily available to people who were slower in warming up to Web-site use. Batson says this process expanded individual involvement significantly.
One problem that surfaced: over-long or over-detailed reports. In addition, the system relied on timeliness of updates and follow-through. Batson resorted to e-mail reminders when anyone fell behind; on the other hand, the common desire to share information served as an inducement to contribute.
At its peak, the overall project included four project teams working in parallel. Project team managers collaborated on developing the milestones tracking system, using the same formatting as for other documentation on the web site. Managers defined milestones clearly in order to be consistent about what they were tracking, and identified individual milestone-states for each task: neutral (not yet started), started, completed, behind, delayed, and removed. The team used a monthly yardstick for tracking milestones, standard for certain projects at IMS, monitoring them on a weekly basis.
Using the intranet to track milestones, says Batson, made project tasks easily visible and served as a graphic way to chart progress to the entire team. On the other hand, updating required more manual effort than the team liked, spurring project managers to look for improvements: "We want to put the update mechanisms in place so that the team creates and maintains its own milestones. Today, I still edit the files myself. We need to learn how to look more proactively at future milestones, and be less focused on the present month. In addition, we're discussing augmenting the system to track project metrics, to gather data about performance objectives and compensation."
Batson lists other examples of the home page's usefulness to the project team: its ease in tracking design issues, implementation phasing, software documentation, and QA documentation, including bug reporting data. He anticipates future intranet improvements, including better ways to link information and application of new programming tools like Java, and notes the importance of seeing the Web-site as an evolving opportunity, where constant change in communication is possible and desirable (quite relevant in view of a team's differing affinities for Web-site use): "People saw the Web as a way to communicate with the world. Now they see it as a way to communicate across the company, across their project team." With this comes appreciation for how to bring the information-rich advantages of the Web in-house for product development.
"The team has two goals for the intranet. The first is keeping up-to-date information available to everyone on the team. An extremely critical piece of the process requires that everyone have access to information, and that the information be up-to-date. Secondly, it's necessary to keep the team involved. Keeping the whole team involved is the most important concept behind web usage--how to invigorate everyone's contribution to the project. We think the Web is the natural place to do that."
"As a project manager, a significant portion of my time involved communicating with people and dealing with day-to-day information that needs to be transferred around the team. At the same time, it's a significant proportion of everyone's work on the team to meet the challenge of how they are going to communicate what they are working on and the progress they're making."
Brian Batson, Integrated Measurement Systems
For more information, call Brian Batson at 503-636-7862; e-mail: bbatson@teleport.com.