A great many of them are still the traditional end-users - employees at desks - but in this era of change many of the stakeholders that IT has to take into account are not even inside the organisation.
Since systems now reach beyond the boundaries of the organisation, the originators of systems have to take into account the reactions of people very different from its traditional constituency.
"Traditionally, IT built the system, installed it and made users adapt to it - IT controlled their behaviour," says Elvin. But with stakeholders outside the organisation IT cannot expect to control their behaviour, he says.
Even within the company there are more complex layers of stakeholders with an interest in the output of IT. Globalisation means that companies now have stakeholders in different countries and timezones, with different languages and cultures.
Systems tend to be more cross-functional, involving different departments, and stakeholders change through time as systems evolve and business itself changes, so that the target stakeholders could be radically different from when the project was first started.
By virtue of the money tied up in their development, IT investments such as enterprise resource planning and customer relationship management systems will create a breed of influential stakeholders - the City analysts who cast unforgiving eyes on firms caught up in unsuccessful implementations.
Given the greater complexity of the delivery environment, what should directors do? Elvin suggests:
1. Appreciate that stakeholder management is an essential aspect of IT and project management - many development methodologies do not yet take sufficient account of the role and importance of stakeholders or give much guidance on stakeholder management
2. Analyse who project stakeholders are. Test the cultural feasibility of the change that the IT system will impose upon them - what will their reaction imply for the success of the design and implementation of the system?
3. Understand the context of the change that the project will bring about. Ask questions such as, "Why are we doing it; what kind of change is involved; how ready as an organisation are we to accommodate such changes?
After the risk and stakeholder analyses the benefits analysis must follow, says Elvin, mapped against the stakeholders. Who wants the benefits and who is driving those benefits?
Do not assume that those risks and benefits - or stakeholders' reaction - will remain static during development and delivery.
Nor should IT assume that all stakeholders have equal commitment or consensus about the risks and benefits. But if conflict between stakeholders is identified it should not be left to IT to sort out, says Elvin. "If conflict is found at a seriously fundamental level, then it has to be escalated to the senior sponsors," he says.
As ever with IT project management, it is crucial to remember that however technically brilliant a system, however smooth its implementation, if it isn't what stakeholders want, it won't be seen as a success.
Roger Elvin was speaking at a recent IT Director's Forum run by the Cranfield School of Management.
Details from Maggie Bridge at firstname.lastname@example.org