From: John Conover <john@email.johncon.com>
Subject: Re: IT uses
Date: Tue, 24 Aug 1993 00:50:45 -0700 (PDT)
John Conover writes: > Allow me continue with an application of IT, specifically to > program/project management, ie., a "how to" application. This will > make use of the email system to hold asynchronous group conferences, > and the archive/retrieval system to document the activities of the > individuals in the group (or team, if you prefer.) ... > Continuing on with the application of IT, I will present an example usage scenario in the day to day operation of the IT system outlined above. To reiterate the way things are setup, all members of the group (or team) have a mail alias set up in their project account that includes their self, all other members of the group, and the group's project archive. (It would be appropriate to think of this as an ongoing electronic conference.) As things are discussed, decided, scheduled, and finished, an email concerning any and all issues of the activity will be distributed to all members of the group, and the archive. (Don't forget that these electronic correspondences constitute a "documented social commitment," on the part of the individuals of the group, to the group, itself.) It would be appropriate to think of the archive as a "library," where you do electronic "literature searches" in the conference digests, for various subjects concerning the project. Take for example, project scheduling and tracking. The group chairman (ie., project leader, team leader, group administrator, or whoever has been assigned to be in charge of scheduling,) issues an email, periodically (say, every Friday,) with a "Subject: Project Status Milestones," (or whatever else) to all members of the group. As all members of the group reply about the week's progress, (simply by pressing the 'r' key in the standard Unix mail system, and typing the response) the person in charge of the scheduling system can update the master project status (either by a "cutting and pasting" the sections out of the returned project status reports into a formal paper report, or automatically updating the schedule database, if a "forms" manager was used to compose the project status request.) There is nothing too different from classical management techniques, so far. It is very similar to an automated MBO system, and fits in nicely with other project analysis/tracking methodologies (ie., like Pert Charts, Gant Charts, Critical Path, etc.) Its only advantage, so far, is that it is efficient-quick and requires minimal time/overhead from the group's members. The system differs slightly in that the original requests and responses concerning project status are archived in a manner that they can be retrieved, electronically, within a "context framework," in an expedient fashion (perhaps by upper management, or the managers of other related cross-functional departments who have a vested interest in the status of the project.) By this I mean that since all of the project status reports are available on demand, (and can be collated by a search of something like "Subject: project status something,") the history of the project status from any previous date to the current date can be put into "context" or "perspective," (by simply reading the reports that were retrieved by the "context search.") This is the part of the system that upper management would use to evaluate the "state of affairs" in the project. (If the upper level managers are "information junkies," the machines can be programmed to issue the "context search" command, automatically, every night, so that the managers know the exact status of every project, to the day-every morning.) What this really enables the managers to do is "precision management" (a Texas Instruments'ism.) Again, this is not too much different than using traditional management tools (just significantly faster,) but note that this is not a traditional bureaucratic process-in a traditional bureaucracy, the various organizations that had a vested interest in the project would be "re'd" with memos (usually on a monthly basis) of status reports (which are written in the context of the project managers,) and spend time attending staff meetings (to get a "better" perspective on the project.) However, in this system, if other managers have a vested interest, they have to retrieve the information from the archive their selves (and thus draw their own conclusions.) It is probably a key point that the nature of the bureaucracy has now been changed. It would be appropriate to think of the electronic bureaucracy as one that a manager has the option of subscribing/un-subscribing to (dynamically) on what is considered an appropriate basis. And if a manager's attention has been focused elsewhere, the progress (or lack of) made in the interim can be retrieved at any convenient time. Note that the objectives are not to replace paper memos, or meetings. These are still important instruments in the group's dynamics. The objective is to offer a better means of information/knowledge dissemination through the organization (both to and from the project group,) so that meetings, etc. can be "quality time," as opposed to wading through reams of "show and tell" project status reports. Additionally, and this is another key point, if an issue comes up in the project schedules, (slippage, etc.) a manager can formulate another "context search" for an additional retrieval, that addresses the specific issues in question from the project status reports. Note that if the use of the system is enforced, then there is no excuse for project "execution failures," too many people would have knowledge of the "program exceptions," and too many people would be documented of having the knowledge. (The project may fail for other reasons, but execution is not one of them-unless the managers are sloppy, and not "watching the store," in which case their managers can formulate appropriate "context searches" to check up how well the project is being managed, and so on up the corporate hierarchy.) The important, key point, is that everyone in the project's chain of command is subject to accountability and scrutiny of the decisions they make. As a side bar, note that it is not the objective to scrutinize a decision itself, but how the decision was arrived at (and, hopefully, all of that information is documented in the archive.) Was a decision made with integrity? What was the "quality" of the decision? Were all pertinent issues and interests addressed prior to making the decision? Note that an external, and presumably unbiased (ie., without parochial interests,) source could retrieve this information from the archive (or have it retrieved for them) and form an opinion on the appropriateness of the decisions, and decision making process (with or without the knowledge of the people involved in the project.) This is the traditional realm of OD or TQM organizations (who, presumably, would monitor such things, "real-time," and keep upper management appraised of effectiveness of the project's management-these organizations have no responsibility or authority in what was decided, but only in the way that it was decided.) Note that this, potentially, presents a means of enforcing the use of the system-the system would be used as a significant source of information-by, perhaps, a disinterested party-in the determination of promotions, bonuses, etc. and fits in nice with the current concepts of "quality management." It is an important, key point, that the system fits in nicely with the more contemporary management schemas. As the decision making process is pushed down into a modern, flat organizational structure (ie., "empowerment" is a fashionable term and "down sized" is the reality,) this type of system is probably the only way that management can "stay in touch" with the decision making process. It is also probably the only way that management can exercise any sort of policy influence over the way the organization makes its decisions (which will be well below upper management, hopefully.) As a conclusion to this side bar, observe who is the audience of the author(s) of the "library" (think about it, it is the other team members and program monitors) which could conceivably evolve into a, largely, self directed management structure-ie., an organization that does the most, with the least, the quickest. (The keyword here is agility.) Probably the system's greatest benefit can be realized when the group (or team) consists of cross-functional personnel. Here, as an example, Marketing would be responsible for doing media searches for pertinent data and opinions (and placing it in the project archive where it would be available on demand to everyone with a vested interest in the project.) Ditto for Sales, who would be responsible for making sure that interests of the customer base was represented in the group's decision making process. And so on for the other functions represented. Note that the document that defines the various responsibilities of the functions should also be in the archive (because someone may want to retrieve that piece of information, someday.) The objective of the system is to integrate all of the cross-functional issues in a concurrent fashion. There are no excuse for engineering designing something that manufacturing can't make and marketing can't market because sales can't sell it, because the customer doesn't want it, or understand it. Note that at this point, each of the cross-functional organizations must go "on record" as committing to "this is what we want to do," (ie., an agenda has been determined.) (This commitment is something that upper level management will be monitoring the system for as a necessary prerequisite for project sponsorship. They will probably have to intervene, in the interest of expediency, to circumvent the forestalling of the functional organization's parochial interests.) At this point, we have an agenda, a buy-in from the functional organizations, and a sponsor, and it is all documented and subject to retrieval at a moments notice-which will be of use in the project's execution phase when directions become de-focused and the functional organizations renege on their commitments. (Like it or not, the reality is that these two things happen all too frequently-I have never been involved in a project where these two things did not happen, to a more or lesser extent-sometimes with disastrous consequences.) I used the example above of schedule/milestone tracking, and how it relates to the social infrastructure of the organization, and how it can be monitored in an electronic "bureaucracy." By no means do I imply that this is the only organizational process that needs to be monitored in the archive. Another of the advantages of the proposed system is to be able to relate organizational processes. For example, resource "burn rate" should be monitored (time cards should be electronic, also-which are an email into the archive containing the number of hours spent, during the day, on a certain task.) Now the "context frame" can be changed to include milestone progress, AND the cost of development to obtain the milestone. And so on. -- John Conover, john@email.johncon.com, http://www.johncon.com/