Intuitively Created Structures - How Users Are Working

People like to structure their knowledge. At least those people who like to communicate. Structuring knowledge is part of communication. Finding the right words, building abstractions, grouping information together, supporting certain perspectives by structuring the information in a way it is assumed can be received well by the audience. Already the act of "serializing" thoughts and concepts into the stream of words can be considered as applying a structure to knowledge.

Let's pick a typical group of today's knowledge workers: project managers. Managing projects means mainly to work on the structure of information. Especially, project managers are busy with translating one structure into another. The upper management needs more abstract information, the team members need more detailed information. The customer needs different descriptions than the production people. The following example maybe comes somehow simpified, but it should show the point.

So, let's see how project managers are working on structuring knowledge. E.g. what tool(s) are they using? The answer is easily found: mainly Microsoft Excel (sorry for the competion, it's really this Microsoft thing, and only rarely similar products of other vendors). More and more popular becomes Mindjet's Mind Manager. (btw.: these are not statistically proven statements, but impressions from working inside different companies with lots of project managing colleagues). For now we focus on MS Excel, and to be more neutral, we say "spreadsheet application".

Tools like requirements management software, special project management tools etc. are used, but often not liberately and typically accompanied with many complaints. Dispite all efforts from the project management office within the companies, project managers
prefere to work with tools they control by their own. Especially, they prefere tools that allow them to structure the information in they way they just are looking for in the moment. There is no time to sit back and think carefully about the structure of the information and how it can be applied within the specialized tool - even if the creators of these tools invested a lot of effort and many good ideas, so the knowledge would be structured "much better" than in a spreadsheet application. "Better" in terms of clarity and reuse within the company. "Better" also in terms of being conform with some processes. Dispite this "strong" motivations, project managers still simply use these spreadsheets.

So, what exactly happens, when the project manager decides to create another Excel sheet? First, there is a list of information, let's say a list of product features the project manager likes to discuss with the customer in the next meeting. It's easy to fill a speadsheet with this list. Next, the project manager want's to indicate when the prouct feature would be available. He or she adds a second column, entering dates, or milestones. Next it becomes clear that not all features are equally important to the customer. A third column is added, with priorities. A,B,C or 1,2,3,4 or something like this. Quickly, there is a lot of data, and getting an overview becomes difficult. How many top priority features the production manager promissed to deliver for the upcoming milestone? ok, add some colors: each top priority feature promised to be delivered for the next milestone gets a green background. Looks nice. But the customer will focus on those top priority features NOT being promised for the next milestone. So, these will be marked with red background. What will our project manager tell the customer? E.g.: the production manager promissed some of these features for the milestone after the next one. They get marked yellow instead of red.

Quite nice and colorful. The project manager sees at one look where they stand: it will be difficult to convince the customer that they get what they want when they want to get it. Too much yellow. But the project is actually running quite well, and so much better than it would look like to the customer. The information needs to be translated, or the structure needs to be adjusted to the customer's point of view, so they get the same impression the project manager has: well running project. And the customers point of view is: if everything is ready for the third milestone, they are happy.

So, restructuring the information: each milestone gets a separate column. The milestone columns show green if the feature is promissed to be ready for this milestone. The field in the first milestone column becomes yellow if the top priority feature is not planned to be ready for this milestone. The field in the second column becomes red, if the top priority feature is even not planned to be ready at this milestone. Medium priority features get green in this second column if they are planned to be ready, otherwise yellow. Etc. for the 3rd column / milestone.

Now, the spreadsheet looks nice, even from the customer's point of view. There is yellow and even read, but embedded within a green looking area - indicating that the project is quite well from an overall point of view, and there are some issues to talk about. This is what the meeting will be about. The project manager has what he or she needed.

Now, someone from the project management office found this result very convincing, too. Good work - this should become a company standard. And since this spreadsheet is about a feature list, and there is already a feature list in the planning software the production team is using, it would be much more efficient to extend the planning software so it can present the information entered by the production team immediately as the project manager needs it. Everybody should be happy with this, and more productive. Let's invest in some software development. First step: let's analyse what is exactly needed.