Those individuals familiar with working on complex software development projects will know managing and delivering such projects is a complicated undertaking and a stressful activity. Whilst developers and managers have a huge tool kit of methods and methodologies, many projects still end-up being challenged or written off.
A feeling of déjà vu
If UK media and press reports are anything to go by there is some evidence to suggest that the failure rate associated with software development projects has somewhat declined in the last decade.
However, there is also proof (see ‘further reading’) that what we have learned (known-knowns) has had little impact on reducing failure rates within the wider public and private sector project community and, consequently, we still have big gaps in our knowledge (those known-unknowns).
Revealing why this may be the case, is, in itself, a tangled web of complexity. Research by McManus, in 2011, identified a lack of stakeholder engagement as a major issue for many sponsors and users, especially in public sector projects such as the (failed) government-sponsored National Programme for IT (NPfit), which was abandoned (in 2012) at a cost of £10 billion to the British Taxpayer.
Common sense would dictate that including stakeholders in the project would be of practical value and beneficial to all. Consider the following extract from the UK government’s Public Accounts Committee: ‘This saga (NPfit) is one of the worst and most expensive fiascos in the history of public sector projects.’
The real meaning, of the above message is one of mis-direction and trust. All projects, to some extent, are tied to the sponsor’s commercial interests and confidentiality clauses. These invariably get in the way of developing good relationships and trust. Trust between sponsors (purchasers) and providers (the project team) is almost certainly the biggest obstacle to delivering complex projects.
Research into failed projects (See further reading, 2008) reveals that one of the biggest obstacles to challenged projects was ‘attitude of mind’, that is the absence of trust and obsolete thinking, which goes on in project teams, e.g. the development process is inefficient, and therefore unable to compete with the efficiency of alternative projects (so, we need a strategy to ‘kick this project into the long grass’ and walk away, without paying too much in compensation).
A question of complexity and choice
Over the years, several studies have pointed to the importance of leadership in delivering successful projects (John McManus, Leadership: Project and Human Capital Management, 2006, Elsevier Publishing, UK). Projects, by definition, need management, but, more importantly, they require leadership. Project managers do not always have the leadership qualities to see projects through to a satisfactory conclusion.
Although opinions differ, project managers need skills which are more akin to modern day diplomats. Such skills include harnessing talent, and dealing with others in a positive, sensitive, and tactful way. A point worth noting is the appointment of a particular project manager is generally a response to someone’s problem, so we should always be aware of whose problem it is.
Inherent in all commercial projects are considerable risks to realising future net benefits (or pay-offs which enable the organisation to justify its activities in terms of overall business benefits). It’s important to bear in mind that there’s no such thing as a ‘generic project’ or flawless ‘methodology’, independent of the purposes of those who architect and design it.
The decision to sponsor one project, rather than another, is made from the perspective of someone’s interest [usually the sponsor]. Consequences into failed projects (Further reading, 2011) points to self-interest as being both a positive and negative motivational influence to delivering successful project outcomes.
Historically, large software projects are doomed to failure. The complication of software development makes them vulnerable to ongoing technical change. This is partly because projects are vulnerable to the whims of sponsors and, as such, require intensive due-diligence and control throughout the development stages, which increases the time and cost effort, which may not be factored in the cost.
Complex projects, typically, have a greater chance of success when supported by the organisation’s chief executive officer (CEO). However, even when this support is forthcoming, the project may still fail or overrun the initial budget and timescales.
Shaped by experience
An argument about differences between theory and practice points to the concept of known-knowns. The risk, uncertainty, and variability in complex projects [known-knowns] imply that technical and physical designs are not the primary determinant of success.
Technical design accounts for between 27 - 34 per cent of projects which fail (Further reading, 2004). This research highlighted the difficulties in translation from logical to physical design and the use of theoretical methodologies, which focused on structures and relationships between engineered components (and were difficult to convey to lay-users and managers).
Few organisations have access to unlimited resources; many firms have to get by on what they have within their collective resource pools. The premise here is that a firm’s resources and capabilities can vary significantly across projects. Lack of investment in training and development, poor mentoring and long hours of work act as a conduit for increased stress levels and, in some cases, staff burn-out.
High turnover of software engineers and development staff within projects is not uncommon and inevitably leads to poor productivity and poor outcomes of delivery. Issues concerned with situational awareness e.g. how well project managers understand the motivational needs of their team members is crucial to the harmony and well-being of their team.
As an example, performance targets were frequently cited as being counterproductive to staff well-being and generally initiated for the wrong reasons (Further reading, 2011 and 2013).
Although there is less controversy or ambiguity in terms of what project management means, it is still a complex mix of interlocking interrelationships, strategic alliances, and contracting networks that link virtually every one with every would-be project advisor or consultant.
Poor advice and fine rhetoric are endemic within the ranks of middle and senior management. Whilst accepting that no individual has a monopoly on knowledge, and it is sometimes prudent to seek professional advice, it is the quality of the advice that counts. Co-opting consultants onto any project without specialist domain knowledge can be dangerous. Studies into project risk (known-unknowns) concluded that inappropriate advice from third-party advisors tended to exacerbate challenged projects towards failure.
Third party advisors tend to have limited ownership and will normally be paid whether the project succeeds or fails. For example, a major aspect of public sector projects is the way the contract is constructed. Many contracts have staged deliverables of varying time durations and cost, with little or no flexibility to amend when events take a turn for the worst.
In such circumstances, ‘time’ can be a dangerous bed-fellow making projects vulnerable to disruption, which, if not managed will plunge the project into a contractual quagmire. A supplier prohibiting contractual changes vastly increases the chances of delivering a successful project.
In conclusion, the particular project that reaches maturity is always the one that goes to support the custodians of authority.
Further reading
- McManus, 2001, Risk in software development projects
- McManus & Wood-Harper, 2004, Application of risk planning in UK firms
- McManus & Wood-Harper, 2008, European study into project failure
- McManus, 2011, IT Projects do we still have a problem?
- McManus & Webley, 2013, Stakeholder salience does it matter?
