Using a collaborative software in a multiprofessional IT development project

Like

Summary

In the following, the use of Knowledge Practice Enviroment (KPE) to support multiprofessional IT development project is demonstrated.

The project took place in a Company, which is a globally operating consulting and engineering firm. The project at stake addresses the business market’s general central challenge at the time: according to radically globalizing, distributed work (design engineering), the aim is to identify the problems of and to create new solutions for the present ICT and the networked working practices.

The project lasted approximately for three months. The work was organized in everyday domain specific subgroup workings and in weekly project F2F meetings. KPE was used to coordinate and share the knowledge about subgroups’ work, and to support the construction and flow of knowledge across the subgroups. In F2F meetings, KPE was shared at video screen and linked to remote offices. In the end of the project, KPE included the knowledge to explicating different subgroups’ work and the work that linked different subgroups. Each subgroup had its own Task and the corresponding material in KPE-space. KPE wiki’s were the main tools to work with, and other KPE items were linked to tasks and wikis’.

Context

Where?

 

View Larger Map

 

Who?

The project setting is multiprofessional; approximately 15 participants represented the users of project tools (engineers from different expertise fields), project managers (representing the project coordination level), higher management participants (representing the Company’s strategic roadmap) and the third party ICT development company.

Learning Objectives

• The overall objective of the project was to come out with new suggestions and solutions for combining the existing communication and design tools of the engineering company, with new potential IT tools. This required exploring the existing problems with the tools and working practices, and figuring out collaboratively the new practices with new combination of IT tools.
• The objective of using KPE was to find out a new way to coordinate the knowledge flow between the expertise groups taking part to the project.  Firstly, to gain insight how to organize the overall activity between individual and group expertise work and project meetings, and combine the added values of F2F interaction with virtual work. Secondly, the objective was to learn new way of virtually documenting and commenting the workings in KPE by crossing the expertise boundaries.

Activities

The project lasted approximately for three months, during which thirteen project meetings took place. The work between the 15 core members of the project consisted of everyday domain specific subgroup work and in weekly, face-to-face project meetings. In each meeting, the work from each subgroup was presented, discussed and documented to KPE. The aim of this practice was to communicate the work throughout the different subgroups in order to reveal that problems, overlappings and missing information inside and between the groups.

Here a broad illustration of the project organization: different activity modes (meetings, individual work, and group work) and how the ten subgroups each had their wiki in the same KPE (content) view to communicate and interrelate the work.

 

 

Tools

The KPE structure with group-specific tasks and the use of KPE tools was planned to support the project aims. The Main user phrased this highly important intention:

The weekly meetings are the place to see what is going on for participants who represent different things. The meetings and the whole project are to ensure that no particular solution [of a particular group] prevents some other [group’s] solutions.

Nine subgroups and the project management had their own tasks, describing their work area, such as IT structure, Collaboration tools, Document management tools, 3D-tools, etc. After a careful planning and trying out the possibilities with KPE tools, it was decided to that each subgroup has its own wiki-page, where the work is communicated to others, and where others can comment and link other knowledge. All the tasks and the related wikis were on one KPE-space, as represented in Figure 2. The light blue icons are the tasks of ten groups and the dark grey main wiki-pages are linked to tasks. Other material and wiki-pages are linked together. The structure supported to keep the organization of the workings manageable. By this manner, the amount of items was rather low.

The main activity in KPE took place through group-specific wiki pages. The material during the project accumulated with thirteen face-to-face meetings. The wiki structure was similar to all groups, which was supposed to help searching and commenting across the groups. The structure was planned by the main user together with project manager and one project member.  The use of wiki followed the requirement of having a tool including the versioning. The subgroups put their materials (report of work activities, status, and plans) to their own wiki’s before the meetings. The meeting memos were also organized inside wikis. The idea also was that wikis serve as tools for the groups to have access to see and comment other groups’ work.
The other KPE tools used were uploadable content items (any digital material), KPE notes and comments that were attached to tasks and content items. Figure 3 shows how the ‘Collaboration tools’ subgroup  had two wikis, had imported four documents (manuals and implementation requirements) and posted four comments to documents. In this project, the use of uploadable content items and comment-tool was not extensive, because they took place inside wikis.

Quotes

Why was KPE implemented to the project?

“What I described about the requirement of working visibly with the tasks of multiple groups, I now see that can be put to KPE. To have an open KPE-environment for development. I try to get together the IT and application people to sit around one table, because if they start to work separately, it does not work. The project would not hold in one piece. KPE seems good, because in this kind of open process where the outcome cannot be defined, it is interesting to see how the different ideas go by different paths. This is the project where we approximately know where we want to go, but we don’t know how we go there.”

 

How did KPE help to manage the flow of complex project information?

 

“It seems that having one space for all groups the use of wikis for both reporting and planning, and keeping memos has been good. Now the reporting and planning and the memos are in one document, which show all the material and the history.”

 

“We have the weekly workings of different tasks put to KPE. In this way we could see the dependencies between the tasks. The material stays in one place. Normally I manage this in my own laptop and powerpoints and the problem is that they may get scattered and hard to handle.”

 

“Many times (in previous projects) there is no documentation of the overall activities at all. The things have been just made. For example, this line (pointing to wiki) tells the implementation of electrical design tool has been done. That is reported here in KPE, and maybe not in any other place. And if it has been documented that information has reached only a few designers inside their own department.”

Recommendations

• One important element of trialogical activity was concretized by the activities of moving from dialogical (discursive) mode to trialogical practices (knowledge objects mediating and supporting the collaboration) by using the knowledge objects to materialize and develop the work. Typically in project work the activities are to large extend discussed to other members, but the talk gets forgotten and easily unconnected to other activities. In this project KPE was used to share and develop objects that concerned the coordinating representations of work:  visions and problems, which where materialized as plans-reports-memos. All these elements were combined inside group specific knowledge objects (mainly wikis).

 

• Typically in the projects of this large scale (several discipline areas, geographically distributed offices), the work is distributed to experts who work separately, with the responsibility of the project manager to keep the project in one piece. Different disciplines work on different rhythms, use different knowledge tools, and even aim for different outcomes. The meaningful setting and KPE tools can support the project to become better aware and to learn across the expertise areas. As evaluated by project members, they managed to make visible the work they had done or planned to do, in order to learn from each other’s work. By using the KPE to communicate the workings across disciplines eventually helped the overall project to coordinated the activity and to reach its aims.

• When planning the learning activities, the specific needs of the learning activity and the process have to be explicated to participants. Some supportive questions help to understand and organize the activity: who and why should participants collaborate?, what should the collaboration be like, what tool(s) to use?, what kind of knowledge artefacts should be developed?, etc.  Evaluation of the abilities of the participants for collaborative activities and particularly for trialogical activities is important when planning and implementing the activities. As shown in this study the skills and motivation vary between individual, groups, organizations; an activity that is easy to implement to one might be out of reach for another.

 

• Plan the structure of and use of tools to follow the economy of lower amount of items. When the amount of knowledge objects rises, the risk of managing the knowledge and particularly collaborative actions also increases.

 

• Training of the tools should not be only technical, but conducted in accordance with project aims and materials. This means that the pedagogical frame should be first planned and visible in training setting and that the real project material could be used already during the training. In this sense the technical, pedagogical and material elements combine already from the training period. As its best, this enhances motivation and commitment.

 

• Reflection of both the epistemic and pragmatic elements should be made visible. Oftentimes the evaluation and reflection concern only the epistemic outcomes, not the practices. The reflection of practices needs support from a trained project manager, otherwise it is under the risk of a failure. Reflection is a skill that can be developed.

Links

Resources