INFORMATION BEHAVIOUR IN ENGINEERING PRACTICES

Get Complete Project Material File(s) Now! »

Engineering projects

The concept “project” is defined by the South African concise Oxford dictionary (2002: 392) as an “enterprise carefully planned to achieve a particular aim”. Whereas this generic definition focuses on the planning of something (an enterprise) in view of achieving something, the Project Management Institute (PMI) (1996: 4) takes the definition a step further. The PMI (1996: 4) characterises projects as being performed by people, constrained by limited resources, and as being planned, executed, and controlled. The PMI (1996: 4) further explains that projects may involve a single person or many thousands; may require less than 100 hours to complete or more; may involve a single unit of one organisation or may cross organisational boundaries as in joint ventures. In section 3.3.5.1, two examples of engineering projects were discussed, namely, Thilmany’s (2005) description of the construction of a metal sculpture at the St Louis Zoo and Alisantoso et al.’s (2006) description of the design of a vacuum cleaner. Other examples of engineering projects include the development of a new product or service (such as a transport service like the Gautrain in South Africa); effecting a change in structure, staffing or style of an organisation; designing a new transportation vehicle; developing or acquiring a new or modified information system; and constructing a building or a facility.
In the discussion on flow of information in engineering work (section 3.3.5.4) and engineers’ work roles (section 3.3.7.1), reference was made to the effect of stages in engineering work on engineers’ information behaviour. From the literature it seems that engineering projects can also be subdivided into different project stages. The following discussion will address the possible effect of engineering project stages on the information behaviour of engineers.
Engineering projects have a starting point and an end. ECSA (2010) referred to these two stages as the inception stage and the close-out stage. The tasks in the project can be subdivided into different stages or phases. The studies conducted by Aurisicchio, Bracewell and Wallace (2010: 711), Du Preez (2008: 176-177) and Ellis and Haugan (1997: 386) reported on the division of projects into stages or phases. For example, Ellis and Haugan (1997: 389) identified five phases in their study. Each of these phases could be subdivided into a number of stages. Du Preez (2008) used the stages in an engineering project that were identified by the Engineering Council of South Africa (ECSA) (2010) to structure some of the data in her empirical study.
The results from Jagtap and Johnson’s (2010: 2452) study suggest that the type of information accessed depends on the stage of the design process. This could be due to the fact that engineers need to complete different tasks during the different stages of an engineering project. Research findings that confirm this notion include the studies by Du Preez (2008), Ellis and Haugan (1997), Freund et al. (2005), and Montesi and Navarrete (2008). According to the findings from Ellis and Haugan’s (1997: 401-402) and Montesi and Navarrete’s (2008: 1422) studies, the tasks for the initial stages (the critical design stages) of engineering projects require information from various sources of information. These include both formal and informal sources of information. Du Preez (2008: 321-322) and Freund et al. (2005: 16) reported similar findings, namely that the different project stages can be associated with different patterns of information use. They found that the initial stages of an engineering project involved more information seeking and engineers did more background reading. Jagtap and Johnson (2010: 2451) also reported on this phenomenon. The redesign engineers in their study accessed a considerable amount of in-service information during what they named the clarification stages of the project.
Two reasons are offered in the literature for why the initial stages in a project have an effect on engineers’ information behaviour:
• tasks requiring completion in the early stages of a project are characterised by greater uncertainty (Lowe, McMahon & Culley 2004: 417)
• engineers need to explore new products and technologies that could be useful in their designs during the initial stages of the project (Hirsh & Dinkelacker 2004: 809).
In South Africa, CESA (2003b) and ECSA (2010) provided some guidelines on the tasks engineers have to complete during each stage of an engineering project. A study of the suggested tasks proposed by ECSA for each project stage shows that the tasks in an engineering project become more directly related to the production or construction of a specific engineering object or facility as the project progresses. The effect of these stage-related tasks on engineers’ information behaviour is reported on by Du Preez (2008: 320-321) and Freund et al. (2005). They observed that the engineers’ information behaviour patterns during the project stages, following the initial stages, are focused on more detailed and procedural information. During the final project stages the engineers were more involved with project management tasks. The information that engineers required during these final stages of a project was derived from the project itself.
Certain elements in an engineering project seem to shape engineers’ information behaviour. These include aspects such as the duration of the project, the project stage and the nature of the project. Further aspects that need to be considered relate to the nature of the project. These include considerations of whether the project is focused on developing a new product or whether it is about effecting changes to an existing structure, or product.

READ The Central Topic - Service Interface Descriptions (APIs)

Practice and work environment

Sheppard, Colby, Macatangay and Sullivan (2006: 435) described engineering practice as the complex, thoughtful and intentional integrations of a problem-solving process and specialised knowledge to a meaningful end. According to Aurisicchio et al. (2010: 711), a work context, in this case an engineering practice, can be described “through the environment in which information seekers [e.g. engineers] work, their work roles [e.g. as consulting engineers], the project type, the stage of the project life cycle and the task or activity type”. This description of work practices is endorsed by Veshosky (1998: 58) when he stated that engineering is context specific.

CHAPTER 1 GENERAL INTRODUCTION.
1.1 INTRODUCTION.
1.2 BACKGROUND
1.3 RESEARCH PROBLEM
1.4 LITERATURE REVIEW.
1.5 IMPORTANCE OF THE STUDY
1.6 METHODOLOGY.
1.7 KEY CONCEPTS
CHAPTER 2 CONCEPTUALISING INFORMATION BEHAVIOUR: A LITERATURE REVIEW.
2.1 INTRODUCTION
2.2 BACKGROUND
2.3 DEFINING INFORMATION BEHAVIOUR
2.4 CONSIDERING KEY COMPONENTS FOR AN OPERATIONAL DEFINITION OF NFORMATION BEHAVIOUR
2.5 OPERATIONAL DEFINITION OF INFORMATION BEHAVIOUR
2.6 CONCLUSION
CHAPTER 3 INFORMATION BEHAVIOUR IN ENGINEERING PRACTICES
3.1 INTRODUCTION
3.2 BACKGROUND.
3.3 ENGINEERING CONTEXT
3.6 ENGINEERS’ INFORMATION ACTIVITIE
3.7 THE MANIFESTATION OF INFORMATION BEHAVIOUR IN THE ENGINEERING CONTEXT.
3.8 CONCLUSION
CHAPTER 4 INFORMATION BEHAVIOUR OF CONSULTING ENGINEERS
4.1 INTRODUCTION.
4.2 BACKGROUND
4.3. CONSULTING INDUSTRY.
4.4 CONTEXT OF CONSULTING ENGINEERING
4.5 PERSONAL DIMENSION OF THE CONSULTING ENGINEER
4.6 CONSULTING ENGINEERS’ INFORMATION NEEDS
4.7 INFORMATION ACTIVITIES
4.8 MANIFESTATION OF CONSULTING ENGINEERS’ INFORMATION BEHAVIOUR .
4.9 CONCLUSION
CHAPTER 5. ENGINEERS’ COLLABORATIVE INFORMATION BEHAVIOUR
CHAPTER 6 RESEARCH METHODOLOGY.
CHAPTER 7 STORY OF ENGINEERING PROJECTS.
CHAPTER 8 REPORTING ON CONSULTING ENGINEERS’ INFORMATION BEHAVIOUR
CHAPTER 9 ONCLUSIONS, LIMITATIONS AND RECOMMENDATIONS
LIST OF REFERENCES
APPENDIX A
APPENDIX B
PERSONAL INFORMATION