The Semantic Puzzle» Logica

Knowledge Management for Project Management: from unstructured to structured information

Jana Herwig — Fri, 28 Nov 2008 10:20:25 +0000

KiWi – Knowledge in a Wiki session, pt. 2: This afternoon, we turned to the Logica use case, which is dedicated to the development and optimization of KiWi as a knowledge management tool specifically tailored to the needs of project management.

Regarding the use case requirements: As Daniel Grolin, a process expert and business architect at Logica (formerly WM Data), pointed out, what is most required at the moment is an application for designing processes, i.e. for designing the ways that people do things. This can be a painful process, in particular if one group of people (consisting of process designers) thinks about the ways that another group of people (e.g. the project managers) are going to do certain things – a collaborative approach should be able to

1) alleviate this challenge
2) generate commitment among the involved parties.

The primary users will be on the one hand the process engineers, and on the other hand the project managers who are the recipients and users of these processes.

In his presentation, Daniel Grolin chose one of four scenarios in which KiWi would ideally be employed: the risk analysis process – which is a vital process for Logica, as the outcomes of this analysis influence the decision whether or not a project will be accepted. From an architectural point of view, KiWi is going to mediate between the process guidance column – which consists of process and workflow features – and the final work product, i.e the result of a process, in this case the report of the risk analysis.

In practice this means that if, for instance, a user has selected the risk analysis process, the Kiwi core system and enabling technologies will provide concepts related to risk analysis, supporting the user in the tagging process. Wiki technology is already being used in the industry, said Daniel, but what is lacking at the moment is the integration of structure, and this is also where he sees the potential of KiWi as a knowledge management tool, and as a means to move easily from unstructured to structured information (by the way, if you are interested in using wikis in the enterprise, I also recommend this article: Wikis for Knowledge Engineering, and in Global Businesses).

Karsten Jahn (Aalborg University) then gave us a preview of a possible user interface (i.e. not of the screen design, but the functionalities) which seeks to address one particular problem: Many companies use many different, sophisticated tools which operate fine on their own, but are not integrated (i.e. there is no communication or exchange of data between them). With KiWi, the aim is to develop a tool that is going to be able to cover all features and processes currently being taken care of by individual tools, to allow for an optimum of data integration.

To conclude, Rolf Sint (Salzburg Research) showed us screens of the current configuration of KiWi for Logica’s needs – the example below is related to the risk analysis process outlined by Daniel Grolin above.

Content Versatility in the KiWi Core System

Jana Herwig — Thu, 27 Nov 2008 10:27:37 +0000

It’s been five months since the last Joint Work Package (WP) meeting in the KiWi – Knowledge in a Wiki – project. This morning, we gathered in Vienna for the next round – focus this time around will be on the core system (architecture developed by the WP3 team, handing over and paving the way for WP 4 team) and the use cases (Logica, Sun Microsystems) where it is of particular importance that everyone involved in the project understands the requirements of the use cases.

In the first presentation today, Sebastian Schaffert from Salzburg Research gave us a tour of two different configurations of the KiWi system. The KiWi core system is oriented towards content versatility, meaning that content items can be displayed and used in various contexts and configurations. As a service to the user, KiWi uses Javascript-based WYSIWYG Editor TinyMCE enhanced with a few home-grown plug-ins which, for instance, make it easier to set links to other wiki pages. Memorizing wiki shorthand is sometimes a challenge, so this feature helps getting things done.

Using a different skin and interface, KiWi can take various forms and shapes – even shapes where you might not spot the wiki in it at first glance. TagIT is such an example of an adaptation of the KiWi core system: a geotagging platform targeting youth in Salzburg who can locate, tag and comment on places that matter to them.

Vice versa, KiWi in its wiki incarnation displays a little map, provided a content item is enhanced with geoinformation; technically, the map on the wiki page is an interpretation of a georelated tag (learn more about complex, structured tags proposed by the KiWi Enabling Technologies Work Package in this article: Usage Data Model Day in the KiWi Project).

Take a look at the screenshots below:

It is the same article that is being displayed, in the first example using the classic KiWi interface, in the second example using the TagIT interface with the article appearing as an info page.

This afternoon, we expect to see another configuration of the system, in a presentation about how the system is specifically tailored to the needs of Logica’s “Knowledge Management for Project Management” usecase.

N.B. The system is not yet publicly available, if you have questions, please contact Sebastian Schaffert.

Conceptualizing knowledge with CMMI: the KiWi/Logica usecase

Jana Herwig — Wed, 25 Jun 2008 10:32:46 +0000

Peter Axel Nielsen, a researcher from Aalborg University who is working on the Logica usecase, started his report by giving us an overview of CMMI, a process improvement approach that is being used by Logica and that is thus going to be of eminent importance for the KiWi/Logica usecase.

CMMI stands for Capability Maturity ModelÂ® Integration, and, according to its inventors, “helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.” CMMI was created by the Carnegie Mellon Software Engineering Institute, and has been adopted worldwide.

CMMI provides a framework for a 5-step path towards maturity in software process improvement – a path that can be expected to take years and which demands a company’s full commitment. Peter drew our attention to a volume, fresh from the printing press, which he edited together with Karlheinz Kautz: Software Process & Knowledge. Beyond Conventional Software Process Improvement.*) The volume contains an interesting CMMI case study, “The Road to High Maturity. How the first Danish company reached CMMI level 5 in 100 months,” in which the authors emphasize that software process improvement, in essence, is “an organizational change process, that is, the processes in an organization, and the behaviour and interaction of people, groups, projects and, in fact, the whole organization.” Some of the benefits reported by the participants in the case study were: reduction of overtime, increased satisfaction of employees, increased opportunities to delegate as a result of formal definitions of roles and greater ease to move between projects.

Switching to CMMI brings with it the benefits of a well-defined, ready to use conceptual model of knowledge – this is, of course, an invaluable asset when it comes to defining the requirements of the KiWi system, which is going to be used as a wiki-based, semantically enhanced knowledge management system for IT project management in the Logica usecase.

*) Peter Axel Nielsen, Karlheinz Kautz (eds.): Software Process & Knowledge. Beyond Conventional Software Process Improvement. Software Innovation Publisher. Aalborg. 2008. ISBN 978-87-992586-0-4 See also: website of the symposium on Software Process & Knowledge that preceeded the publication.

KiWi Joint Work Package Meeting in Prague

Jana Herwig — Wed, 25 Jun 2008 09:09:30 +0000

So here we go again, the KiWi and me: Today, tomorrow and Friday I am in Prague with my colleagues Andreas Blumauer and Matthias Samwald, attending the first Joint Workpackage Meeting in the EU-funded project KiWi – Knowledge in a Wiki. The present meeting is hosted by Sun Microsystems - Josef Holy and Inka Havlova gave us a very warm welcome, but thankfully the Sun offices are the direct opposite, namely perfectly chilled on this hot June day:-)

The day started with Sebastian Schaffert, project coordinator from Salzburg Research, giving us an overview of the actitivies of the first quarter in the project and a primer on the objectives of the meeting. The overall concern of this full meeting, in order to align core developments of the project early on, is to develop a common understanding of the functionalities and behaviour of the KiWi system, to define a core data model and to develop an outline for the upcoming dissemination plan.

An IT project is like herding cats, they say – in our case, we’ll be herding kiwis, and if we can enjoy it only half as much as these guys, I’ll be fine:-)

The first session is coming up: Peter Axel Nielsen’s report from Work Package 5, i.e. the usecase developed by Logica and Aalborg University. More updates coming up soon!

KIWI Project Partners, Pt.5: Logica

Jana Herwig — Fri, 14 Mar 2008 11:20:27 +0000

Logica (formerly known as WM-Data) is the second KIWI-business partner, participating in the project management use case. Logica and their knowledge and project management activities were introcued by SÃ¸ren Rieck, one of their consulting architects who has a background in Computer Science (MSc) and nearly 30 years of experience in project management, IT-architecture design and testing (and he is incredibly photogenic, as the picture to the right proves – not one of the many pictures we took of him during the kick-off meeting turned out badly – and he is a dedicated philatelist).
Logica is a global IT and management consultancy company with about 39,000 people operating in 36 countries, 750 thereof in Denmark. The KIWI usecase is going to be conducted with Logica Denmark’s Public and Education Dept., which has 140 employees and typically 20 projects running at a time. 10-20% of project resources are used on project management tasks.
Logica already has a whole array of knowledge and project management instruments and supporting processes in place: Process descriptions and project plan templates are made available in a web-based library; project team members have access to required courses and seminars to address arising needs; audits, assessment metrics and project management tools are provided; further assistance comes from project management experts, the project management office and of course through channels of informal collaboration.
Nonetheless, there are challenges, for instance it may happen that knowledge is not shared systematically – even though one project may have a solution that other projects could benefit from. Furthermore, there are several bottle necks limiting the flow of information, in particular in the phase between the completion of one project and the launch of a new one, when previously defined project management practices might potentially get lost.
So the crucial question is: If all these mentioned instruments are in place, but one is still presented with a situation where there is a lack of balance between knowledge creation and knowledge exploitation â€“ what kind of an improvement and in which areas can be expected from using the wiki model for collaboration and knowledge management? What is wiki anyway : just another technology or a new way of thinking? Karsten Jahn (from Aalborg University who are assigned to this usecase as an academic partner) proposed to consider it a philosophy rather than a technology. In his part of the use case introduction, he reported divergent examples on the one hand of people, even in the industry, who think highly of wikis, but who rarely ever contribute to them, and on the other hand of people who dislike wikis, but who use them intensively.
When one is aiming to implement a project and knowledge management tool, one must also be aware of the different types of knowledge that are involved: In the example of project management, as SÃ¸ren pointed out, it is knowledge that is ‘in the heads of people’ which cannot easily be extracted or transfered. Peter Axel Nielsen from AAU elaborated on this by offering this pattern of four types of knowledge (explanations in parentheses added by myself).