IT Is All Well and Good, But What About the Actual Work?

Of course we focus on the user’s needs! We carefully consider what kind of end-users might operate our system, and we also come to grips with them by preparing user narratives. But don’t expect a software vendor to describe current conditions. Nobody is ever willing to pay for that!

My thesis examines the consequences for good practice and for describing the work of end-users when developing software and procuring and deploying systems, and the reason for these consequences, bearing in mind that both suppliers and purchasers of information systems seem to think that it is enough to know what users will do on their computers.

And then it comes as a major revelation to discover that end-users also work collectively and individually without computer mediation, and that all of this other work simply fails to figure in the user scenarios. 

They should appreciate how and why their software fits into the work activity system as a whole.

All software developers aim to provide a tool for future productive use, and so they should also know and understand the envisaged benefits of their software. They should appreciate how and why their software fits into the work activity system as a whole. More meaningful still is to view the software as part of an overall information system that delivers required working information to the right point at the right time and in the right format.

Even though the user-centred approach is fashionable, many system vendors consider it too one-dimensional. Being user-centred has nothing to do with user profiling. It ought to be about outreach to the customer, participation, description and appreciation of work activities, asking about overall workflows, the kind of information system is in use, and aspects that require software development. One possibility to achieve understanding when accessing to the customer is to seek permission to take pictures and show them to other developers.

Of course we do discuss architecture, but even this often tends to focus on technical compatibilities between hardware and software.

Software development requires the customer to provide a great deal of detail about inputs and outputs, including things like input field lengths and database design, so it’s no wonder that the idea of appreciating the work activity as a whole has gained so little attention. Of course we do discuss architecture, but even this often tends to focus on technical compatibilities between hardware and software.

We are familiar with the idea that high standard production also creates a high quality product, and so we have integrated inspections and project management. Creating software that works is already an inherently challenging undertaking, and this is amplified still further when we are creating the product for a diversified network of activities.

Obviously we discuss the future context of the software and its users, but current development methods seldom pay much real attention to these aspects. Some good ways of understanding context were actually developed back in the 1970s, so it’s appropriate to ask why we aren’t using them. Everything nowadays has to flow rapidly and productively. Want to understand why maintenance costs are so much higher than the cost of producing the original software? Then tell us where to find the customer who is willing to pay for software development as part of an information system supporting work activity system. Where is the software house that will convert “user-orientation” into an appreciation of overall activities and workflow?

My thesis demonstrates that information system projects can take care of workflows. Our Activity-Driven Information System Development (ISD) model essentially seeks simultaneous monitoring and common diagram for modelling of the work and of the information system that it requires, thereby enabling a joint overview of their developmental requirements. The modelling method allows both employees and software developers to comment on the diagrams, ideally in partnership. The alternative is to press on with technology-driven development and argue that the activity will only take shape when the software has first been installed.

More information on Ms. Pentikäinen's research: Pentikäinen M (2014). Co-Development of Work and Information Systems - An Analysis of the Construction of the Activity-Driven ISD Methodology in 2001–2013. Publications of the University of Eastern Finland. Dissertations in Forestry and Natural Sciences, no 153. Kuopio, Finland: University of Eastern Finland. Available online at

The research team website may be viewed online at