18 September 2007

Technology and Work


Perrow's technology classification is a decades old view of how technology and work inter-relate. In this context technology is not just computer related technology; its everything from the basic tools of pen and paper to defined business systems.

I think this model is useful in two ways for IT project teams.

1. The user environment
The first is that it helps analysts understand the type of work the client undertakes, and so it helps when defining requirements for new technology. For example, if you are dealing with lawyers you need to develop a different CRM system to the one you would build for a phone company's call centre.

It's also interesting to think about how this framework applies to models like ISO9000 and CMMI. It's definitely useful when considering your users' interaction with your system. Do you want to build a system that forces them to follow your process, or build a system that enables professionals to tackle a variety of unanticipated problems in a number of ways?

2. The software development process
The second is it helps understand the development methodology that is most appropriate to your project. For instance in a well defined problem place, but in a complex environment an engineering approach might be best, while in a poorly defined problem area, but in a relatively simple environment a craft approach may be better.

This gives an idea of why different people see Agile or Waterfall methods as particularly poor or effective and never seem to agree with each other. It aligns with the experience many of us have where large enterprise projects just can't work with Agile, or where a Waterfall approach just locks you into a bad solution.

You can read more about this model by Googling it, or better, by using Google scholar. Here is an article to start you off on your search.

3 comments:

  1. In my experience both models have merit (although I have to admit to being more in favour of agile methodologies) but in my experience, most organisations don't full commit to either and hence fail whatever their nominated methodology.

    ReplyDelete
  2. My view on models is that motivated, talented people deliver. THe profess they use can be a constraint or a help, depending on the environment.

    I think this model gives some insight into what model suits what environment. No doubt there is a definitive answer somewhere.

    ReplyDelete
  3. Indeed, SDLCs and methodologies are not finely-tuned and OOTB tools. They are guidelines. They are abstractions. I really believe the key is in realizing that adoption of *some* techniques and ideas within an SDLC or methodology is the only way to go. Although I am sure there are shops the function perfectly with a perfect Fountain Model, I think those shops are the exception instead of the rule.

    ReplyDelete

Search This Blog