Showing posts with label formal systems model. Show all posts
Showing posts with label formal systems model. Show all posts

Monday, 16 February 2009

Boundary objects

Supervisor #2 last week talked about boundary objects, which are things that are shared between different groups of people to help make the transition of meaning between groups that don't talk or otherwise share meaning and language. Susan Leigh Star first introduced the idea in 1989. Supervisor asked me what boundary objects I'd noticed in the case studies. Someone had mentioned screen mock-ups. I have a photo of people working on a live incident where two guys are looking at screens and another has an incident form. The incident form is a boundary object and the various role players were working from it.

Someone in another team took the photo - thus creating another boundary object that helps understanding the process of dealing with a live incident.

Other boundary objects are the project opening and closing documents, which were shared between higher level managers both users and IS developers.

So boundary objects:
  • screen mock ups
  • incident log
  • photo
  • project documentation


Star, S. L. and Griesemer, J. R. (1989) 'Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39', Social Studies of Science (Sage), 19 (3), pp. 387-420. 1092

Friday, 16 May 2008

Formal Systems Paradigm

I'm convinced that what my supervisor #1 has drawn matches the formal systems paradigm (FSP) [1].

A system has four aspects to it:
  1. a purpose
  2. an interest from someone who perceives it as a system
  3. components that interact and do something
  4. if any one component is removed or added then the system behaves in a different way
The FSP has components:
  • a purpose
  • sub-systems that are systems themselves and do things
  • a decision making process
  • a performance management process
  • an environment
  • a boundary
What sup#1 has drawn includes
  • a decision-making system that consists of client civil servants and politicians (possibly as a separate system),
  • a consultant system again with possible subsystems
  • a system for effective consultancy with notes against it about how consultants add value, how it's measured, and contribution to project - so it must be a performance management system
Then she's drawn a boundary round these three components and put stuff in the environment, like:
  • other projects or across projects or programmes
  • nature of projects in public sector
  • life cycle
  • nature of consultant engagement
  • more effective project outcomes influenced by market shift and clear outcomes.
So where do I go with this? She doesn't like systems, so I can't go there without explaining a lot. However, I think I could write up each of the components in turn, citing the literature to arrive at a similar diagram. Then each component of the diagram brings aspects of my research question. Erm.

What is my research question?

How do clients engage with consultants in order to ensure effectiveness of the consultancy contribution to the overall project?

Fortune, J., Peters, G. and NetLibrary Inc. (1995) Learning from failure: the systems approach, Wiley, Chichester ; New York. 773