Rethinking Communication

The fourth paper on our series for the PM World Journal on Project Management in the time of COVID, Rethinking Communication has been uploaded to the Mosaic website.

Organizations everywhere are struggling with the requirements of returning project planning and delivery to pre-COVID levels, which in turn creates a range of communication challenges. They need to prevail over the global threats of staff and material shortages, the demographic changes to the project workforce and the general reluctance of project teams members to resume full-time face-to-face modes of working. These are complex issues for organizations and may need courage to introduce innovative flexible work modes and to introduce new people strategies to acquire and retain project workers. It is a great opportunity for innovation and flexibility, and will require a measure of audacity from often conservative organizations. To achieve these ambitious goals, they must ensure that communication and people management strategies match any changes they plan to introduce, and even more important, to ensure adequate consultation with their people.

Download all three papers from: Project Management in the time of COVID

What is agile?

Over the last couple of months, I’ve seen many discussions around the concept of agile in project management where it seems no one was talking about the same thing……..  This set me thinking.

My conclusion is the Agile Manifesto sets out a philosophy not a methodology and change the term ‘software’ used in the manifesto to product (or output), it is a generally applicable philosophy.  Then there are various methodologies for implementing this philosophical approach. This distinction creates to totally different areas of discussion.  One is the validity of the philosophical ideas, the other the appropriateness of any given methodology in the circumstances of a particular project.

The underpinning philosophy driving the development of project management from the 1960s through to the 2000s was derived from scientific management, the core elements being:

1. The future is largely predictable and we can create reliable schedules and budgets for a project.
2. These plans can be used by management to control the work of the project.
3. Risk is important, and if you do enough work, you can parameterize the overall risk profile and allow appropriate contingencies based on the management’s risk appetite.
4. When things go wrong, someone is at fault.
5. The way to improve project outcomes is to do ‘project management better’.

Then the Agile Manifesto was published. It sees most elements of traditional project management as valuable, but places more emphasis on:

• Individuals and interactions,
• Working software products (fit for purpose),
• Customer collaboration,
• Responding to change.

These ideas are consistent with other innovations such as empowerment, self-managed teams, and stakeholder engagement which also emerged into prominence in the 2000s.

This ‘agile philosophy’ represents a paradigm shift in thinking from the older project management ideas that are built around predictability and ‘command and control’ to one focused on delivering value to the client by working with people.

A third concept, also from the 2000s, is complexity which emphasizes the impossibility of predicting future outcomes, the day-to-day actions of the project team build the future within an ever-changing environment.

My feeling is at this level most thinking project practitioners will be willing to agree agility and complexity are important elements in the successful management of projects.

Then you get to the methodologies.  Scrum is a methodology developed for use on soft projects (software development, and others). It emphasizes using the skills and capability of the project team to decide what to do next.  Lean construction also emphasizes using the skills and capability of the project team to decide what to do next. The difference between the two is the characteristics of the product places far more constraints on the work of the construction team, compared to the software team, and this is reflected in the methodology.   

Separating the discussions around approach (philosophy) between predictive, agile and/or complex is important for the evolution of project management as a concept. But this is a different discussion to the one about which of the methodologies is best for a particular project. In this respect the agile community are well ahead of the more traditional project communities.  Agile methodologies include Scrum, DA, Safe, XP, Kanban and several others. 

In the more traditional industries, we have a few concepts such as Lean Construction and BIM, but mostly continue to approach the management of projects in the same way as we did in the 1970s, 1980s, 1990s, etc.  And continue to see the same failure rates, and continue to blame people, or the lack of skills, or the lack of diligence in the planning……. Maybe there is a need for a reframing of the discussions.

The Origins of Schedule Management

Our peer-reviewed paper, ‘The origins of schedule management: the concepts used in planning, allocating, visualizing and managing time in a project’ has recently published in the ‘Frontiers of Engineering Management’ at: http://journal.hep.com.cn/fem/EN/2095-7513/current.shtml

This paper brings together a number of published articles and other research we’ve undertaken in the last decade or so to present a coherent view of the evolution of project scheduling in a format that can be used by other Academics.  It is also aimed at correcting many of the commonly held misconceptions around this topic.

The concepts used for project schedule management have very deep roots; getting the right people in the right place at the right time to accomplish an objective has been a major organizational challenge for at least 3000 years! In ancient times this process seems to have been based on the scheme of arrangements being contained in the leader’s mind and instructions communicated verbally. Modern approaches to solving the twin challenges of first thinking through the ‘plan’ and then communicating the plan to the people who need to do ‘the right work, at the right time, in the right place’ use sophisticated graphics, charts, diagrams, and computations, but the problem and challenges are the same.

This paper traces the development of the concepts most project managers take for granted including bar charts and critical path schedules from their origins (which are far earlier than most people think) through to the modern day. The first section of the paper looks at the development of concepts that allow the visualization of time and other data. The second looks at the shift from static representations to dynamic modelling through the emergence of computers, dynamic calculations and integrated data from the 1950s to the present time.

You can download an augmented version of the paper from: https://mosaicprojects.com.au/PDF_Papers/P202_The_Origins_of_Schedule_Management.pdf

The Evolution of Project Management

The publication of the PMBOK® Guide sixth edition at the beginning of September, and the decision last week by ISO committee TC258 to revise ISO standard 21500 should mark the end of an era in the development of project management. For most of the last 50 years the dominant view of project management associations has been that project management is a generally transferable skill. This has resulted in the view that ‘project management’ can be represented by a single ‘BoK’ (Body of Knowledge), a single ‘competency baseline’ and capability can be demonstrated by passing a single credential or certification. However, whilst the PM professional associations have advocated this view, the job market has always retained a focus on different industry experience – you don’t get an IT project manager’s job without IT experience.

As outlined above, from the emergence of ‘modern project management’ in the 1960s[1] the predominant view of the professional associations and most academics and practitioners has been that ‘project management’ is a single discipline with transferrable skills. A single qualification framework is appropriate and the skills and techniques are generally applicable across all industries.  However, in the years between the 1960s and the 2000s, as different industries and disciplines progressively adopted the concept of ‘project management’ this holistic view has become increasingly stressed.

The future suggested in this post still sees project management as a single discipline focused around some high-level objectives; but rather than having a single set of generally accepted good practices applicable to most projects most time, the emerging discipline needs to be capable of embracing a range of different approaches to project management and a diverse toolbox of techniques that can be mixed and matched to optimise the creation of the project’s deliverables.

Project management literature has identified at least three key dimensions to project management:

1. An ‘adaptive/agile’ approach -v- a disciplined structured approach.
2. The size, scale, and difficulty associated with the work of the project.
3. Simple relatively predictable projects -v- complex projects with emergent properties.

In addition to these parameters (mapped in the diagram above), there is also the degree of certainty associated with the work, the technical complexity of the product, and the attitude of the stakeholder community[2].

It’s time for a change.

The project management techniques needed to manage different types of project vary enormously; for example:

• The optimum approach to managing a relatively small, simple project to upgrade a website may benefit from an adaptive/Agile approach to managing the work and should only require a ‘light touch’ to control the work;
• Contrast this to the disciplined approach needed to design and build a new chemical plant where not only do complicated parts need to be manufactured to precise dimensions months in advance and shipped halfway around the world, but the work has to be carefully managed and the parts assembled in a precise sequence to allow all bits to be fitted together properly in a safe working environment.

Both these endeavours are projects, but the project management techniques needed for success are dramatically different. Even within the one project, some elements may benefit from an ‘agile’ approach to the work (eg, systems integration), while other elements of the work will require a very disciplined approach to achieve success – building space rockets does require ‘rocket science’.

The challenge facing the project management profession and project management academics is firstly defining the common core of project management, and then adapting the approach to developing and documenting the overall project management body of knowledge in a way that recognises the core commonality of being ‘a project’ whilst allowing different approaches to the management of the work. And once these foundations are in place, flowing these concepts through into documented standards, knowledge frameworks and certifications. In the 21^st century a ‘one size fits all’ approach to the management of projects is no longer appropriate.

PMI has started down this path, they have agile certifications and have included both tailorability and agile concepts into the 6^th edition of the PMBOK® Guide. Developments in the ISO space are also moving towards this integrated but separated approach to managing different types of projects. ISO 21500 Guidance on Project Management, is being updated and transformed into a higher level ‘management standard’, if this development is successful, in the future a series of implementation guides can be foreseen focused on different types, sizes and phases of project development and delivery.

What’s missing at the moment is a holistic and agreed understanding precisely what a project actually is[3] (this will segregate project management from other forms of management), and then a framework distinguishing the different types of project that exist within the overall frame of a project but requiring different styles of project management. Some of the multitude of factors that need to be considered include:

• The inherent size of the project usually measured in terms of value;
• The degree of technical difficulty in creating the output (complication) caused by the characteristics of the project’s work and its deliverables, or the time-frame the deliverables are required within;
• The degree of uncertainty involved in the project;
• The degree of complexity associated with the work and the stakeholder relationships;
• The difference between client project management and contractor project management;
• The various methodologies and strategic approaches to managing the project and developing the product (Agile, PRINCE2, etc);
• The maturity of the environment in which the project is being delivered (developing economies/organisations -v- mature economies/organisations); and
• The difference between project, program and portfolio management.

The common core

The core element of all projects is the intentional ‘temporariness’ of the team (organisation) set up to deliver the project. The ‘temporary organisation’ is given an objective to create a deliverable for a client and then to shut down efficiently; in addition, there is an intention on the part of most key stakeholders to treat the work as a ‘project’. This means the project has to be started (initiated), the work planned, then undertaken, and on completion the temporary organisation has to be closed – and of course, all of these activities need monitoring and controlling.

Where 21^st century project management needs to diverge from the doctrines of the last century is in the way these overarching objectives are achieved – defining 44 or 49 processes as ‘generally accepted best practices’ is no longer appropriate.  The concept of ‘project management’ needs to be able to adapt to very different approaches, allow the project team to select from a toolbox of ‘useful techniques and methodologies’ and then encourage the teams to craft the processes they actually use to optimise the delivery of the project’s outputs to its clients.

Achieving this will require a different approach to developing standards, a different approach to training and qualifying practitioners and the creation of very different communities within the profession that encourages cohesion whilst embracing diversity of practice.

It will be interesting to see if our profession is up to the challenges.

____________________

[1] For more on the origins of ‘modern project management’ see: http://www.mosaicprojects.com.au/PDF_Papers/P050_Origins_of_Modern_PM.pdf

[2] For more on the dimensions of project management see: http://www.mosaicprojects.com.au/WhitePapers/WP1072_Project_Size.pdf

[3] For more on defining a project see: https://mosaicprojects.wordpress.com/2016/08/11/seeking-a-definition-of-a-project/

Differentiating normal, complex and megaprojects

The days when projects were simply projects and project success was defined by the ‘iron triangle’ are long gone.  The intention of this post is to try and bring together four aspects of current thinking and their embedded concepts into an overall model of project management in the 21^st century.  The starting point is traditional project management as defined in the soon to be published 6^th Edition of the PMBOK® Guide; the major change (incorporated in the 6^th Ed.) is ‘Agile Project Management’.  The two significant extensions to traditional project management that go beyond the PMBOK® Guide are ‘Complex Project Management’ and ‘Megaproject Management’. The focus of this paper is on the skills and competencies needed by the ‘managers’ of these different classifications of ‘projects’ rather than the scope of the different concepts (more on this later).

As a starting point, there seems to be a generally accepted view that the competencies needed to be a successful project manager underpin all of the other concepts. There are some distinctly different techniques used in Agile, only some of which flow into traditional project management, but in other respects ‘agile’ and ‘good project management’ are very closely aligned.  Managing complexity requires a significant additional set of competencies that build onto the traditional requirements.  Then, whilst many complex projects do not meet the definition of a ‘megaproject’, every megaproject is by definition a complex project with an additional layer of management capabilities needed to deal with its impact on society.  This basic framework is outlined below:

Stakeholders

All forms of project management recognise the importance of the project stakeholders. Projects are done by people for people and the ultimate success or failure of a project is defined by people – all ‘stakeholders’.  My work on the PMBOK® Guide 6^th Edition core team was very much focused on enhancing the sections on stakeholder engagement and communication (which is the primary tool for engaging stakeholders). And as the scale of projects increase, the number of stakeholders and the intensity of public focus increases dramatically.

A heuristic suggested by Prof. Bent Flyvbjerg is as a general rule of thumb: ‘megaprojects’ are measured in billions of dollars, ‘major projects’ in hundreds of millions, and ‘projects’ in tens of millions or less. To quote the late Spike Milligan, ‘Money can’t buy you friends but you do get a better class of enemy’ – and while many stakeholders may not be ‘enemies’, the ability of stakeholders to organise around a megaproject tends to be far greater than around a small internal project. Consequently the focus on stakeholders should increase significantly in excess of the increment in cost as you flow from small to megaprojects.

However, regardless of size, the need to identify, engage, manage, and deliver value to stakeholders, through the realisation of beneficial change, is consistent through all of the concepts discussed below. This and the temporariness of each ‘project organisation (ie, team)’ are the two consistent factors that underpin the concept of project management; and ‘temporariness’ is the key factor that separates projects and programs from other forms of management and ‘business as usual’.

 

Traditional Project Management.

The recognised guide for traditional project management is the PMBOK® Guide augmented to a degree by ISO 21500. The publicly released information on the 6^th Edition highlights the need for flexibility in applying its processes, including the requirement to actively consider ‘tailoring processes’ to meet project requirements, and the value agile thinking can bring to the overall management of projects (see below).

The frame of traditional project management starts once the project is defined and finishes once the project has delivered is objectives. While this scope is somewhat limited and there may be a need to expand the scope of project management to include project definition at the ‘front end’, and benefits realisation and value creation after the outputs have been delivered (this will be the subject of another post), the knowledge, skills and competencies required to manage this type of project management are well understood.

Each project has four basic dimensions, size (usually measured in $), technical difficulty, uncertainty and complexity (these are discussed in detail in: Project Size and Categorisation). In the right circumstances, Agile can be an effective approach to resolving uncertainty. However, at an undefined point, the increase in complexity reaches a point where the concept of ‘complex project management’ becomes significant and really large projects are the realm of ‘megaproject management’. But the underpinning capabilities required to manage all of these extensions remains the conventional project management skills.

 

Agile Project Management

Agile has many facets. The concepts contained in the Agile Manifesto basically reflect a shift away from a ridged focus on process towards a focus on people (stakeholders) and adapting to change to achieve a successful outcome.  These concepts are now firmly embedded in the PMBOK® Guide 6^th Edition and apply to every project. Where agile projects separate from traditional project is recognising that in a range of soft projects, including software development, taking an iterative and adaptive approach to understanding the scope can often achieve a better outcome. Understanding what is actually helpful to the client develops based on learned experience from earlier iterations and these needs are incorporated into the next iteration of the development allowing a better outcome to be delivered to the client. This is not significantly different to much older concepts such as ‘rolling wave planning’ and progressive elaboration – there really is little point in making detailed plans for work you don’t know much about. The difference is Agile actively expects the scope to be adapted to the emerging requirements of the client, the other approaches seek to add detail to the plans at an appropriate point in time whilst the overall scope remains fundamentally unchanged.

Agile does not even need a project to be useful. Many of the Agile techniques work in any situation where there is a backlog of work to get through and can be effectively used outside of the concept of a ‘project’, this particularly applies to routine maintenance work of almost any kind.  A discussion on the value of Agile, and its limitations, are contained in our paper Thoughts on Agile.

However, for the purposes of this post the key aspects Agile brings to the discussion, that are essential for effectively managing most types of project, are contained in the Manifesto – a preference for:

• Individuals and interactions over processes and tools.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The Manifesto recognises there is value in the items on the right, but values the items on the left more.

 

Complex Project Management

Complexity is a facet of every project and program. Complex project management skills become important at the point where complexity becomes a significant inhibitor affecting the delivery of a successful outcome from the project (or program). This point may occur well before ‘complexity’ becomes the defining feature of the project.

Complexity is a very different concept to a complicated project, technically complicated work can be predicted and managed; launching a new communication satellite is ‘rocket science’, but there are highly skilled rocket scientist available that undertake this type of work on a routine basis. As with any traditional project the costs, resources and time required can be predicted reasonably accurately.

The dominant feature of complexity is the non-predictability of outcomes. Non-linearity, ‘the tipping point’, and emergence describe different ways outcomes from a slightly different starting point can vary significantly compared to previous experience or expectations (for more on the concepts of complexity see: Complexity Theory).  Complexity arises from various forms of complex system, these may be organic (eg, a river’s eco-system), man-made (eg, an overly complicated system-of-systems such as too many interconnected software applications automatically interacting with each other), or interpersonal (eg, the web of relationships within and between a project team and its surrounding stakeholder community).  In all of these situations, the ‘system’ behaves relatively predictably, dealing with the effects of stresses and stimuli up to a point (and normal management approaches work satisfactorily); but after that point adding or changing the situation by a small increment creates completely unexpected consequences.

Interestingly, from the perspective of managing a project, these three areas of complexity are closely interlinked, the complex behaviour of the environment and/or man-made systems-of-systems feeds back into the perceptions of stakeholders and the activity of stakeholders can impact on both the environment and the way complex systems function. Similarly, dealing with emerging anomalies in the environment or in a complex system needs the active cooperation of at least some of the project’s stakeholders. Consequently, the focus of complex project management is dealing with the consequences of the inherently unpredictable and complex behaviours and attitudes of stakeholders, both within the team and within the surrounding stakeholder community.

Some projects and programs, particularly large ones, are obviously complex from the outset and can be set up to make effective use of the ideas embedded in complex project management. Others may be perceived as non-complex ‘business-as-usual’ and tip into complexity as a result of some unforeseen factor such as a ‘normal accident[1]’ occurring or simply because the perception of ‘straightforward’ was ill-founded. Underestimating complexity is a significant risk.

Where the project is perceived to be complex from the outset, a management team with the competencies required to deal with the nuances of managing a ‘complex project’ can be appointed from day one (and if appropriately skilled people are not available, support and training can be provided to overcome the deficiencies) – this maximises the probability of a successful outcome.  When a project unexpectedly falls into a state of complexity the situation is far more difficult to manage primarily because the people managing the work are unlikely to be skilled in complex project management, will try to use normal management techniques and most organisations lack the resources needed to help rectify the situation – skilled complex project managers are in short supply globally.

One initiative designed to overcome this shortage of ‘complex project managers’ and build an understanding of ‘complex project management’ is the International Centre for Complex Project Management (ICCPM).  ICCPM’s approach to complex project management is to see this capability as an extension of traditional project management (as inferred in the diagram above). The ICCPM view is that while traditional approaches are insufficient to effectively manage a complex project on their own, you cannot manage a complex project without a strong foundation based on these traditional skills and processes. The relationship is described by the ICCPM as:

What changes is in part the way the traditional capabilities such as scheduling and budgeting are used, overlaid with the expectation these artifacts will need to adjust and change as the situation around the project changes, augmented with a range of ‘special attributes’ particular to the process of managing a complex project. These ‘special attributes’ are valuable in the management of any project but become essential in the management of complex projects.  These capabilities and competencies are defined in the ICCPM’s Complex Project Manager Competency Standard available from: https://iccpm.com/.

 

Complex projects can vary in size from relatively small undertakings involving factors such as updating a complex systems-of-systems, or a high level of political sensitivity, through to the megaprojects discussed below. A complex project may not be a megaproject or even a major project, but every megaproject and many major projects will be a complex project requiring complex project management capabilities for a successful outcome.

 

Megaproject Management

Megaprojects are defined as temporary endeavours (i.e. projects or programs) characterised by:

• A large investment commitment;
• Vast complexity (especially in organizational terms); and
• A long-lasting impact on the economy (of a country or region), the environment, and society.

They are initiatives that are physical, very expensive, and public. By definition, megaprojects are complex endeavours requiring a high degree of capability in the management of complex projects.  In addition megaprojects typically involve a number of other facets:

• Megaprojects are by definition a program of work (see: Defining Program Types).
• Many are implemented under government legislation, requiring skills and knowledge of government processes and the ability to operate within the ambit of ‘government’. This is a very different space in terms of accountability and transparency compared to private enterprise.
• Most interact with a range of government agencies at all levels of government from local to national. These stakeholders often have a very different set of agendas and success criteria compared to the organisation running the megaproject.
• The size of a typical megaproject involves large amounts of money and therefore increases the risk of corruption and other malfeasance – governance and controls need to be robust[2] to maintain high ethical standards.
• The ‘political attractiveness’ of doing a megaproject (eg, hosing the Olympics) distorts decision making; care in the megaproject development process is required to reduce the effect of optimism bias and strategic misrepresentation (see: The reference case for management reserves).
• Megaprojects are financially fragile[3] and fragility is typically irreversible. Once broken the fragile entity cannot be readily restored to its original function. Financial (or investment) fragility is defined as the vulnerability of a financial investment to becoming non-viable, i.e., losing its ability to create net economic value. For example, the cost risks for big dams are significant; the actual costs more than doubles the original estimate for 2 out of 10 dams; triples for 1 out of every 10 big dams. But managers do not seem to learn; forecasts today are likely to be as wrong as they were between 1934 and 2007.

Recognising the scope and complexity of managing a megaproject and training people appropriately can mitigate the risks, the UK experience around Terminal 5 and Cross Rail (both £4 billion projects) suggest that achieving a good outcome is viable provided the organisation commissioning the megaproject is prepared to invest in its management. It’s probably no coincidence the management of megaprojects and their associated risk has been the focus of the Saïd Business School, University of Oxford for many years.

 

Summary

The competencies needed to manage projects grows in line with the increase in complexity and the increase in size. There are definitely additional elements of competency needed at each step in the framework outlined above.  What is far less clear is how to demarcate between normal, complex and megaprojects! Every project has a degree of complexity and a degree of size.  The values suggested above to separate normal, major and mega projects are arbitrary and there is even less clarity as to the transition between normal and complex projects.

I suspect the domain map demarcating the different disciplines will end up looking something like this but there’s a lot of research needed to define the boundaries and assign values to the axis (especially in terms of measuring the degree of complexity).  Hopefully, this blog will serve to start the discussion.

__________________

 

[1] Normal accidents are system accidents that are inevitable in extremely complex systems. The three
conditions that make a system likely to be susceptible to Normal Accidents are:
–  The system is complex
–  The system is tightly coupled
–  The system has catastrophic potential
The characteristic of the system leads to multiple failures which interact with each other, despite efforts to
avoid them.

[2] For more on governance and ethics see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#OrgGov1

[3] From: Big Is Fragile: An Attempt at Theorizing Scale, in Bent Flyvbjerg, ed., The Oxford Handbook of Megaproject Management (Oxford: Oxford University Press)

The Yin and Yang of Integrated Data Systems

Integrated project management information systems (PMIS) are becoming more common and more sophisticated ranging from ‘web portals’ that hold project data through to the potential for fully integrated design and construction management using BIM[1].  The benefits from using these systems can be as much as 20% on complex construction projects using BIM.

The advantages of this type of information storage and retrieval system include:

• Ready access to data when needed via PDAs and ‘tablets’ significantly reducing the need for ‘push’ communication and the existence of ‘redundant data’[2].
• One place to look for information with indexing and cross-referencing to minimise the potential for missed information.
• Audit trails and systems to ensure only the latest version of any document is available.
• Cross-linking of data in different documents and formats to assist with configuration management, requirements traceability and change control.
• Controls on who can ‘see’ the data, access the data and edit the data.
• Workflow functions to remind people of their next job, list open actions, record actual progress, etc[3].
• A range of built-in functions to validate data and avoid ‘clashes’, including locking or ‘freezing’ parts of the data set when that information has been moved into ‘work’.

These benefits are significant and a well-designed system reduces errors and enhances productivity leading to reduced costs, but the ‘yin’ of well-designed PMIS comes with a ‘yang’!

People increasingly tend to believe information produced from a computer system, this is true of ‘Facebook’, Wikipedia and flows through to more sophisticated systems. There also seems to be a steady reduction in the ability of younger people in particular to critically analyse information; in short if it comes from the computer many people will assume it is correct. Add to this the ability of many of the more sophisticated PMIS tools to transpose and transfer information between different parts of the systems automatically or semiautomatically and there is a potential for many of the benefits outlined above to be undermined by poor data. This issue has been identified for decades and has the acronym GIGO – garbage in, garbage out.

The question posed in this blog is how many projects and project support organisations (PMOs, etc.) consider or actively implement effective data traceability.  Failed audits, overruns from scope oversights, and uninformed or ill-informed decision-making are just a few of the consequences project teams suffer from if they do not have full traceability of their project management data. This issue exists in any information processing system from basic schedule updating, through monthly reporting to the most sophisticated, integrated PMIS. If you cannot rely on the source data, no amount of processing will improve the situation! And to be able to rely on data, you need to be able to trace it back to its source.

Traceability is defined as ‘the ability to trace the location, history and use of each data element’. This sounds simple but in reality can be very challenging, and the results of poor visibility can be devastating to a project. Some of the key questions to ask are:

• Where did this data or these actuals come from?
• What is the authorizing document and when did it get signed/approved?
• Has everyone approved the change request or action item?

Traceability does not happen by accident! Project management information systems have to be designed with traceability as a key element in each of its aspects.  As information comes into the system the author or the origin of the information has to be recorded (preferably automatically). Depending on the nature of the information it may need to be quarantined until appropriate checks have been carried out and/or approvals have been obtained and then there needs to be traceability of any subsequent changes. The foundation of traceability is the combination of processes (people) and data management.

Therefore, the ‘yang’ of a sophisticated integrated project management information systems is that as the systems become more integrated and sophisticated people will come to rely on the information provided and ‘trust it’ whilst the source and veracity of the data used becomes less obvious.

Resolving this is partly process and partly people. The Chartered Institute of Building (CIOB) has produced the Time and Cost Management Contract Suite 2015 focused on complex construction projects using BIM.  This contract defines a number of key support roles (largely independent of the parties) focused on managing the information flows into and out of the system to ensure its accuracy and validity. Similar roles and responsibilities are essential in any effective PMIS.

My latest post on the PMI ‘Voices blog’, From Data to Wisdom: Creating & Managing Knowledge highlights the importance of data as the underpinning of all reporting and communication.  So the question is, how much focus does your project team or PMO put on ensuring the data it is using is timely, complete, accurate and traceable?

_________________

[1] BIM = Building Information Modelling, see: http://www.mosaicprojects.com.au/WhitePapers/WP1082_BIM_Levels.pdf

[2] For more on planning project communication see: http://www.mosaicprojects.com.au/Mag_Articles/ESEI-09-communication-planning.pdf

[3] A discussion on how these capabilities can enhance project controls is at: https://mosaicprojects.wordpress.com/2016/11/26/the-future-of-project-controls/

Are you a workshop leader or facilitator?

Workshops are a routine feature in many projects. They are typically used either to find a solution to a problem or to develop and integrate knowledge needed for the work (eg, requirements gathering and prioritisation).

Effective project managers know that every workshop is a meeting and many of the rules for running effective meetings need to be applied including:

• Making sure the right people are in the room;
• Having a clear purpose (one meeting – on purpose);
• Distributing the agenda and supporting documents in advance; and
• Starting on time. For more on running effective meetings see: http://www.mosaicprojects.com.au/WhitePapers/WP1075_Meetings.pdf

They also know that unlike normal meetings workshops are a creative process that needs the active contribution of the attendees to craft the best answer to the problem or question being posed…..  This means time is needed to ‘break the ice’ so that the people in the workshop feel comfortable working together and the facilitator needs to act as a host welcoming and engaging people as they arrive.

The job of the facilitator is to ensure the workshop ‘works’ and produces the required outcomes. The facilitator (or workshop leader) only needs sufficient knowledge of the subject under discussion to allow them to ask pertinent questions and summarise discussion – the core skills of facilitation lay in ensuring everyone is engaged and participates, all points of view are heard, the group works towards a consensus or conclusion efficiently and the outputs are agreed.  For more on facilitation see: http://www.mosaicprojects.com.au/WhitePapers/WP1067_Facilitation.pdf

Facilitation is a very useful skill for a project manager to acquire and use, however, to organise and run a successful workshop there are a two key questions that need to be asked very early in the planning stage – unfortunately both of these are frequently overlooked!

Question 1 – Will I be a key contributor to the process of developing the workshop’s output? If the answer to this question is ‘yes’ the project manager should consider engaging someone else to act as the facilitator for the workshop.  The role of the facilitator is to make sure everyone contributes, all of the ideas are brought into discussion and the best solution is reached; it is nearly impossible to do this if you are also contributing significant input to the discussion.

Question 2 – Do I want to lead the workshop towards a predetermined conclusion or do I want the workshop to have free reign to explore and develop its own solutions?  While a degree of flexibility is needed in both situations, if the workshop is focused on getting buy-in to a concept that is already in mind (quite common in problem solving mode) the approach to managing the workshop will be quite different to an open discussion looking at all of the options.

Based on your answers to these questions there are four quite different types of workshop that require different approaches to deliver successful outcomes:

The best way to approach the planning and running each of these workshop types varies significantly.

You facilitate. In situations where you have no particular input to contribute and no predetermined outcome in mind (beyond the fact you need an outcome) facilitating the work of the group participating in the workshop can be a good way to build credibility and enhance your leadership position. Provided you are comfortable in the role, facilitating the workshop to achieve a useful outcome is a valid role for the project manager.  If you are not comfortable in the role, there is nothing wrong with using an experienced facilitator, your objective is simply to get a useful outcome from the process (for example a prioritised list of requirements).

Others facilitate. Where you are going to be a key participant in the workshop process and have significant input to contribute as a subject matter expert, but do not want to drive to a predetermined conclusion, the use of a neutral facilitator is essential.  The job of the facilitator is to ensure all of the viewpoints in the room are heard and the outcomes from the workshop incorporate the views of the participants, either based on a consensus or by applying an impartial selection / decision making process. It is virtually impossible to simultaneously be a participating expert and an impartial facilitator.

Briefing sessions. Have a very different focus, the purpose of the workshop is to explore and understand a predetermined proposition.  The role of the facilitator shifts towards making sure everyone’s questions are heard and answered, and there is a full understanding of the proposition being put. The outcome from the workshop is focused on creating understanding and buy-in from the participants rather than crafting a free-form solution – depending on the nature of the proposition being discussed, there may, or may not, be opportunities to adjust or fine-tune the concepts. However, provided someone else is the primary source of the concepts being discussed, the project manager can usefully take the role of facilitator.

Sales sessions. Have a similar focus to briefing sessions but the concept being ‘sold’ is primarily ‘owned’ by the project manager.  In this situation if you want genuine buy-in from the workshop participants it is essential that the workshop is facilitated by someone else!  The facilitator’s job is to make sure everyone is heard and to help lead the group towards a common understanding and consensus. Your job is to answer the questions and ‘sell’ the proposition (and where appropriate adapt your proposition based on the feedback received).

Understanding the objectives of the workshop and the best way for you to participate in delivering a successful outcome lays the foundation for success.  Then the hard work starts……..

Governmentality -the cultural underpinning of governance

Two major governance failures in recent times highlight the importance of organisational culture in delivering a well-governed entity.  Professor Ralf Müller has adapted the term ‘governmentality’ to describe the systems of governance and the willingness of the people within an organisation to support the governance objectives of the organisation’s governing body. When the willingness to be governed breaks down, as these two examples demonstrate, governance failures follow.

Toyota

The Lexus ‘unintended acceleration problem’ from 2009 has cost  car manufacturer Toyota a staggering $1.2 billion fine to avoid prosecution for covering up severe safety problems and continuing to make cars with parts the FBI said Toyota “knew were deadly.”  In addition to numerous civil actions and costs of reputational damage.  The saga was described as a classic case of corporate culture that favoured the seemingly easy way out instead of paying the cost and doing the right thing.  But, the actions of the people who magnified the problem by attempting to cover up the issues fundamentally contradicts the ‘Toyota Way’ that has guided Toyota since 2001. The Toyota Way has two core principles, respect for people and continuous improvement (kaizen).

Respect for people puts ‘people before profits’, and this is not an idle slogan.  Following an Australian Government decision in 2014, all motor vehicle manufacturing in Australia will cease by 2018 (this affects General Motors Holden, Ford and Toyota). In February 2014 Toyota president Akio Toyoda personally came to Australia to tell his workers of the closure and Toyota’s commitment to its staff through training and other activities has maintained staff commitment at our local Altona plant with everyone working to make the “last car the best global car!”.

The difference between the “people first equals customer first” attitude demonstrated in the approach to closing the Altona plant where people are still being released for paid training to up skill for new roles and the ‘customer last’ approach that dominated the Lexus saga is staggering.  The reaffirmation of the ‘Toyota Way’ may have been driven in part by the Lexus disaster but this does not explain why quality and customer service was allowed to fail so badly in the company that practically invented modern quality.

Volkswagen

A similar dichotomy is apparent in the Volkswagen diesel engine emissions scandal.  A company renowned for engineering excellence, from a country renowned for engineering excellence allowed engineering standards to slip to a point where the cars being sold were illegal.  The actual emissions were only part of the problem, Volkswagen engineers had developed a software program dubbed the ‘diesel dupe’ that could detect when the cars were being tested and change the engine performance to improve results. When the cars were operating under controlled laboratory conditions – which typically involve putting them on a stationary test rig – the device appears to have put the vehicle into a sort of safety mode in which the engine ran below normal power and performance thereby reducing emissions. Once on the road, the engines switched out of this test mode.

Governance issues

Neither of these issues involved ‘a few bad apples’ – the excuse used by most institutions to explain banking and financial scandals. They both required extensive management involvement and cover-ups or acquiescence. A substantial subset of both organisation’s management felt that doing the wrong thing was in the best interests of either themselves or the organisation (or both, at least in the short term). But the governing bodies of both organisations would seem to have maintained a commitment to their overall philosophy, the ‘Toyota Way’ and ‘Engineering excellence’.  So what caused the governance failure?

Governmentality

One element that seems central to both of these failures was a breakdown in the willingness of managers to comply with the overall governance philosophy of the organisation which in turn caused the governance processes to fail; this is the domain of governmentality. Governance cannot be successfully imposed on a population that does not want to be governed!

Governmentality is a term coined by philosopher Michel Foucault around 1980 and refers to the way in which the state (or another governing body) exercises control over, or governs, the body of its populace. The concept involves a complex series of two-way transactions involving:

• the way governing bodies try to produce the people best suited to fulfil those governments’ policies;
• the organised practices (mentalities, rationalities, and techniques) through which people are governed, and
• the techniques and strategies by which a society is rendered governable.

In the same way as governments rely on most people complying with legislation most of the time, organisational governance mechanisms such as ‘project management offices’ and ‘portfolio management’ cannot function effectively without the cooperation of the people being governed. When governmentality breaks down and people no longer support the governance processes they cease to be effective.

The challenge facing every governing body, in every organisation, is in three parts

1. Creating an authentic vision and mission for the organisation.
2. Creating an effective governance system that supports the achievement of the vision.
3. Creating and maintaining an ethical culture that embraces and supports governmentality.

Effective governance systems can weed out the bad apples and correct errors, but they cannot oversee the actions of every manager all of the time if the majority of people do not wish to follow the governance dictates, or actively work to subvert them.

Developing the ‘right culture’ by employing the right people (and importantly offloading the wrong people) starts at the top.  The governing body needs to ‘walk the talk’, their CEO and senior executives need to model the desired behaviours and ‘doing the right thing’ needs to be encouraged throughout the organisation.

Achieving this requires authenticity and a holistic approach to the way the organisation functions; all of the elements need to work together cohesively. Achieving this is the primary responsibility and challenge for the ‘governing body’, in most organisations, the Board of Directors!

If you get the vision, mission and culture right, even major lapses such as the ‘Lexus unintended acceleration problem’ can be overcome.  Despite the damage this caused, Toyota is now the world’s largest automotive manufacturer with a market capitalisation that is nearly double that of Ford and GM combined.  This is also the reason why Objectives, ethics and culture are the top three elements in my model for the ‘Functions of Governance’.

Seeking a definition of a project.

Good definitions are short and unambiguous and are essential for almost every aspect of life. Even something as simple as ordering a snack requires a clear understanding of what’ required – this understanding is the basis of a definition. For example, doughnuts and bagels have a lot in common, they are both round and have a hole (a torus), and are made from dough but they are ‘definitely’ very different commodities! If you need a bagel for breakfast or a doughnut for you coffee everyone involved in the transaction needs to understand your requirements if your expectations are to be fulfilled.

 

 

 

 

 

 

 

 

Definitions serve two interlinked purposes, they describe the subject of the definition in sufficient detail to allow the concept to be recognised and understood and they exclude similar ‘concepts’ that do not fit the definition. Definitions do not explain the subject, merely define it.The simple fact is if you cannot define something precisely, you have real problems explaining what it is, what it does and the value it offers, and this lack of definition/understanding seems to be a key challenge facing the project management community (by the way, the bagel is on the left…… the other picture is a Krispy Kreme donut).

Way back in 2002 we suggested the definition of ‘a project’ was flawed. Almost any temporary work organised to achieve an objective could fit into almost all of the definitions currently in use – unfortunately not much has changed since. PMI’s definition of a ‘project’ is a: temporary endeavour undertaken to create a unique product, service or result. This definition is imprecise, for example, a football team engaged in a match is involved in:

• A temporary endeavour – the match lasts a defined time.
• Undertaken to create a unique result – the papers are full of results on the weekend and each match is unique.
• Undertaken to create a unique product or service – the value is in the entertainment provided to fans, either as a ‘product’ (using a marketing perspective) or as a service to the team’s fans.

Add in elements from other definitions of a project such as a ‘defined start and end’, ‘planned sequence of activities’, etcetera and you still fail to clearly differentiate a team engaged in a project from a football team engaged in a match; but no-one considers a game of football a project. Football captains may be team leaders, but they are not ‘project managers’.

The definition we proposed in 2002 looked at the social and stakeholder aspects of a project and arrived at an augmented description: A project is a temporary endeavour undertaken to create a unique product, service or result which the relevant stakeholders agree shall be managed as a project. This definition would clearly exclude the football team engaged in a match unless everyone of significance decided to treat the match as a project but still suffers from a number of weaknesses. To see how this definition works download the 2002 paper from, www.mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf

 

Updating the definition

Since 2002 there has been a significant amount of academic work undertaken that looks at how projects really function which may provide the basis for a better definition of a project.  The key area of research has been focused on describing projects as temporary organisations that need governing and managing; either as a standalone organisation involving actors from many different ‘permanent organisations’ such as the group of people assembled on a construction site, or as a temporary organisation within a larger organisation such a an internal project team (particularly cross-functional project teams). The research suggests that all projects are undertaken by temporary teams that are assembled to undertake the work and then dissipate at the end of the project.

My feeling is recognising the concept of a project as a particular type of temporary organisation provides the basis for a precise and unambiguous definition of ‘a project’. But on its own this is insufficient – whilst every project involves a temporary organisation, many temporary organisations are not involved in projects.

Another fundamental problem with the basic PMBOK definition is the concept of an ‘endeavour’.  The definition of endeavour used as a noun is: an attempt to achieve a goal; as a verb it is: try hard to do or achieve something.  But, ‘making an effort to do something’ is completely intangible; projects involve people! Hitting a nail with a hammer is an endeavour to drive it into a piece of wood but this information is not a lot of use on its own; you need to know who is endeavouring to drive the nail and for what purpose?

Another issue is the focus on outputs – a product service or result; the output is not the project, the project is the work needed to create the output. Once the output is finished, the project ceases to exist!  A building project is the work involved in creating the building, once the building is finished it is a building, not a project. But confronted with the need to create a new building different people will create different projects to achieve similar results:

• One organisation may choose to create two projects, one to design the building, another to construct it;
• A different organisation may choose to create a single ‘design and construct’ project;
• Another organisation may simply treat the work as ‘business as usual’.

The scope of the work involved in any particular project is determined by its stakeholders – projects are a construct created by people for their mutual convenience, not by some immutable fact of nature.

 

A concise definition of a project

Unpacking the elements involved in a project we find:

• A temporary organisation is always involved, but not all temporary organisations are project teams.
• The requirements and scope of work included in a project have to be defined and agreed by the relevant stakeholders – there are no pre-set parameters.
• The stakeholders have to agree that the work to accomplish the scope will be managed as ‘a project’ for the project to exist; the alternative is ‘business as usual’ or some other form of activity.

Modifying our 2002 definition to incorporate these factors suggests a definition along these lines:

A project is a temporary organisation established to deliver a defined set of requirements and scope of work, which the relevant stakeholders agree shall be managed as a project.

This definition overcomes many of the fundamental problems with the existing options:

• It recognises projects are done by people for people, they are not amorphous expenditures of ‘energy’.
• It allows for the fact that projects do not exist in nature, they are ‘artificial constructs’ created by people for their mutual convenience, and different people confronting similar objectives can create very different arrangements to accomplish the work.
• It recognises that projects are only projects if the people doing the work and the people overseeing the work decide to treat the work as a project.

What do you think a good project definition may be that is concise and unambiguous?

The challenge is to craft a technically correct definition, and then apply the Socratic method of thinking outlined in our 2002 paper at:  hwww.mosaicprojects.com.au/PDF_Papers/P007_Project_Fact.pdf.

I look forward to your thoughts!

Is your steering committee costing $5000 per hour?

The loaded cost of running a committee of senior managers can easily exceed $5000 per hour once the opportunity costs are included.  Productive committees offset this by creating value, hopefully significantly greater than their running costs.  Project and program steering committees should be no different!

However, if the steering committee is simply focused on ‘governance’ it is highly unlikely to be generating any significant value.  At the management level where most steering committees operate there is very little governance decision making needed and conformance and assurance usually needs specialists.

The first four functions of governance defined in The Functions of Governance are:

• Determining the objectives of the organisation: this is done by the organisation’s governing body and implemented through the strategic plan. The project should have been selected because it contributes to achieving the strategic plan, a function of portfolio management, but once the project has started it is rather too late.
• Determining the ethics of the organisation: this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s ethical standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
• Creating the culture of the organisation: again this is done by the organisation’s governing body; it is a duty of every manager to support the organisation’s cultural standards and ensure the people they are managing conform. But you do not need a committee to ensure this occurs, just the project manager’s line manager (usually the Sponsor).
• Designing and implementing the governance framework for the organisation: this should be done before the project is started and include delegations of authority for expenditure and decision making and escalation paths. If it has not been done, one half hour meeting of the sponsor and a few key managers can set the delegations.

In summary, the aspects of governance that determine the way the organisation operates and how the project or program will fit into the overall governance framework does not need a monthly meeting of any type.  There are management responsibilities but these are vested in the responsible line manager, typically the Sponsor (see more on the role of a Sponsor).

The final two functions of governance are ensuring accountability by management and conformance by the organisation.  A steering committee can certainly focus on these aspects of governance but if they do, they are largely wasting their time and most of the $5000 per hour.  There are two fundamental reasons for this:

1. It is extremely poor governance for a managing entity to seek to provide assurance that the people it is managing are conforming. Assurance oversight should be provided by an independent body.
2. Most aspects of project surveillance and assurance require high levels of technical skill. It is highly unlikely any of the managers on a steering committee posses these skills (see more on project surveillance).

The organisational entity best suited for the work of surveillance and assurance is a PMO with appropriate support from management. If there is an effective PMO structure in place with the ability to identify shortcomings, backed up by responsible line management there is no need for another committee to second guess the process a few weeks later (see more on PMOs).

Some of the completely unproductive ‘governance’ functions undertaken by ‘steering committees’ include:

• Validating correct procedures have been followed (properly resourced PMOs are a better and cheaper option).
• Discussing negative variances and allocating blame (management action is needed not committee discussions).
• Second guessing management decisions after the event and interfering in the day-to-day running of the project (project professionals are not helped by interference from amateurs – even if they are senior managers).
• Listening to lengthy reports on what has happened during the last month (effective reporting is all that is needed).

Being involved in this type of activity may make the steering committee members feel important but contributes little or nothing of value in a well governed and structured organisation; if the organisation is not well governed and structured the committee members would be far better off focusing on fixing the real problems.

 

Steering Committees can be highly valuable!

The constitution of most steering committees creates a real opportunity to add value to the overall management of a project or program, but only if the committee focuses on helping craft success. Steering committees typically include members from a range of areas within the organisational affected by the project and its deliverables. Therefore as a group its members are uniquely placed to assist the project manager and sponsor deliver a successful project by helping them steer a path through the organisational politics and stakeholder issues that confront any project or program.

This objective can be achieved by making the members of the steering committee personally responsible for the realisation of value from the organisation’s investment in project, and in particular for dealing with the organisational change and stakeholder issues that are outside of the project manager’s responsibilities. Some of the key responsibilities allocated to the steering committee may include:

• Responsibility for preparing the organisation for the changes needed to make use of the project’s deliverables and the realisation of value.
• Managing the interface between the project and the organisational change management work
• Being available to assist in the management of stakeholder issues escalated from the project and/or identified in areas outside of the direct influence of the project.
• Ensuring effective benefits management is in place for the life of the initiative (ie, it continues after the project is closed).
• Dealing with any other aspect of organisational politics that may affect the work of the project or the on-going change initiative.
• Making value based decisions on complex change proposals, including contributing positively to the resolution of intractable problems, to optimise the value outcome for the organisation.

Obviously the steering committee also needs to take an interest in the project its steering to success. The problem is these are all management activities, not governance activities (for more on this see Does organisational governance exist?).

Effective steering committees work with the project manager and sponsor to identify the external influences causing problems and help the project successfully navigate the organisational stakeholder environment. They also resist the urge to interfere in the actual running of the project or program. There is a world of difference between a collaborative and supportive approach focused on success and the negative approach adopted by so many steering committees that seems to translate ‘governance’ into giving the project manager a ‘hard time’ to ensure compliance with ‘due process’ even if this adds to the existing problems.

Are your organisation’s steering committees worth their hourly running costs?