MIS40640 – Managing Technology & Change: Cultural & Political Perspectives – Managing the IS design & development process

Readings of the week:

Presentation:

Managing the IS design & development process

Minutes of the Class:

Week 7 (continuation)

What is challenging in systems development?

Curtis Article is 30 years old and a lot of the same problems still exist.

“writing code isn’t the problem, its understanding the problem that’s the problem”

Fluctuating and conflicting requirements

Fluctuating and conflicting requirements are an on-going, enduring problem in software development.

Why does this issue occur?

Conflict-Organisations are pluralistic- Different groups have different needs and have different perceptions of what a system should do therefore hard to find common ground.
Users not knowing what they want – we should abandon perception what the requirements are “out there”; instead requirements should be co-constructed through an on-going dialogue. Users often don’t have an understanding of the systems and underlying processes that they execute every day. Limited understanding of processes and practices that system is meant to support is a most common failure of information systems projects. To fix this issue process observation can be used. An example of an air traffic control project in London was discussed in class. The design team wanted to figure out how the controllers worked and figure out how the users interfaced with the system. To understand how air traffic control worked there was a ask analysis done. This is a detailed analysis of what you do under certain conditions. Done via interviews with controllers. The prototypes was that they didn’t quite fit with what was needed which in turn created issues. The air traffic controllers’ understanding of what they did was not at the level required to produce a system. On the job analysis where every single thing was observed was needed. As an example: air traffic controllers were walking over to the rack with the piece of paper with flight details but observing what the others were doing: (hard to analyse unless you witness it first hand).
Sub conscious practices: Practical consciousness (parts of our life that we perform but often are not aware of or can’t articulate) and discursive consciousness (parts of our life that we are aware of and that we can articulate). In requirements analysis it’s both developers and users that learn in the process.
If we want to develop systems to support work practices, how we can make sure that the system that we’re developing will support the practices and not get in the way?
We need to see software development process as a learning activity.
Politics: bidding for software projects, development estimates etc. A lot of guess work is involved in specifying requirements for any complex system. It is difficult to estimate until there is a full engagement with the requirements. There is a ritualistic element to the estimating and planning process.
Getting to a stage in software development with no conflicting requirements is a dream that is unlikely to come true.

Communication and co-ordination breakdowns

Source of these breakdowns include large number of groups, geographic separation, cultural differences, outsourcing, off-shoring etc.
Documentation was often seen on a project as the main source of communication. Incomplete documentation often created issues. The bigger the project, the greater the volume of verbal communication (Minzberg: Fallacy advising that complex issues can be captured in a document). It is dangerous for the project when there is no continuity between project teams (i.e. analysis and design).
Not having a single point of contact for the customer can be an issue. Communication practices are the most important aspect of effective communications.

Conclusion:

Large development projects should be treated as a communication process and as a learning process.
Requirements analysis should continue throughout the whole lifecycle of the project. Tools and practices should focus on:
Spreading the domain knowledge more evenly across the team to avoid reliance on software gurus – i.e. refactoring, business embodiment.
Practices that support on-going change
Practices that support communication within the team
Personal attributes and human relations activities provide the greatest opportunity for improving software development process.

Key aspects to successful software projects often come from:

Negotiating with the customer
Resolving conflicting requirements
Mediating between conflicting groups
These are rarely recognized as contributing factors.

Week 8

Responses to challenges- Most common is around methodology. To what extent does methodology cause/explain these challenges?

Worshipping of methods and seeing them as a silver bullet to all software development issues but it is not advised and can be seen as dangerous.

Fitzgerald’s paper is a nice distillation of the pro and anti methodology argument. Ones of the key points discussed is how organisations use their project method as an argument to win business from those without a recognized system development process.

Methodologies are seen as a systematic ways of breaking down complex problems and making them easier to manage and control.
Methodologies produce various kinds of visibilities (e.g. milestones, scope, cost tracking). This in turn contributes to reducing risk
Standardisation: advantages to a standard process make it easier for people to work together on the project
Benefits of linear/phased approach: specialisation can be used in a project (using most valuable and most expensive people only during certain project phases).
Pressures by particular agencies to enforce particular way of developing software (e.g.
CMMI, ISO)
Is increasing quality about systematizing the process?
Danger associated with radial systemisation: we need to consider how methodologies are used in practice? The key is to understand how methodology is used in practice.
How should you know which practiced to use and avoid in a particular project? – It takes skill and experience to select the aspects correctly.
Key to project’s success are the people that will work on a project and their experience. Expertise always supersedes method. Methodology often provides a sense of safety due to the fact that it provides systemisation. In software development people are the most important factor (their ability to use method smartly).
If you become overly reliant on a few good people then you’re in trouble. Success comes from cultivating successful practices in an organisation.
Why is it that we assume that complex processes can be systematised in methodologies?
Danger is that it is often assumed that methodology can be taken off the shelf and introduced to a good software project.

Case against systems development methodology:

Goal displacement – methodologies used appropriately may be very beneficial but we should always focus on methodologies in use.
There are thousands of different methodologies – what do we mean when we talk about methodology?
A lot of judgment is involved in how to use methodology. This makes a difference between a novice and an expert. Be careful of falling into the trap that the main way of making software development better is through systematizing the process!
Methodology addresses the need for security and calming anxiety (David Wastell). Danger: doing the process right becomes the end in itself. Organizational rituals are important in reducing anxiety. Methodologies can give sense of security that success will be achieved. Anxiety is related to personal issues as well as organizational & political issues. Bureaucracy can be a method to hide behind and reduce anxiety. Reason: Too rigid – Too much QA- Trust in the methodology and it will work out in the end is the incorrect way to think.
Organizations as a ‘psychic prison’ – Huge danger of using software development technologies just to calm anxiety. Consultants charge a lot of money for reducing anxiety.