The biggest problem Nathan has is that there isn’t much teamwork in his organization. The projects in this group are small enough that most developers have their own independent projects. They don't get much of a chance to talk together, and so they don’t share code or ideas. The last straw happened recently when he discovered two different developers working on basically the same set of subroutines -- while their projects were independent, they accessed the same database.
The Soft Toolbox is comprised of two integrated systems. The first is simply a storage platform for all the tools that Nathan's group has developed. The second is a work request system that allows Nathan to prioritize and manage the work.
The storage platform is very simple. Nathan started with a standard Notes discussion database, and modified the Main Topic form to a Toolbox Item. First, he added several fields. The Developers field is a list of the names of the people who built a tool; they can be approached if more information is needed. Platform describes the operating environment for the tool, such as DOS, Windows, or Notes. The Keywords field is a multi-valued keyword field that's used to help people to locate this tool, and Abstract includes a brief description of the tool’s purpose.
Someone filling out a Toolbox Item form includes the fields above, and types the title of the tool on the subject line. The body of the form contains the tool documentation (either directly posted into Notes or attached as a document), and also contains the attached executable file for the tool itself.
There are several Toolbox views, by Platform, by Keyword, by Author, and by Subject. This range of views makes it easy for people to find tools in a variety of ways.
Nathan hoped that posting their tool group’s output would help people to visualize the kind of work that they do, as well as providing a repository that would allow anyone to retrieve an existing tool without having to hunt down the original author. He left the standard Response and Response to Response forms in place, in case people wanted to comment on the database or the tools in it. He has also encouraged people who develop their own tools, such as editor macros, to add them to the Toolbox as well.
Of course, many people will look in this database and fail to find a tool that meets their needs. They needed to have a way to request that a tool be developed, so Nathan also created a Tool Request Form.
This form has a subject, a date, and the identification of the platform for which the tool is being requested. There are two date fields -- Date Required and Date Desired. Nathan originally only had the former, but found that people would err too much on the side of caution and specify a date earlier than they really needed. With both dates to fill out, they are more honest about their real needs (although he jokes that he ought to just set both fields to "yesterday" and leave it at that).
There is also a Priority field, with values of "Low - it would make life easier if we had this", "High - we need this, but we would somehow get by if we didn’t have it", and "Urgent - we have no alternatives to this". Nathan found that putting the extended descriptions in the field made people more honest about choosing a priority.
The description field starts out as blank, but there were different questions to be asked depending on the type of request being built, so the form has buttons labeled Utility Request, Notes Application Request, and Library Request. These buttons insert appropriate questions into the description field.
Finally, the form asks for the name, phone number, and email address of the user so that the tools group can get more information if needed.
Once the form has been filled out and stored in the database, there is a section that can be only edited by the Tools group. It contains a Status field with values of New, Needs Information, Pending, In Development, Not Accepted, and Completed. There is a Projected Completion date field, and the name of the developer to which the project has been assigned.
After seeing a request, the tools group evaluates it and sets the status field appropriately. This will often initiate a discussion in the database between the person or team making the request and the tools group. The standard Response and Response to Response forms facilitate the discussion of the requests right in the database. Occasionally representatives of other groups will chime in and add their own commentary and feature requests to a topic under discussion. By encouraging discussion and improvement, Nathan's group can develop tools that are useful to a wider audience.
The Requests views show all requests by Date, by Platform, by Author, and by Status.
Since the creation of the Soft Toolbox, Nathan's group has run much more smoothly. Their clients can easily find out the status of their pending projects. The publicly posted requests have led to the development of better products, because the ideas and specifications are refined before being committed to code. And the group's visibility within the organization has improved, because the size and quality of the group’s output is now much more obvious.
Application Origin: Modified from the standard Notes discussion database
Application Development Time: 1 day, plus continuous improvement.
Typical Size: 10-50 MB (mostly the file attachments)
Typical Use: Customers make requests to have software developed. Members of the tools group and the customers themselves discuss the requests on line and come to agreement. The status of the development effort is tracked in the database, and the resulting software is posted in the database for public use. The software posted includes software developed within the organization, macros, and custom tools.
Forms: Toolbox Item for storage of software, Tool Request for requesting the development, Response and Response to Response for ongoing discussion.
Views: Toolbox views show the Toolbox Item forms; there are views sorted by Platform, by Keyword, by Author, and by Subject. The Request views show the Tool Request forms, by Platform, by Status, by Author, and by Subject.
Purpose: Management of work requests for a software service organization, and distribution of the resulting products.
A chapter from The Lotus Notes Idea Book,
by Jeff Kovel, Kent Quirk, and Jay Gabin.
Published by Addison-Wesley Publishing Company
ISBN 0-201-40787-6.
This page maintained by Kent Quirk.