If we consider the inherent complexity of risk associated with software development and stakeholder issues associated with software projects, it is not too surprising that few projects will be delivered to the original business specification. The culture of software development is often such that user, stakeholder and risk management issues are not factored into development projects early on in the development cycle.
Even when known there are instances when risk issues cannot formally be written down or discussed with the user for political reasons although they may be discussed at length behind closed doors. Such nondisclosure adds to the burden of the SDM and places them at odds with both the customer and their internal management.
Methodology and process
Despite attempts to make software development more rigorous, a considerable proportion of development effort results in systems that do not meet expectation and fail to meet user expectations. A predominant paradigm in project management is to view the development process as a three-way trade-off between time (business urgency), cost (budget) and quality (product functionality and capability).
Although our technical understanding of software development failure has increased, the underlying reasons still remain an issue and a point of contention for SDMs. A key issue for many SDMs is that too few organisations have the infrastructure, education, training or management discipline to bring software development projects to successful completion.
Development methodologies and processes clearly exist for constructing the software that is a major component of an information system. But these methodologies and processes alone are far from enough to cover the complexity and human aspects of many large and unprecedented information systems subject to multiple stakeholders, resource and ethical constraints.
The basis for developing and evolving information systems will ultimately require an extension of the discipline that is 'human factor management' to provide capabilities and understanding in the inter-relationships between leadership, stakeholder and risk management. The major challenge is to extend our understanding and capabilities within this domain so that it is possible to address more ambitious, unprecedented systems development.
Human factor management
Is 'human factor management' useful and critical to software development?
The first part of the question is perhaps easier to address as 'usefulness' is clearly addressable in principle, but the fact that it is rarely integrated with leadership, stakeholder and risk management continues to separate it from a unified software development framework. Based on the author's previous research, risk is in the main subjective, relative and situational rather than objective, absolute and universally recognisable.
For instance, usefulness is a highly subjective aspect of the decision-making process within stakeholder and risk management. Indeed the inclusion of leadership and stakeholder management within the risk management framework is a matter for practical investigation that has not been a primary focus of previous study for publications in software development.
Expectation failure and stakeholder management
Expectation failure within the software development process may be viewed as the inability of the process to meet a specific stakeholder group's expectations. System development failures signify a gap between some existing situation and a desired situation by members of a particular stakeholder group. In this context stakeholders are any group of people who share a pool of values that define the desirable features of an information system, and how they should be obtained.
My view is that stakeholder groups face significant challenges and problems in either ethical terms or in terms of morality. In the former case, a stakeholder's main concern is to mould the future to fit their interests. In the latter case, the main concern is to align the development process with the stakeholder's current concerns to legitimise commitment and gain control. This declaration places the SDM at the head of the process and emphases the nature of stakeholder and stakeholder influences, regardless of whether the relationship involves internal or external stakeholder groups.
Organisational capabilities comprise the capacity consistently required to deploy an integrated set of resources (including competencies such as leadership) to attain specific functional and strategic objectives. Software engineering capabilities are socially complex phenomena that accumulate over time through market and non-market activities and are embedded in the organising principles, routines and resources of the organisation. These tend to be idiosyncratic and firm-specific, and as a consequence cannot be easily replicated by competing organisations or by the same firm in different contexts.
Organisations that have strong capability1 are to some degree protected from poor delivery performance and recurring or expectation failure. A highly capable organisation is one that consistently delivers superior organisational performance and productivity growth. The point being made is that many organisations that have strong capability also encourage active involvement and tend to have higher than average leadership capability and levels of stakeholder engagement.
Emerging trends in management and leadership point to a future where technical skills will have less currency than those associated with leadership, stakeholder management and governance. A number of critical performance objectives such as customer satisfaction and retention are driving the way high-performance organisations train their managers to carry out directives in their jurisdiction.
This is not to negate the importance of technical skills and knowledge, but there is recognition that there is a greater need for skills in dealing with intra-personal and inter-personal issues, particularly with stakeholders and senior levels of management. SDMs who work for high-performance organisations often describe positive experiences based on freedom of choice, latitude and direction.
High-performance organisations often provide the emotional support so crucial to future leadership and development. SDMs who aspire to be leaders must cultivate their soft skills and emotional intelligence. Leadership and management literature suggest that the most important factor distinguishing effective from ineffective leaders is their understanding and use of emotional intelligence.
A leader's emotional intelligence includes their degree of self-awareness, ability to manage emotions and ability to engender self-motivation. Emotional intelligence also focuses on an individual's ability to relate well to others, be a mentor for other's emotional development, foster a motivating environment, and manage conflict effectively. One of the foundation skills for emotional intelligence is the skill of empathy.
In essence SDMs must be in tune with their emotional intelligence; they must also to some degree act and be social architects, who understand the interaction of organisational and behavioural variables, who can foster a climate of active participation and can minimise dysfunctional conflict inside or outside any development project.
In practice SDMs need to adopt verifying styles to suit the environment and situation they find themselves in - the line between technical manager and leader is forever being redefined. One attribute a leader must posses is that of seeing the bigger picture. Doing things right is not good enough; the SDM must do the right thing.
To some degree leadership is an improvised art in that many SDM operate in dynamic environments where the rules can change in days not weeks. In my experience, successful SDMs engender trust, are adaptable and are able to forge new collaborative relationships for themselves, their teams and their ever-shifting portfolio of stakeholders.
- A project staffed with uniformly very low-rated personnel on all capability and experience factors would require 11 times as much effort to complete the project as would a project team with the highest rating in all the above factors.
Boehm B (1981) Software Engineering Economics. Prentice Hall, Englewood Cliffs NJ.