In projects over £10 million, the understatement of effort and variable cost is a common feature of IT project failure in which budget overruns do not generally reflect the true cost or risk of the project. Dr John McManus examines what qualities a project manager needs for success.

If we consider the inherent complexity of project risk associated with project delivery, it is not too surprising that only one in eight projects will be delivered to the original time, cost and requirements schedule. The culture of many organisations engaged in software projects is often such that leadership, stakeholder and risk management issues are not factored into projects early on and, in many instances, cannot formally be written down for political reasons and are rarely discussed openly with the customer or project board meetings.

What are the issues?

Although our understanding of the importance of project success and failure has increased, the underlying reasons for failure still remain an issue and a point of contention for those involved in the specification and delivery of software projects.

Much of the research into software development and project delivery has been conducted from the premise of project and technical processes linked to the schedule, cost and quality requirements model, which often pits customer against provider organisations. The author believes developing an alternative model for project management founded on 'leadership', 'stakeholder' and 'risk' management will lead to a better understanding of the management issues that often contribute to the success or failure of projects.

An examination of the literature underlying project success and failure points to the indisputable fact that few projects fail for technical reasons. But what about management processes? Management principles are implicit in the body of knowledge on leadership, stakeholder and risk management and have been discussed on many occasions by the BCS project management community.

Although processes clearly exist for project management, for example planning, budgeting, configuration management, etc., these processes alone are far from enough to cover the complexity and human aspects of many large and unprecedented complex software development projects subject to multiple stakeholders, resource and ethical constraints.

The basis for developing and evolving future methodologies will require an extension of the discipline that is project management to provide capabilities and understanding in the interrelationships between leadership, stakeholder and risk management. The major challenge is to extend our understanding and capabilities within these domains so that it is possible to address more ambitious, unprecedented project development. This is often required for competitiveness or to enhance the quality of products and services.

The argument

Project management is still characterised by PRINCE2-type methodologies and, although some of the broader issues associated with project management have led to a wider understanding of the softer issues associated with projects, such as people capability, the broad forms of leadership and stakeholder management have yet to be embraced with any real enthusiasm. Although individual organisations can achieve improvements in capability, the effectiveness of an independent approach is limited by the need to compete for business on price. 

Project organisational capabilities have the capacity to consistently deploy an integrated set of resources (including specialised competencies) to attain specific functional and strategic objectives. 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. They 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 of, failure. A highly capable organisation is one that consistently delivers superior organisational performance and productivity growth. The point 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.

The gap

Debates and discussions within the BCS have centered on improving hard processes, such as better technical design, improved requirements engineering, better reuse, better testing etc. Based on the author's research2, projects that fail (or are challenged) do so because of managerial and organisational issues related to poor decision-making, poor risk management, poor leadership and lack of stakeholder involvement. The management of projects is not an isolated activity; it must be an all-inclusive effort that embraces shared leadership, decision-making and risk.

Published research by the author into stakeholder involvement, into project failure, generally signifies a gap between some existing situation and a desired situation by members of a particular stakeholder group - stakeholders being defined as 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. It is suggested that stakeholder groups often face significant challenges and problems in ethical, moral judgements.

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 project with the stakeholder's current concerns to legitimise commitment. These judgements often lead to escalation where stakeholders are pitted against each other. The point about escalation is that support for a project can still continue even in the face of major constraints.

Major stakeholders in a project may be reluctant to withdraw support because of the heavy investment in personnel and other resources devoted to a project. That said, ongoing commitment on the part of project stakeholders or participants is a necessary determinant of the success of a project. In managing stakeholder relationships the need for commitment, leadership, communication and control cannot be emphasised enough.

Those responsible for initiating projects within organisations still look to capital employed as a way of prioritising projects and the resource (and division of labour) to deliver them. In many respects this reinforces the value of technical skills above the softer skills many aspiring project managers need and makes it difficult for project managers to get out of the technology ghettos many find themselves in.

In the field of project management, the project manager must have experience in managing and communicating effectively with a wide variety of stakeholders. Key competencies for project managers are leadership, change management, communication, negotiating, team building, decision-making and problem-solving.

An ability to lead is clearly one of the most important competencies a project manager must have. A lack of leadership qualities can readily result in the failure of projects. As such, the project manager must be able to set goals and objectives. The manager must then be able to identify and implement the steps necessary to achieve them. Working closely with various stakeholder groups, the project manager must have the skills necessary to translate expectations into a practical vision for the project.

Reducing project failure

This checklist contains the tasks and activities of project managers during the course of a software project.
 
Pre-development processes

  • Identify ideas or needs.
  • Formulate potential approaches.
  • Conduct feasibility studies.
  • Refine and finalise the idea or need.

Project initiation

  • Identify life cycle model.
  • Select a project model.
  • Map the activities to the life cycle model.
  • Allocate project information.
  • Establish the project environment.
  • Provide standards and guidelines.
  • Plan project management.
  • Plan documentation.
  • Plan training for all software staff.
  • Define the responsibilities in the project.
  • Define the key positions and backups for every key position of the project.
  • Inform the personnel associated with the project about the project.

Project monitoring and control

  • Analyse risks.
  • Perform contingency planning.
  • Manage the project according to plan.
  • Implement problem reporting methods.
  • Initiate acceptance/release of milestones/phases.
  • Create regular status reports.
  • Inform the customer about the progress of the project.
  • Collect and analyse metric data.

Software quality management

  • Plan software quality management.
  • Define metrics.
  • Manage software quality.
  • Identify quality improvement needs.

Configuration management

  • Plan configuration management.
  • Develop configuration identification.
  • Perform configuration control.
  • Perform status accounting.

References

  1. For example, 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, p431.
  2. McManus J (2007) Stand and deliver. ITNOW, BCS, November, 8-9. 
    McManus J, Wood-Harper (2007) Understanding the sources of information systems project failure, Management Services J, Autumn, 38-43.
    McManus J (2007) Lead by example. BCS Project Management, July, 1-5.
    McManus J (2007) Developing a risk assessment process. ICFAI University Press, May, 38-43.
    McManus J (2007) Success is at stake. BCS Project Management, April 1-5.

About the author

Dr John McManus MBCS is writer, teacher and consultant in global strategy, software innovation and project leadership. Dr McManus is Rushmore Professor in Management Sciences at the Rushmore Institute, USA. Dr McManus can be contacted through the BCS Elite Group.