Project management has become a universal discipline. The fundamental knowledge of the principles and practices has become embodied in a mature subject of study.
It is widely taught and available to those who need a qualification to practice and it is supported by professional qualifications such as PRINCE2 or the Project Management Institute. The irony is that, despite this trend, projects still, all too frequently, overrun in time and and/ or cost and often fail to live up to expectations.
Simply stated, project management is concerned with the fundamental question of how to manage effectively within constraints: at the primary level of time, financial and physical resources. These factors are in finite supply and therefore careful planning, analysis, requirements specification, choice and decision-making is required to identify, design and execute courses of action.
Project management has developed very effective techniques and tools of practical application in order to facilitate the achievement of goals and outcomes under constraint. But in order to be fully effective, project management has to be grounded in a strategic context that identifies what has to be done, who is to be involved and how it is to be done.
It is clear that managing a project that has specific goal(s) is quite different from day-to-day operations management. The increasing rate of change and global competition means that ‘steady state’ effectively no longer exists for many businesses. Thus managers are increasingly operating through a series of strategic thrusts, with each sub-project as part of an evolving probabilistic business strategy.
Every project begins with an essentially human goal, which to be realised has to go through a formal engineered process- a technical system. The outcomes of the process are then re-translated back into the real world of people, ideas and actions- a social and cultural system.
With relatively simple transactional processes the techniques of business and systems analysis are well developed. In the 20th century the business requirements were usually readily defined and relatively low in complexity, and the IT solutions were equally relatively simple.
The scale of projects is a major factor in determining outcome. Where requirements are fully understood, the level of innovation is limited, the environment and circumstances are known, and organisational and stakeholder settings are largely stable, successful delivery on outcomes, time and budget may follow.
However, this scenario is increasingly less likely as scale and dynamic environments generate uncertainty and instability: hence the importance of initial appraisals (SWOT, PESTEL) and then more searching and ongoing critical strategic analysis. Investment of effort in appraisal, planning, modelling, risk analysis and sustainability are likely to encourage higher levels of return and greater operational resilience in the management of project processes.
The resolution of external conditions is the key to creating internal resilience. Data gathering, intelligence analysis, information and knowledge management practices tailored to needs are vital.
And perhaps most importantly the two-way communication strategies not just to manage flows but also to build communities of practice and a sense of polity (common consent and grounded understanding) around which the ‘soft’ processes can be managed and local ownership of implementation achieved. Project ownership, not only within the project team but at every level of the business that will be affected, is vital.
Prototyping and agile development approaches have enabled us to evolve an understanding of requirements and the resultant solutions, but the traditional tools and techniques have become less useful when the business requirements are complex and subject to change. The resultant system is often a hybrid human-computer system; e.g. I want an ICT system to help my doctor diagnose, not turn him into a robot.
We have been used to dealing with project delivery risk; indeed Barry Boehm’s 1986 spiral model had risk management at its core. We now have to deal with concurrent business risk: the business does not stand still while a long-term ICT strategy is rolled out.
The socio-technical reality is brought into ever sharper focus and there are ever-closer relationships between customers, stakeholders, managements, project clients and project teams and all those who have an interest in infrastructure and process. Behaviour, interaction, communication, context, requirements and general dynamics dominate both project and business environments.
Together these create a ‘knowledge space’, which becomes an essential part of the context and content of project management. Perhaps the best aspect of PRINCE2 is the ‘handshake’ between the business that will deliver the benefits and the IT function that will enable them.
In this era of concurrent business and ICT risk, it is important that both ICT and the business take a manageable step out of the known risk areas together to explore the uncertainties and gain mutual learning and understanding. In this flux ‘we are all project managers now’.
Traditional project management has emphasised hard skills, tools and techniques. These are still needed but must be supplemented by organisational development, social and cultural awareness skills. The predominant driver for ICT projects up to now has been organisational efficiency: fewer clerks or more sales for the same workforce. It is now faced with projects to support greater organisational effectiveness, but in an environment of almost institutional change.
Not only must a much wider view of risk be taken, but systems must be developed more incrementally and adjusted as the organisation responds to global competition. Project managers must mediate the business needs with the ICT delivery and be far more aware of the business and organisational dimensions.
For this to be a reality, the strategic alignment of business strategy and an enabling ICT architecture to encompass strategic possibilities is vital and the implications and limitations of that architecture (the boundaries of the pitch we are playing on) must be fully understood by the business.
In this environment the business case will be regularly revisited; stage reviews will be as much about the current business understanding as the ICT delivery, and frequent implementations will be used as vehicles for real mutual learning.
