MASTER’S THESIS
2008:164 CIV
Erika Andersson
MASTER OF SCIENCE PROGRAMME Mechanical Engineering
Luleå University of Technology
Department of Applied Physics and Mechanical Engineering Division of Functional Product Development
2008:164 CIV • ISSN: 1402 - 1617 • ISRN: LTU - EX - - 08/164 - - SE
Capturing and managing Design
Rationale for aero engine
'we know more than we can tell'
Michael Polanyi (1967: 4) The Tacit DimensionPreface
This thesis work is the final project for receiving a Master of Science degree in mechanical engineering at Luleå University of technology (LTU), Luleå and has been conducted at Volvo Aero in Trollhättan.
The project has been carried out between February 2008 and September 2008 and has been very interesting and rewarding from start. I feel that this project has made me more prepared for future work and has given me other perspectives to the work of engineering. I will definitely bring all my lessons learned and experiences with me in my “knowledge backpack” using them whenever needed.
I would like to thank all those people both within and without Volvo Aero that has shown interest in my thesis and without any doubt helped me by answering all of my questions and interviews.
Tanks to Gunnar Marke (Volvo Aero) and Mats Lejon (Volvo Aero) for your support and care for my wellbeing during this project.
A special thanks to my supervisors Ola Isaksson (Volvo Aero) for his never-ending enthusiasm in my moments of frustration and Andreas Larsson (LTU) for taking his time answering my emails despite being in USA.
Thank you for your support, guidance and help!
Last but not least, thanks to my family and dear friends for putting up with me during this process.
Tank you!
Erika Andersson Trollhättan 2008-09-01
Abstract
Companies today are facing an increasingly competition and with that the companies have to be more innovative and create new ideas and concepts on a tighter time schedule. This situation increases the demands to use and reuse knowledge, not only figures and facts but even the knowledge that comes with experience such as design alternatives and the reasons behind why selecting one alternative over another, also called Design
Rationale.
The purpose of the thesis was to investigate and understand the organizations needs of Design Rationale and to identify and try out potential approaches to finally recommend a method so that it is possible to capture Design Rationale in an early development phase. In order to find an approach to capture Design Rationale, needs for a possible capturing tool hade to be identified. This was made through personal interviews among the
personnel at Volvo Aero, attending meetings in different projects, observations and many discussions both within and without Volvo Aero. Furthermore three computer based systems where chosen for evaluation since computers are used as the natural way of working and writing at Volvo Aero. These systems where then evaluated and weighted against the needs to be able to se if the systems fulfilled the requirements. Two of the systems where also tested.
Computer tools can effectively help organize and structure thoughts and decisions. A good overview of the situation is one of the effects from this.
When awareness and a basic level of understanding about Design Rationale benefits are received Design Rationale can be captured using the systems suggested.
To be able to implement and capture support and methods for Design Rationale, people need to be aware of Design Rationale existence and it is essential that it becomes a part of and implemented in the design culture at the company.
Table of contents
1 INTRODUCTION...1
1.1 BACKGROUND...1
1.2 VOLVO AERO COMPANY...3
1.3 THE STRUCTURAL COMPLEXITY OF DESIGN...4
1.3.1 Tacit and Explicit knowledge...6
1.3.2 Knowledge lifecycle ...6
1.3.3 Capturing explicit and tacit knowledge ...8
1.4 WHAT IS DESIGN RATIONALE?...8
1.5 WHY DO WE NEED METHODS FOR DESIGN RATIONALE?...9
2 METHOD ...11
2.1 NEEDFINDING...11
2.1.1 Literature study...12
2.1.2 Interviews...12
2.1.3 Participation and observations...12
3 INVESTIGATION AND EVALUATION ...13
3.1 INTERVIEWS...13
3.1.1 Analysis of the interviews ...13
3.2 NEEDS FOR DESIGN RATIONALE TOOLS...15
3.3 STATE OF PRACTICE...16
3.3.1 Current practice at Volvo Aero ...16
3.4 STATE OF ART...17
3.4.1 Hewlett-Packard ...17
3.4.2 Design Rationale editor ...17
3.5 TOOLS FOR DESIGN RATIONALE...18
3.5.1 Design Rational editor...18
3.5.2 MindManager ...20
3.5.3 Teamsite...21
4 RESULTS ...23
4.1 TOOLS FOR DESIGN RATIONALE...23
4.1.1 DRed ...23
4.1.2 MindManager ...23
4.1.3 Teamsite...23
4.1.4 Evaluation...23
5 CONCLUSION AND DISCUSSION...27
6 SUGGESTIONS FOR FURTHER WORK ...29
7 REFERENCES...31
APPENDIX A ...33
1 Introduction
Imagine you just started working at a company that is active on the global market. You just got a new design assignment to solve and there are high demands on delivering products in a short time. To be able to find out the history behind the product, you read old documents but you never really understand why the part looks like it does. The option left is to go and ask a person that has worked with a similar product several years ago. This person is also soon to be retired which means that this person is taking all that knowledge with him and from the company.
This is a problem that not just newly employed persons face but all personnel working with for example design problems. There is a need to capture this “why” knowledge also called Design Rationale due to that the companies of today do face a larger competition. Higher pace and increased demands on delivers are other aspects that make effective collaboration and sharing of knowledge even more important.
1.1 Background
Due to the increasing demands on the companies, it generates that companies
continuously have to progress their product development process. The engineers and their team also constantly have to improve their work strategies and pass on their knowledge and information. The transferring of knowledge is important so that the next team and next generation of engineers can take advantage of the knowledge in an easier way than before.
With development of aircraft systems comes a high demand on quality and safety. This requires great knowledge from many designers who are making their decisions on the basis of several requirements and constraints such as performance, cost, risks and
reliability. The designers are working in an environment where they are pressured to take not only more decisions but also in a shorter time than before, figure 1. Another factor in the decision making process is the assumptions made from experience from the people working in the project. Many people are involved in each project and personnel enter and leave as the personnel’s skills are needed. This makes it of great importance that the assumptions made can be captured, transferred and understood. People without the same experiences can then use and learn from past experiences and knowledge both within the design team as well as other projects and new employees and consultants.
Shorter Leadtime Decision
Intensity
Figure 1 Number of decisions vs. lead-time.
Understanding the intent, the reason why certain decisions are made, of the design is a crucial part of the daily engineering work and a significant portion of decisions is based on understanding of that.
However, this knowledge is seldom expressed in a more formal sense and some things are often taken for granted such as experiences which, as mentioned before, for example newly employed generally don’t have.
Projects that follow the Product Development process have certain duration over time and involve many persons from different areas of knowledge. Since Volvo Aero has increased their ambition level in their product development and the emphasis on providing their own technologies, the projects are progressing in parallel in a larger extent than before. More, parallel, activities generates fewer key persons and more consultants are involved in a larger quantity than before which causes knowledge sharing challenges. This
significantly increases the need to understand “why” the products are defined the way they are. In particular if persons and roles are changed and new circumstances occur after the decisions have been taken.
In this thesis assignment, the aim is to initially investigate and understand the
organizations needs of Design Rationale and to identify and try out potential approaches. The goal is then to recommend a method so that it is possible to capture and use Design Rationale in an early development phase.
1.2 Volvo Aero Company
Volvo Aero was founded in 1930 as NOHAB Flygmotorfabriker and is today a part of the Volvo Group. The company develops and produces components for commercial and military aircrafts as well as for rocket engines.
The company also offers maintenance, repair and overhaul of aircraft engines and industrial gas turbines, sales of spare parts as well as leasing of aircraft engines and aircrafts, figure 2, [1]. Volvo Aero produces components for about 90% of all large commercial aircrafts.
Volvo Aero’s business philosophy is based on close cooperation with the world leading aerospace companies.
Volvo Aero’s strength lies in: - Lightweight designs - Manufacturing technology - Product support
1.3 The structural complexity of design
Designing a product is far from a direct science. Design is often described as a creative activity that is hard to support with exact science [2].
Designing complex structures is something the design engineers at Volvo Aero deal with on a day to day basis since there are many and complex conditions in the aircraft
industry. For example, an aircraft engine has to cope with large differences in temperature. It is cold where the air comes in but very hot, about 2500 °C where the combustion occurs, which makes the choices of material complex. Other conditions are:
• Weight restraints
• Tough physics such as vibrations • Air worthiness and safety
All these also have to be considered to a low cost.
Understanding the concept of Design Rationale and the methods to capture Design Rationale is difficult at first. The reason is that it deals with knowledge, decisions and experiences which form concepts that are as obvious and practical, as they are difficult to define and express. It is often easier to work with for example drawings, computations etc from where you can se an immediate and useful result.
By capturing and sharing Design Rationale and experiences the complexity of the problems and the high pace of decisions made can be more straightforward and more effective.
It is more or less impossible to deal with all the design problems at once. As “Moran and Carroll” says “Design problems are more than complex, they are dilemmas”. A design problem has so many aspects that make it very complex.
For example, design problems [3]: • Cannot be stated per se.
• Cannot be solved with a definitiveanswer
• Are complex, and full of tacit and overstated reasons
• Any solution generates (often unknown) “waves of consequences” • Design calls for creativity and cleverness
For example, a struggle one of the projects had was the choice of whether to use aluminum or titanium for their component. They knew that titanium is very expensive unlike aluminum and there has for a long time, even in other projects, been an interest in the capacity of aluminum. The choice didn’t fall on aluminum due to that they hadn’t enough knowledge about it. The lack of knowledge generated more questions than they could solve at the committed time.
Designing, in the meaning of constructing something, is a process that is individual from case to case but that still often follows a certain path, figure 3a. It starts with receiving a design task that has to be decomposed to get a better understanding and to form a context. When a basic understanding of the task is achieved the designers have to choose which
methods to use. At this stage there are few computerized methods used. When the
decision on how to proceed is made the evaluation takes place using for example tools as CAD drawings and FEM analysis and based on these figures and facts the project team members then makes a decision. Whether the design process is starting over again or not is then based on if the decisions made where satisfying or has to be reevaluated.
But is it really this easy and where does the Design Rationale come in?
Design task Create Evaluate Decide
Design task Create Evaluate Decide
Design task Create Evaluate Decide
Understanding rationale for taking design decisions is to weight multitude of aspects together
Design task Create Evaluate Decide
Understanding rationale for taking design decisions is to weight multitude of aspects together
Figure 3 Design process (top figure, 3a) and capture and usage of Design Rationale in the design process (bottom figure, 3b).
Design task, Create and Evaluate are the first stages and isn’t as separate as one might think, figure 3b. It is a process from where the designers gather knowledge and information so that the best decision can be made in the end. This process doesn’t necessarily have to be done by the same persons. Except from the knowledge coming from figures and facts in this part the involved personnel also gather Design Rationale. This Design Rationale is an important factor when making the final decision since the experienced personnel often knows by experience what works and what doesn’t and which is knowledge that rarely or never is written down. So, gathered information, knowledge and experiences and thereby Design Rationales is then used to make as appropriate decisions as possible.
1.3.1 Tacit and Explicit knowledge
Knowledge can be represented with different levels of richness. The richest forms of knowledge representation cannot be written, not even outspoken. This can be explained in tacit and explicit knowledge. [4]
Knowledge carried in people’s minds, gained through personal experience and therefore difficult to express is called tacit knowledge.
The tacit aspects of knowledge are those that cannot be codified, are hard to transfer and share and generally require extensive personal contact and discussions. [5]
For those people who have gained a lot of experience, some things in the design and the design process feels obvious. For example, what dimensions are possible to cast or what material suites best for certain strains. These people are often not aware of the knowledge they possess or how it can be valuable to others.
As Polanyi [4] expressed it: "We know more than we can tell”, explains tacit knowledge and the issues with Design Rationale very well. The understanding of “why” a part is designed in a specific way comes with experience and stays in peoples minds which make it difficult to communicate to the rest of the organization.
The knowledge of how to ride a bike is an example of tacit knowledge. One cannot learn to ride a bike by reading a textbook because it needs personal experimentation and training to learn.
Rising the understanding of Design Rationale enables the tacit knowledge to become explicit. Explicit knowledge [5] is knowledge that easily can be articulated and which people are aware of possessing. It can without much difficulty be transferred and
communicated to others by for example manuals, documents and procedures. To increase the awareness of possessing knowledge, the tacit knowledge has to become explicit. Making knowledge explicit means making knowledge “visible” and thereby simplifies the sharing since it can be written down and documented.
1.3.2 Knowledge lifecycle
A first question to ask in the lifecycle of knowledge [6], figure 4, is to Identify what is worth capturing? To be able to decide this there has to be an awareness of what Design Rationale is and its means.
Secondly, once the relevant knowledge with its Design Rationale’s has been identified, the issue becomes how to Capture it. In what form can we capture the relevant
knowledge? Typically, much of the significant knowledge is difficult to express, due to the amount of tacit knowledge. Think of how many times that you know something, but are incapable of expressing your knowledge.
Thirdly, when the relevant knowledge is captured, the next issue becomes how to Store the knowledge. If a meeting is, for instance, captured by video recording which provides rich knowledge representation, the question becomes how to store the video tapes. Is the best place to store it in for example in an archive, or on a homepage on internet?
Once the knowledge and its Design Rationale have been Identified, Captured and Stored, it must be possible to Access the knowledge so that it later on can be used. Let’s say that the video tapes were put into an archive, how is it possible to locate them later on? Maybe a background situation has to be attached to the tapes such as a description of when and where the meeting occurred as well as the topic of the meeting.
Access Share Use Learn Store Capture Identify Generate aquire Access Share Use Learn Share Use Learn Store Capture Identify Store Capture Identify Generate aquire
Figure 4 Knowledge lifecycle based on the VIVACE model [6]
The fifth lifecycle stage is how make aware of that the knowledge stored exists so it can be Shared with others. Sharing knowledge goes two ways, for the person that hold the knowledge, the Sharing issue is how to make others aware that the knowledge exists, while the person in need of knowing the knowledge needs to know where to search. Sharing knowledge can be done in a formal way such as electronic publications, distribution lists, make notifications and announcements via e.g. the local website etc. Other, just as interesting ways for sharing knowledge can be open, or directed, meetings between people and different design teams with the purpose of sharing ideas and
experiences. For Design Rationale, the Design Reviews can play this role.
Once shared, the next stage becomes deciding what knowledge to be Used in order to transform the knowledge into practical actions. Typically, if a concept lacks a few of the features wanted the entire concept is ignored despite the benefit of the remaining features which is an unconscious action. [27]
The seventh stage is about how to Learn from using the knowledge and put it into a system so that the knowledge can be reused. One example is to have meetings between separate projects with the purpose to exchange knowledge and information and thereby learn from each other.
Finally, the last stage is where the knowledge and Design Rationale translates into practically solving problems and design work is generated.
1.3.3 Capturing explicit and tacit knowledge
As described in chapter 1.3.1, knowledge can be put into two categories, tacit and explicit knowledge, and to be able to use the knowledge it firstly has to be identified and
captured, figure 4.
Since explicit knowledge is knowledge you are aware of possessing it doesn’t make it very difficult to capture since you know what to write down. This type of knowledge can easier be expressed in words and numbers which also enable sharing in the form of data, manuals, specifications etc. Explicit knowledge often makes the capturing and sharing more structured depending on the human beings laziness.
Capturing tacit knowledge on the other hand is more challenging since we, as mentioned before, don’t know that we possess it. Tacit knowledge is often transferred via
conversations at the coffee breaks, in the cafeteria line or at the bus on the way to and from work. Capturing can for example be made via video recordings where the attendees at the meeting don’t have to decide what is important enough to write down. There are also possible to later analyze for example the body language and what is said “between the lines”.
It is easy to ignore or forget to capture tacit knowledge since explicit knowledge is visible and that it for many people is hart to express something that you “just know” ore is a feeling. It is still very important to try to capture or at least transfer the tacit knowledge since it is a great part of our knowledge.
1.4 What is Design Rationale?
If you look up the word “rationale” in a dictionary it says “logic cause” or “principle” which gives a quite good basic understanding, but the expression “Design Rationale” requires a bit further explanation. Many researchers have through the years defined what Design Rationale is, based on their point of view. Some of the definitions of Design Rationale are:
• The design alternatives and the reasons behind why selecting one alternative over another. [7]
• Design Rationale is the reasoning and argumentation that underlies the activities that take place during the design process. [23]
• Design Rationale offers more than only the decisions, but also the reasons behind each decision, including its justification, other alternatives considered, and argumentation leading to the decision [8]
Another way to explain and understand Design Rationale is to simply, responding to questions of “why” rather than “how” and “what”. Why are we designing the way we are? Why is the detail three meters long instead of two? and so on. Asking this simple question helps to analyze and understand not only the design decisions but all kinds of decisions.
As shown above, the interpretation of Design Rationale is in the eye of the beholder and has the potential to be used in many different ways. One set of situations where Design Rationale can be useful, defined by Burge and Brown [8], are:
• Design verification
The Design Rationale can be used to verify if the design decisions and the product itself are the reflection of what the designers and the users actually wanted.
• Design evaluation
The Design Rationale is used to evaluate the various design alternatives discussed during the design process.
• Design maintenance
The Design Rationale helps to determine the changes that are necessary to modify the design.
• Design reuse
The Design Rationale is used to determine how the existing design could be reused for a new requirement with or without any changes in it. If there is a need to modify the design, then the Design Rationale also suggests what needs to be modified in the design.
• Design teaching
The Design Rationale could be used as a resource to teach people who are unfamiliar with the design and the system.
• Design communication
The Design Rationale facilitates better communication among people who are involved in the design process and thus helps to come up with a better design. • Design assistance
The Design Rationale could be used to verify the design decisions made during the design process.
• Design documentation
The Design Rationale is used to document the entire design process which involves the meeting room deliberations, alternatives discussed, reasons behind the design decisions and the product overview.
So, if the rationale is captured, used and shared in a proper way there will be many benefits generated from it.
1.5 Why do we need methods for Design Rationale?
Design, as mentioned before, can be seen as a problem-solving process (se chapter 1.3) where the designers face a series of design issues and decisions along the way. This process involves choosing the best option from among all the alternatives. To take each design decision, the engineers have to use the “data” from current facts and requirement specifications, “current knowledge” which often is well documented, but also “past knowledge” such as experiences from earlier projects, design principle and “best practice”. To be able to use past knowledge it has to be available and therefore consequently captured in a satisfying way.
There are many areas where Design Rationale is useful. Some of the most common and investigated areas today are in software development and architecture but it is becoming more and more well-known in the Computer Aided Design area. [2]
When working in a project the product life cycle is long and most development projects take years to complete. Design decisions and especially the “why’s”, are forgotten to be documented since it didn’t seem to be important knowledge at the time.
Documenting Design Rationale is also very useful if any factors change during the process or even after. Then it is possible to look back and se what kind and why the decisions were made and learn from “the mistakes”. Design Rationale also helps the design engineers to avoid making the same mistakes as before and learn from earlier experiences. This will save both time and money for the company since the product development process then can be more effective.
Design Rationale techniques can be used as [2]: • An aid for documenting
• Learning • Re-evaluate • Evaluate
• Learn the design • Learn from mistakes
Let’s continue on the example from chapter1.3. Since there has been an interest for aluminum as a choice of material for a quite long time and several projects have had it in mind there should be quite a lot of research material about it. The pressured time
schedule has instead created a situation where no one has been documenting. If the projects through out time instead hade documented the small parts of the effects they investigated and gathered all of that, some day there would be enough information for a project to actually be able to investigate the possibilities of using aluminum to its full extent. The time aspect makes effortless capturing of Design Rationale an important requirement.
2 Method
There are several methods for gathering necessary information and knowledge about the needs at Volvo Aero, figure 5. Methods used were mainly interviews with the personnel, discussions and by attending meetings. These methods where chosen on the basis of the thesis projects characteristics and is presented in this chapter.
METHODS Interviews Participation Literature and journals Questionnaires Internet Observations METHODS Interviews Participation Literature and journals Questionnaires Internet Observations
Figure 5 Methods suggestions
2.1 Needfinding
The purpose of needfinding is to gain knowledge about what the needs are in Design Rationale and if there is a need for Design Rationale at Volvo Aero. It is essential to identify and state the “real needs” before starting developing a solution. Mapping out the needs enables to focus on finding a solution that might not be as pronounced as other [9]. Needfinding: “The Why and How of Uncovering People’s Needs” and its stages of the needfinding process can according to Dev Patnaik & Robert Becker [9]be defined as:
• Frame and Prepare: goals, subjects, and site - Frame the research question
- Define the needer group
- Study established data for grounding in the subject • Watch and Record
- Immerse oneself in the needer group
- Avoid intrusions to keep the behavior natural - Using appropriate recording media
• Ask and Record
- Interview in the customer's environment - Record information in the customer's terms • Interpret and Reframe
- Create need statements
- Classify and prioritize the needs - Reframe the research
2.1.1 Literature study
A literature study is essential for getting an understanding of the topic going to be researched and it also prevents the researcher from doing anything that already has been done.
The literature study was made by searching the internet, reading books, articles and journals. This also helped identifying what questions to ask for the interviews.
2.1.2 Interviews
Conducting interviews is a preferable method if the questions are many as well as tricky questions and answers can be explained right away [10]. It is also easier to get a “feeling” of the current situation since, in this case, there were “face- to- face” interviews and inspiration to further, more relaxed, conversation could be made. It is also easier to ask new questions and adapt them to the situation as the interviews proceed.
On the other hand interviews tend to take a long time and can have the effect that the interviewees answers what they think is the right answer and not what they really feel. The long time and the often many questions also make it difficult to analyze and replicate.
An interview can be conducted structured or unstructured. Structured interviews aims to ensure that each interviewee is asked exactly the same questions and in the same order to ensure that the answers are going to be correct compared, gathered and answered within the same context [12].
In an unstructured interview the questions can be adapted depending on situations and interviewee and is analysed depending on each interviewees answer. [12]
2.1.3 Participation and observations
Through observations the observer allows to get close to the reality as well as being able to observe body language, gestures and expressions. On the other hand it doesn’t tell anything about the observed persons thoughts and emotions [11].
There is two types of observations; structured and an unstructured. In an unstructured observation everything is observed opposite to the structured way where the observer knows what to look for and has a more pronounced goal for the observation. [11] Participating meetings also helped understand how the personnel interact between the fields of knowledge and how documentation was carried out on the day to day basis as well as the possibility of seeing a pattern in the way of thinking and communicating among the personnel.
3 Investigation and Evaluation
3.1 Interviews
To obtain a broad perspective the interviews were conducted with people with different background, different work assignments and from different departments. All the
interviews were documented, summarized and analyzed.
Eleven people were interviewed and each session took approximately 45 minutes. The first interviewees were selected with help from supervisors. These, in its turn, generated more recommendations on people to interview and which also was conducted.
Interviewed persons are working in areas of: • Definition engineer
• Design engineer • Development research • Design leader
• Stress engineer
• Chief architect product development process
The documentation of the interviews was made by recording them in hope that the focus could be maintained on the discussion in a larger extent as well as eliminate disturbance such as taking notes. The interviews were carried out on the basis of a few questions like:
• What is your work task?
• What is your role in the project?
• How do you interact with the other people in the project? • What is it that decides if a decision is ok ore not?
• How is a decision made in your project?
The answers from these questions resulted in new issues and new discussions took place gradually.
3.1.1 Analysis of the interviews
When the interviews were completed and information was collected by the use of recording, an analysis of the gathered information was made.
The analysis, with its purpose to find needs for what features a Design Rationale system in the end should have, can be divided into three steps:
1. The initial phase of the analysis was to listen to the recordings and then write down the
key issues/observations that distinguished the interviews as well as the observations from the meetings.
2. Further, these key issues/observations were analyzed by putting them into three
different perspectives:
y People – the human factor, understandings and knowledge y Process – way to work, support, instructions
y Tools – system support For example, figure 6:
One observation was that the personnel often use old knowledge about an engine if, from start, someone knows that there exists an engine similar to the one going to be designed. [23]
When putting this into the context of “people” and asking the question “why” the answer could be that it is easier for the personnel to go and ask someone who knows than to search for the information wanted. The context of “Process” can have the answer that there isn’t any good established way to handle the situation of using old knowledge and finally “tools” can have the answer that there is poor search ability amongst old projects.
• •PeoplePeople • •ProcessProcess • •ToolsTools 2. Why? 2. Why?
It is easier for the personnel to go and ask someone who knows than to search for the information wanted. There isn’t any good established way to handle the situation of using old knowledge There is poor search ability amongst old projects 3. 3. NeedsNeeds • Search ability on old projects • A place to collect experiences 1 1. Key issues. and observations
The personnel often use old knowledge
about an engine if from start someone
knows that there exists an engine similar to the one
going to be designed. • •PeoplePeople • •ProcessProcess • •ToolsTools 2. Why? 2. Why?
It is easier for the personnel to go and ask someone who knows than to search for the information wanted. There isn’t any good established way to handle the situation of using old knowledge There is poor search ability amongst old projects 3. 3. NeedsNeeds • Search ability on old projects • A place to collect experiences 1 1. Key issues. and observations
The personnel often use old knowledge
about an engine if from start someone
knows that there exists an engine similar to the one
going to be designed.
Figure 6 Example of analyzing a key issue/observation.
3. Finally, the needs where identified by looking at the “answers” (point 2, figure 6) and
identifying what needs would fulfill these “answers”. Figure 6.
A summary of the needs created this way can be seen in table 1 below. For complete table and analysis see appendix A.
3.2 Needs for Design Rationale tools
The needs that werecreated from the analysis of the interviews, meetings and the day to day conversations with people working at Volvo Aero can be seen as a summary in table 1:
Table 1 Summary of needs for Design Rationale tools.
Needs
A) Searchable on old projects and documents B) Collect experiences and knowledge C) A ”natural” system
D) Simple
A) “Searchable on old projects and documents” – One of the major expectations on a
support system expressed from almost all the interviewees is that the Design Rationale’s from earlier projects and documents should be possible to search for so there is a
possibility to use and reuse that knowledge. The projects today are “closed” when they are finished and the information and knowledge is not available anymore. As one of the stress engineers expressed it “If I don’t remember myself, it is easier for me to go and ask someone I think knows the answer to my question instead of searching in a database somewhere”. This requires the solution to have a good search capability both for the projects as a unit as well as within the systems.
B) “Collect experiences and knowledge” – Another expectation is the need to have a
more pronounced way of capturing experience and knowledge. The collected and stored substance today is mostly figures and facts. Expressed by several of the interviewees as well as based on observations there is also a need to have a central place where both problems and solutions are connected and gathered.
C) “A natural system” – For the solution to be used at all, there is a need to make it feel
natural to use. One of the design engineers made a considerable comment in his interview that “there is a project that has a very extensive and detailed concept book, but, in that project they hade a person that enjoyed writing documents and wanted it himself”. The general feeling amongst the engineers is that it is boring and time consuming to
document. This requires the solution to become a natural element in the day to day work.
D) “Simple” – The simplicity in a system is also one of the very important needs. If
something is to complicated the human being tent to loose interest especially if there always is short of time to learn and evaluate. This makes it important to make the system
easy to use but first and foremost easy and quick to learn but still capable coping with large amount of information. Based on conversations as well as the interviews and observations, simplicity is important due to the constant pressure of time and the many different systems already existing.
3.3 State of Practice
The practice for documentation at different levels at Volvo Aero is shown in this chapter. These systems are the once used today.
3.3.1 Current practice at Volvo Aero
The global tool that enables use and reuse of old knowledge is the Operational
Management System (OMS). Since OMS is a global system there are foremost standards, instructions and documents that work generally at the company that is documented. This is a system that is good for the general understanding of the company but that isn’t optimal for a specific component. This makes it hard for the specific “individual
character” to document the rationale since this is a system that mostly tells how to do and not why. [13]
One step closer to the project level and that also is a part of OMS is the Global
Development Process (GDP). This is a general development process template that can be adjusted to different assignments but is primarily made for product development projects. In GDP there is a Gate system which puts certain demands in documentation and
activities such as design reviews and has to be fulfilled before entering the next gate. This project assurance plan ensures that a minimum level is kept in the projects but even this is a system that mostly tells what to do and again not why. [13]
One of the demands in GDP, is a document itself and called a concept book. This is a document where the compiled ideas and concepts are gathered. Here is actually an excellent opportunity to write down the rationale but these books vary a great deal due to different projects and ambition from those who write it and generally the rationale is not documented.
The Document Management System (DMS), which is one of the modules of SAP, is a system where documents that needs to be recorded and made traceable are saved and given an identification number. When a document is found and used by another part it can then add for example lessons learned from using the information. This is a system that enables a central place for handling and storing documents. This system could be a great asset for the spreading of information but is still a complex system with a vague search function. [13]
Teamsite is a Microsoft product [20] that is used for documenting in general in the
projects. It can be compared to a homepage that in this case is individual for every project and that only the members of the project have access to. This site is a part of the daily working environment and its structure is based on a file system. Here project members can interact and upload documents which depending on level of ambition can have different appearances.
The common denominator for these recording mechanisms is that the use of them is highly depending on the situation as well as the level of ambition by those who use it and that the systems tell what and how to do but not why.
3.4 State of Art
Sharing knowledge and information is something that happens every day all over the world at different companies. But, is the knowledge stored in some way, is the “right” knowledge stored and is it easy to share amongst the involved. Hewlett-Packard is one of the companies working with knowledge sharing improvement.
3.4.1 Hewlett-Packard
Hewlett-Packard (HP) [14] is an American company that mainly produces PC-computers, printers and servers. The company was founded in 1939 by Bill Hewlett and Dave
Packard.
HP has an open work culture where all employees work in open cubicles which benefits knowledge sharing. Many employees are technically-oriented and all are participants in a profit-sharing program.
The company is also known for its decentralized organizational structure and mode of operations. There is little organized sharing of information, resources or employees across units. Although the company is culturally open to sharing, few business units are willing to invest time and money in efforts that do not have an obvious and immediate payback for the unit.
It is common, however, for employees to move from one business unit to another. This mobility makes it possible to some degree of informal knowledge transfer within HP. Although HP’s CIO and the manager of Information Systems Service and Technology felt that knowledge already is exchanged well within the work group and even business units, they felt that there is little support in the culture for sharing across units. In 1995 they noticed that several knowledge management initiatives were in progress in various HP business units and some of them had been in place for several years whilst others were just in an early stage. Noticing this they decided to attempt to assist the knowledge management at HP by holding several workshops with people interested in the topic. The current approach at HP, which emphasizes awareness and the development of a general terminology and structure through workshops, is subtle. The two managers feel it is appropriate for HP’s culture to develop in this area and they are working on several approaches and are always looking for other techniques and methods that might be introduced.
3.4.2 Design Rationale editor
Dr Rob Bracewell of the Engineering Design Center, University of Cambridge, research and creates innovative tools to aid designers. One of his latest research domains, the Design Rationale Editor (DRed), is already implemented and introduces into industry.
For this he got, along with those how introduced the software in Royce, the Rolls-Royce’s R&T Director’s Creativity Award for 2004 [16].
DRed is a tool that, when used, can capture, graphically present and store rationale for future use and reuse and it can also help designers work in a logic way through their designs [17].
This tool captures rationale in the form of structured spider diagrams, and is already being used with great enthusiasm in industry. In order to increase the tool's range, Rob is working on bi-directional linking with other software: already it is possible to link DRed maps to Word documents and vice versa, and to create labels dynamically in DRed maps from data in Excel worksheets. Forthcoming improvements will see similar integration with OpenOffice.org and a version that runs on Linux.
DRed is already in use within Rolls-Royce and is already improving decision-making and communication as well as reducing the need for long and tiresome reports. For example the use of DRed in now mandatory for all design scheme reviews in one of Rolls- Royce projects. According to Rolls-Royce’s designers DRed do have positive affects on the design work and is now incorporated into their standard Product Lifecycle Management tool set. In longer term they hope DRed will improve even more the sharing and transfer of knowledge not just between projects but also between business sectors. [18]
3.5 Tools for Design Rationale
To be able to see if there is a possibility to capture Design Rationale with the help of a computer based system, three different systems where chosen. These choices are based on recommendations, systems used today and from the needs. Computer based system where chosen due to that computers are used as the natural way of working and writing at Volvo Aero. Computer support is also an important factor due to that the general feeling amongst the personnel is that it is far to time consuming to create and transfer
handwritten documents into computer written documents.
3.5.1 Design Rational editor
Dr Rob Bracewells research project about the Design Rationale editor (DRed) is developed to record Design Rationale as it is created and displayed as a mindmap structure, figure 7. The aims of his project where to [15]:
• Understand how the information retrieved from various document types can be semantically linked in order to provide an integrated view of related information when attempting to reuse existing knowledge.
• Develop a retrieval method that enables keyword-based or natural language queries along with a graphical navigation of related information.
• Develop an indexing structure for capturing and retrieving knowledge and experience
Action symbol
Figure 7 DRed structure
This software tool enables engineers to record their personnel rationale as it is created and considered. The tool helps to structure the possible design options and its thoughts and arguments through adding for example action symbols to each topic, figure 7. It is also god for presentations in several considerations as well as for reducing the needs for massive design reports, and to eventually build a database with rationales for future use and reuse.
DRed is also integrated with Microsoft applications which make it possible to link DRed maps to Word and Excel and improvements as integration with Linux is on its way. DRed is collaboration with Rolls-Royce and is already used by the same with great success.
Pros:
9 low training requirement 9 Well integrated with Microsoft
applications
9 Mindmap structures makes it easy to follow the “thinking” 9 Color coded visual symbols
Cons:
9 Hard to overlook when large structures
9 Can feel messy due to the large color coding figures
This tool was chosen for evaluation due to an expressed interest from one of the departments at Volvo Aero. The evaluation of DRed is based on literature and internet research. This due to access problems to the tool since it is on its way to be
3.5.2 MindManager
In 1998 MindManager (MM) was promoted as a visual thinking tool that supports human potential, developed by Mindjet LLC [21]. Mindjet was founded on the principle that creativity, innovation and collaboration must be a key factor in every successful activity. MM can provide [22]:
• Visually capture, organize and link key ideas and information to inform decisions, motivate actions and get things done.
• Brainstorm, plan, strategize and interact in more dynamic and meaningful ways. • Get clarity on the big picture, down to the smallest detail – for everyday tasks and
large-scale initiatives.
MM is well integrated with Microsoft applications such as for example Excel, Word, PowerPoint and Outlook which makes it easy to import and export documents, figure 8.
It is also possible amongst other things to put notations and action items to team members and important information. Both individuals and entire teams can access, update and share knowledge in an online environment.
Pros:
9 Easy to understand and start using
9 Integrated with Microsoft applications
9 Good preinstalled templates 9 Mindmap structures makes it
easy to follow the “thinking” 9 Color coded visual symbols
Cons:
9 Difficult to overlook when large structures
9 Not integrated with all Microsoft applications
This software system was chosen because it is already in Volvo Aero’s possession and is used by a few of the personnel that also made it possible to test and try out the program. Even though it is used by some it is still much unknown amongst the design engineers.
3.5.3 Teamsite
Teamsite is a Microsoft web-based solution that makes collaboration and sharing of documents online possible [20]. This is a tool that in this case is available only within the Volvo corporate network due to secrecy and is managed by Volvo IT/Aero.
Teamsite enables groups, teams and departments to have their own website from where they at any time and place can store and share information regarding their specific project at one secure part of the Intranet, figure 9.
It increases the possibilities of communication within the Volvo group and it reduces big quantities of emails with heavy file attachments.
Figure 9 Teamsite structure
Due to that the Teamsite is a place to collect information regarding a project it makes it easier to find the information wanted. The personnel can share not only documents but also useful links, contacts, calendars, tasks and interact on a discussion board.
Pros:
9 Easy to share documents 9 Good to have a central place to
gather project specific
information – enhances a team feeling
Cons:
9 The site can easily be
unstructured due the file structure 9 The work surfaces are only
meant to be stored in a limited time.
9 When the project is finished the information shall be removed.
This tool is today used at Volvo Aero in a day to day basis and it was chosen for
evaluation because of that reason and thereby be able to se if it can provide capture of the rationales in the projects even though it is not thought of as a Design Rationale capturing tool.
The Teamsite was evaluated by a brainstorm session with team members from a project using Teamsite as well as testing and trying.
4 Results
4.1 Tools for Design Rationale
The results from the investigation and evaluation of the selected Design Rationale tools are shown in table 2 where the tools are weighted against the needs and complemented with a clarifying comment.
4.1.1 DRed
Since an opportunity of testing DRed wasn’t possible the evaluation is based on literature search and evaluations already conducted. This leaves some evaluation against the needs unanswered and therefore some of the areas are left blank. It has been reported [19] to be a program that is easy to learn and use and that contributes to easier decision making.
4.1.2 MindManager
This system with its mindmap structure is a system suitable to use in day to day meetings when issues of any kind are discussed. There are nice templates for e.g. the project leader to use to prepare for meetings and a pedagogic introduction film at the start, showing the basic skills.
4.1.3 Teamsite
The Teamsite is used within every design project at Volvo Aero today. It is used as a central place for all the team members to upload their contributions to the project. The more documents uploaded the harder there is to find what searched for. This due to that the responsible person for the Teamsite basically designs the site himself as to what folders and structure the information put on the Teamsite is going to have. Low structure makes low interest. Further evaluation of the Teamsite can be seen in appendix B.
4.1.4 Evaluation
The tools are evaluated and weighted against the needs by the scale:
1 – Fulfill the need
2 – Fulfill the need partially 3 – Do not fulfill the need
Table 2 Evaluation of Design Rationale tools against the needs
Needs
(for further explanation of needs see chapter 3.2)
DRed
MindManager
Teamsite
Searchable on old projects * (* = Further explanation)
2
Depends on current safety restrictions specified from the business deal.2
Depends on current safety restrictions specified from the business deal.
2
Depends on current safety restrictions specified from the business deal. Searchable on old documents** (** = Further explanation)
2
Unclear database search capability. Has the capability of savingdocuments in some Windows application
file formats.
2
Unclear database search capability. Has the capability of saving
documents in most Windows application
file formats.
1
Has a search function but due to poor structure it is hard to know what information
is relevant or not.
Possibility of being a ”natural” system/ a natural part in the day to day work
1
Gives a good overview due to graphical representation of
relations and dependencies.
1
Gives a good overview due to graphical representation of relations and dependencies.
2
Is already today a natural part of the dailywork but has no good representation of
relations and dependencies. Collect experience
and knowledge Still requires an
2
understanding of Design Rationale
3
Only collects figures and facts unless someone consciously
writes ”Design Rationale documents”
Simple
1
low training requirement and easy
to use
1
low training requirement and easy
to use
2
Generally a simple system but the poor structure can make it
hard to use.
Availability
Not accessible atpresent
Accessible, but requires a request
In the standard supply
*
The wish to search for old projects and documents involves more than just the system itself. The search ability is to a high degree controlled by the different competing customers and safety restrictions between the projects coming from the business deals required. The Teamsite for example is closed and locked after every project and a request has to be delivered to be able to get access.
**
For the personnel to have access to and the possibility to search for a document it requires that everyone can se the specific file format the document is saved in. Either the company has to make the chosen system to a standard system or that the system has the possibility to save the document into another file format standardized at Volvo Aero.
5 Conclusion and Discussion
Using the programs evaluated can effectively help organize and structure thoughts and decisions and enables to get a good overview of the current situation. My conclusion is that it is possible to capture Design Rationale first when awareness and a basic level of knowledge about Design Rationale are received and more important when the benefits of capturing Design Rationale are understood.
The result of this thesis is based on analysis of findings from interviews, participation and literature study. The methods chosen are based on the affect of the apparent difficulties to define and clearly express Design Rationale and are adapted for the interviewees to ease the verbalization of their tacit knowledge (se chapter 1.3.1).
The selection of tools was limited by the fact that access to DRed was not possible during the period of the thesis project. These limitations lead to an imbalance in the level of evaluation where some tools hade the advantage of being investigated on a deeper level. Capturing and managing Design Rationale by using the chosen tools itself and without any other support is limited. Automatically capture Design Rationale via the usage of a computer based program, I believe is a challenging task, without any knowledge of Design Rationale and its benefits. It is also very important to be aware of and have in mind that the captured Design Rationale is useful for others and for later reuse since the feeling of being of non importance can make the capture poor.
To be able to implement and capture support and methods for Design Rationale, people need to be aware of that something called Design Rationale exists. It is essential that it becomes a part of and implemented in the design culture at the company.
There are several ways of increasing the awareness of Design Rationale amongst the personnel and the usage of several channels for that increases the possibilities of reaching out to all personnel, figure 11. Some possibilities could be through education, informing about Design Rationale at staff information meetings, write about it at Violin (the internal website) and make sure that all the newly employed gets information about it as well as how important it is to capture. Other suggestions are to implement it in OMS (se chapter 3.3.1) or maybe such a simple thing as putting up a poster with some basic “why” questions and encouragement in every meeting room.
Because of the challenge in understanding Design Rationale, the example of education in a structured way such as a class, might increase the possible effect of people thinking of it as “dopey”. Therefore the need of making the topic concretized is of great importance.
Informing newly employed at introduction Poster in meeting room OMS Violin Education DMS Informing at staff information meetings Informing newly employed at introduction Poster in meeting room OMS Violin Education DMS Informing at staff information meetings
Figure 10 Channels for receiving Design Rationale awareness
The Document Management System (DMS) is a system used at Volvo Aero today where the document that needs traceability is stored and given an identification number. Since Volvo Aero successfully is increasing the development of their own products they need to “own” their own information and lessons learned. They also need to take care of the same and also increase the ability to search for it. Further development of DMS to increase the search ability, availability as well as the user friendliness of the system together with an understanding of Design Rationale, I believe the need of gathering Design Rationale is possible.
Choosing a computer based system for capturing Design Rationale has a possible scenario of being put into the pile of other programs seldom used due to that the personnel today already cope with a number of systems.
Despite this scenario I think that a computer based program is easiest to embrace and implement to the daily work since using it-systems is the every day work tool.
To use Design Rationale it needs to be easy to write down and to be a living document that can be complemented when needed. Systems of different kinds, discussed above, can help structuring and organizing e.g. thoughts although finally I strongly believe that the awareness of Design Rationale must be the first thing to be brought into daylight and also why it is important to capture Design Rationale as well as what the personnel benefit from capturing Design Rationale.
6 Suggestions for further work
Since awareness of Design Rationale is the first step towards the possibility of capturing Design Rationale, it would for future work be interesting to find methods for:
Achieving awareness about Design Rationale amongst the personnel at Volvo Aero.
When awareness is achieved how to proceed so that awareness can lead to understanding of Design Rationale and its benefits.
Further work needs to be done in the evaluation of not just computer based programs but also other solutions for capturing Design Rationale.
7 References
[1] Volvo Aero Corporate presentation 2008-02-06
http://violin.volvo.net/violinaero/corporate/en/home.htm 08-06-20
[2] Moran T. P, Carroll J. M. Design Rationale: Concepts, Techniques, and Use Lawrence Erlbaum Associates, 1996, ISBN 0-8058-1567-8
[3] Lago P. Lecture notes on Design Documentation
http://www.di.univaq.it/muccini/MWT07/Lectures/Lezione04_DesignRationale.pdf
08-04-03
[4] Smith M. K. (2003). Michael Polanyi and tacit knowledge. The encyclopedia of informal education.
http://www.infed.org/thinkers/polanyi.htm 08-08-06
[5] Tacit knowledge
http://en.wikipedia.org/wiki/Tacit_knowledge 08-08-06
[6] VIVACE Forums, forum2, poster 1
www.vivaceproject.com 08-08-10
[7] Burge J, Cross V, Kiper J, Maynard-Zhang P, Cornford S. (2006). Enhanced design
checking involving constraints, collaboration and assumptions – Ontology supported rationale for collaborative argumentation.
Design, Computing, and Cognition, Gero J (ed), Kluwer Academic Publishers, Netherlands. pp. 655-674.
[8] Burge J, Brown D.C. (2002). Discovering a research agenda for using design
rationale in software.
Maintenance Computer Science Technical Report. Worcester Polytechnic University. WPI-CS-TR-02-03.
[9] Patnaik D, Becker R. (1999). Needfinding: The Why and How of Uncovering People’s
Needs. Design Management Journal.
http://www.humancentered.net/blog/Needfinding.pdf 08-04-07
[10] Dahmström K. (2000). Från datainsamling till rapport. Studentlitteratur AB ISBN: 91-44-01458-9
[11] Kylén J-A. (2004). Att få svar.
Bonnier Utbildning AB, Stockholm, ISBN: 91-622-6577-6 [12] Interview methods
[13] Operational Management System
http://violin.volvo.net/violinaero/corporate/en/projects_processes/processes/operational_
management_system/processes.htm 08-06-16
[14] Davenport T. H. “if only HP knew what HP knows”
http://www.providersedge.com/docs/km_articles/If_Only_HP_Knew_What_HP_Knows. pdf 08-05-23
[15] Cambridge EDC (2006). Retrieving Design Rationale.
http://www-edc.eng.cam.ac.uk/research/knowledgemanagement/km2/ 08-05-19
[16] KIM project (2006). R. H. Bracewell.
http://www-edc.eng.cam.ac.uk/kim/people/rob-bracewell.html 08-05-19
[17] Cambridge EDC (2006). Developing, Integrating and Testing Rationale Capture
Tools
http://www-edc.eng.cam.ac.uk/research/knowledgemanagement/km2/capturetools/
08-05-19
[18] Department of Engineering at the University of Cambridge (2004). Rolls-Royce R&T
Director's Creativity Award.
http://www.eng.cam.ac.uk/news/stories/2005/rollsroyce_award/ 08-05-19
[19] Bracewell R, Wallace K. Introducing the capture of argumentation-based design
rationale into industrial practice
http://www.users.muohio.edu/burgeje/dred_eindhoven.pdf 08-02-26
[20] Teamplace portal (2007), version 1.2.
http://portal.teamplace2.volvo.net/TeamPlace0/default.aspx 08-06-04
[21] Mindjet (2008). Mindjet.
http://www.mindjet.com/whymindjet/customers/default.aspx 08-06-02
[22] Mindjet (2008). Mindjet.
http://www.mindjet.com/products/mindmanager_pro/default.aspx 08-06-02
[23] Horner J, Atwood M. E. (2006). Design Rationale: Goal, Problems, and Context. Workshop on Design Rationale: Problems and Progress, Design, Computing, and Cognition. Eindhoven, Netherlands.
Appendix A
Utvärdering behov
Observation Varför? Behov
Man tittar på tidigare motorer, om någon sedan innan vet att det finns liknande motorer.
- Kan ej titta på alla motorer då det finns olika kunder – sekretess - Svårt att söka efter gamla motorer
– Dåliga sökmotorer? - Lättare att gå och fråga - Dåligt dokumenterat - Tidskrävande - Tråkigt - Sökbarhet/spårbarhet på gamla projekt - Samla erfarenheter
Citat: ”Om vi skulle skriva dokument skulle arbetet stanna upp och det har vi inte tid och råd med”
- Tidspress - Tråkigt
- Tar tid från det roliga
- Ser inte att man dokumenterar för nästkommande
- Fokus på ”här och nu” - Inget ”naturligt” sätt att
dokumentera
- Ett ”naturligt” system.
- Känsla av att det som skrivs ner är till någon nytta
- Känsla av att det bidrar till
vidareutveckling av projektet.
- Enkelt - Snabbt Tänker inte på att de
dokumenterar för andra och även för sig själv till nästa projekt. Ser/förstår inte innebörden av Design Rationale.
- Inga krav på ”Design Rationale dokumentation”
- Har aldrig tänkt i de banorna - Om behov av att veta orsaken till
beslutet - frågar istället - Inget uttalat behov av Design
Rationale
- Gammal erfarenhet (behöver inte skrivas ner)
- Göras medveten om Design Rationale
Osäkerheter och frågor fås svar på och bekräftas genom samtal.
- Lättare att fråga än att leta - För många olika dokument som
läggs på hög. - Svårt att söka/hitta - Spårbarhet av dokument - Samlingsplats för dokument m.m. Vill inte ha ytterligare ett
nytt ”delsystem”.
- För många olika dokument - svåra att hitta
- trötta på olika system - jobbigt
- det gamla som man redan kan och funkar är bra.
- Enkelt
- Naturlig del i arbetet - Ske här och nu
Appendix B
Teamsite utvärdering
Fördelar:
• All projektinformation samlad på ett och samma ställe. Med all information menas: tasks, filer av diverse slag, medlemmar i projektet, kalendrar, (diskussionsforum), mötesprotokoll.
• Möjlighet att skapa ”under sites” för ett avgränsat område (ex en granskning) och ge specifik behörighet till den.
• Verktyg för att planera och genomföra möten
• Koppling till Outlook – maila action – mötesplanering synkad
• Informationsspridning, typ anslagstavla, komplement till ”vanliga möten” • Möjlighet att skapa sin egen mapp där det mesta finns vad gäller t.ex. definition
samt skall man leta efter andra kan dom hittas under ”design lead” eller liknande. • I stort sett alla, även andra projekt kan (om tillstånd sökes och beviljas) komma åt
info på Teamsiten.
• Om Teamsiten används ”direkt” på mötena sparar man tid istället för att först skriva mötesprotokoll på papper för att sedan föras in i datorn/Teamsiten. (Detta görs dock ej i detta projekt)
Nackdelar:
• Vi är ej tillräckligt utbildade om Teamsiten för att kunna utnyttja den fullt ut. • Svårt att flytta/kopiera filer.
• Svårt att hitta pga. att en standard mall för hur filmappar skall läggas upp saknas/inte är känd.
• ”Slask mapp” att föra ej giltiga filer till saknas. • Koppling/länk till R/3 DMS svår.
• Ingen gemensam Volvo Aero struktur – alla har olika vilket gör det svårt att hitta i/för andra projekt.
• Möjlighet att ge ut samma ”actions” till fler än en person saknas.
• Behörighet kan också vara ett problem ibland och otydlig – ex borde det kanske finnas behörighetsgrupper som per automatik ger personen tillgång till de Teamsiter denne behöver kunna läsa.
• Varje möte har en egen actionlista och beslutslogg – ingen möjlighet att samordna dessa.
• Svårt och omständigt att flytta dokument.
• Koppling till dokument som ligger på en annan plats t.ex. mappar i utforskaren dvs. ändra på ett ställe och det uppdateras automatiskt i Teamsiten.
• Det tar tid att lära sig alla funktioner.
• Ingen översiktsfunktion, det skulle behövas någon typ av översikt som t.ex. en trädfunktion eller annan översikt över innehållet/mapparna.
Bidrar Teamsiten till kunskapsöverföring/kunskapshantering?
• Nej, man går fortfarande och frågar istället för att leta efter information på Teamsiten.
Är det enkelt att följa tankegångarna i Teamsiten?
• Nej, eftersom det är en vanlig mappstruktur där man döper mapparna själv och det lätt blir rörigt med konstiga namn.
