A main goal at work is to gather all the organization's information into one meta database for people to access in a variety of ways. This metadatabase will not necessarily hold data itself, but will be a map to where the data lives. To that end I'm working on learning C sharp and figuring ways to apply rolled out applications, such as Goldmine to needed purposes.
In seeking the One Database, we hope to make peoples' jobs easier and their effforts more effective. But the OD will not replace one aspect of the job: talking to people. Often the best source of information-sharing is the oldest, namely, having a conversation. And I've noticed that in decentralized organizations like mine, conversations are particularly crucial to good work results. They form the connections between different units and tend to identify conflicts, solutions and relative importance of issues.
To foster this, I've been making an effort to leave my warren/office and walk through various parts of the office to talk to colleagues. The results are mixed thus far. But I have identified one person I consistently miss in my perambulations around the office, probably the one I should talk to the most. Since we do not cross paths accidently, I've proposed a meeting to clarify work flow. The meeting seemed like the quickest way to organize work in a useful and smooth fashion.
Which brings me to the issue of figuring out workflow in a think-tank office. It must have some commonality with an assembly line for certain products such as reports and conferences. That is, certain steps must be complete before other ones take place or the final item assembled. For example, the organization applies for a grant to research and write a report. Somebody (somebodies) do the research, perhaps convening a conference or running a demonstration, compile data, develop conclusions, and pull this into a report. The report then must be edited, formatted, published and disseminated. I'll bet we haven't mapped out the generic steps needed to complete the current list of projects from an organizational perspective. A simple flow chart of the steps might illuminate some of our actual strengths, constraints, and potential places for improvement. And by having an organizational view, not a project-level view, we just might see where project incentives do not coincide with organizational incentives.
Posted at July 23, 2003 09:32 AM | TrackBackThis discussion has been closed. No more comments may be added.