Category Archives: Agile Ideas

The Evolution of Project Management

The publication of the PMBOK® Guide sixth edition at the beginning of September[1], 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[2] 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[3].

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 really does require ‘rocket science’.

The challenge facing the project management profession and project management academics is first 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 21st 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 6th 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[4] (this will segregate project management from other forms of management), and then a framework for distinguishing the different types of project that exist within the overall frame of being ‘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 21st 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] PMBOK® Guide 6th Edition available in Australia:

[2] For more on the origins of ‘modern project management’ see:

[3] For more on the dimensions of project management see:

[4] For more on defining a project see:


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 21st century.  The starting point is traditional project management as defined in the soon to be published 6th Edition of the PMBOK® Guide; the major change (incorporated in the 6th 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:


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 6th 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 6th 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 for 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 6th Edition and apply to every project. Where agile projects separate from traditional projects 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 scientists 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:

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 also 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, hosting 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.



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:

[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 maturing or ‘agile’

kitten-yogaA deliberately provocative article on Linked-In asks the question is ‘Agile Dead?’; a discussion on how various aspects ‘agile’ invented by different individuals and groups are fading from prominence follows.  Agile is not my area of expertise but the article seems designed to generate attention without really saying anything new.

What the article did prompt in my thinking was the question ‘What is agile?’. Concepts vary from:

  • The Agile Manifesto (which is basically 101 common sense) created to overcome the failures of rigid IT development that required a 100% complete fully detailed plan before people really knew what the problem was (often referred to as ‘waterfall’ development but nothing like the original ideas in the waterfall concept).
  • Through to the agile anarchist community who’s mantra seems to be ‘trust us all of our teams are above average’ and we will make you really nice software without any discipline (a concept that ignores the mathematical fact that 50% of any group have to be below average….).
  • Then there are all of the various ‘agile’ methods from ‘Scrum’ to ‘XP’.

Ergo ‘Agile’ or ‘agile’ can mean virtually anything to anyone.  In contrast to all of these specific variants, I would suggest at its root ‘agile’ is a concept or philosophy rather than a methodology or process; useful philosophies rarely ‘die’.

What is emerging I believe is a gradual understanding that the false concepts of ‘command and control[1] and ‘certainty, based on a fully detailed plan[2] are slowly disappearing from management thinking (although there are still plenty of recalcitrant ‘fossils’ embedded in far too many management structures) – detailed planning months or years in advance of the work, done at a time where the work is imprecisely understood cannot control an uncertain future regardless of contract conditions and the exhortation of management. These ideas are slowly being replaced by an adaptive approach to projects that engages stakeholders and focuses on actually achieving the stakeholder’s objectives and realising benefits, ie, an ‘agile’ approach.

Every project and every project management system can benefit from some elements of ‘agile’ (which overlaps with many other concepts such as ‘light’, ‘lean’, and ‘last planner’. The key tenets seem to be:

  • involve your stakeholders,
  • trust your team,
  • don’t waste time planning in detail things you don’t have detailed knowledge of[3],
  • adapt to changing circumstances, and
  • wherever possible avoid a ‘big bang’ approach – iterative and incremental developments mitigate the risk of catastrophic failure.

The agile manifesto certainly highlighted these important concepts but it did not invent them. These elements of fundamental common sense are ignored in far too many situations. What the agile manifesto and the subsequent changes in attitude have done is refocus on the importance of people and relationships in any project.

On the ‘Agile front’, many of the ridiculous excesses promoted by consultants and experts are certainly fading into obscurity. Executives are learning that ‘agile’ is not a cure all ‘silver bullet’ it needs pragmatic management and proper planning the same as everything else, it just the way planning and managing is done that differs; for more on this see:

Certainly there has been a realisation that the agile anarchist’s concept of ‘trust us’ (and their abandonment of any pretence of strategic planning and documentation) really does not work. An appropriate degree of planning, coordination and documentation are essential to achieve success, particularly on larger projects and in the longer term when the inevitable updates and maintenance cut in.

In summary, if ‘agile’ is a philosophy that prioritises people over rigid process, and it will change and adapt over time; it’s not ‘dead’ but it is evolving into a pragmatic management process. Certainly some of the narrowly defined concepts and methodologies branded as ‘agile’ are failing and being abandoned as ‘passing fads’ and new adaptations are emerging, but that’s normal. The core underpinnings of the original Agile Manifesto are still alive and well.


[1] In the 1950’s Peter Drucker identified the need for a new way of managing ‘knowledge work’, see:

[2] “All models are wrong, but some are useful” (Prof. George E.P. Box), and every estimate used in the plan is wrong to a greater or lesser degree, see:

[3] For more on ‘rolling wave’ planning see:

Workflow Management

Many projects involve repetitive elements of work that take some inputs, run them through a series of processes and deliver an integrated output.  Standardising these elements of project work can create efficiencies and minimise errors.   A couple of examples include normal ‘sprints’ in an Agile project and the monthly updating of the plans and reporting in a major project. Workflow management sit one step above individual processes (particularly standard operating procedures) linking them into an optimum sequence of work.

Workflow management means to oversee the creation of a deliverable from beginning to end. The management aspect is to be able to identify the people who need to be involved in each process within the work flow and to ensure the ‘flow’ allows for input from all required parties in the right sequence. The key questions that need answering to create a productive workflow are:

  • What is the optimum sequence of processes?
  • Who needs to be involved in each process? This includes knowing what inputs are required to start the work and what outputs are produces to finish the work.
  • How to keep the momentum going within each process and the overall workflow (and the timely identification of blockages)?

A workflow can be simply designed on a piece of paper (or white board) to show the flow, who is responsible for each process and how the tasks are accomplished; or automated.


An example of an automated workflow management tool from

An example of an automated workflow management tool from

The key advantage of developing and using a workflow is you can expect similar results from the accomplishment of the work at each iteration, even if the people involved change. It reduces errors and provides consistent results.

Agile projects use the concept of ‘done’ at the end of a sprint. A common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects. Teams define the series of steps needed to reach ‘done’, and implement them routinely through each sprint. The steps to get to ‘done’ may include:

  • Code Complete
  • Unit tests written and executed
  • Integration tested
  • Performance tested
  • Documented (just enough)

Build these steps into a workflow and everyone benefits – particularly if the workflow is reviewed and updated to incorporate learned experience on a regular basis. The art is to keep the workflow as simple as possible but not so simple that it becomes simplistic.

So next time you wade through the tasks needed to create your monthly report or any other repetitive job within the overall management of a project think about documenting the work flow – it will pay dividends over time.

Project Zone Congress, Frankfurt #2


The Project Zone Congress is now over and the two conference days lived up to the standards set on pre-conference workshop day (see my first post)!

A few of the ideas picked up as vignettes:

Oliver Lehmann commenting on competency made the point that experience is a teacher, you need to be a good student to learn from your experiences (and the same applies to training courses), this requires taking the time for reflection and then implementing the insights. We are planning a blog on this a bit later.

Peter Taylor asked what’s the best way to develop solutions? ‘End-user’ involvement. or remove the hyphen and ‘end user involvement’?  The challenge is communication and understanding – what do the customers actually understand from your project documentation??

Peter again, project management has progressed from the ‘accidental project managers’ of 20 years ago, to the ‘non-accidental, qualified project managers’ of today and the emerging generation of ‘intentional project managers’ – where people are making specific career choices to become PMs.  Effective sponsorship is a crucial element for project success but no-one is training or supporting sponsors – we are still in the era of the ‘accidental sponsor’.

Organisations are changing and this affects project governance! The effect of the industrial revolution was to progressively isolate organisations from the natural environment with mechanical sources of power (starting with steam) and ‘factory walls’.  The knowledge revolution is increasingly forcing organisations to connect with the ‘virtual world’; connectivity and integration are becoming normal as are the pervasive social networks.  From both a governance and management perspective it in no longer possible to ‘hide’ behind the organisation’s walls.  Openness and accountability are the new normal.

Senior management attention is the key resource in any organisation and is in very short supply.  Maintaining access to this resource is the key to obtaining all of the other resources you need for your project.  This means Advising Upwards effectively to be seen and to be successful!

Change management and the difficulty of implementing change was a constant theme – probably the only person who really likes a change is a wet baby…..  change is generational within organisations – taking 4 years to fully bed down and one successful relapse that goes uncorrected needs 20 corrections to erase the memory of the ‘success’.

Agile was one of the three streams in the conference – my paper on the challenges of developing an effective governance regime ‘Governing Agile – the changing role of project controls in an ‘agile’ environment’ focused a lot of discussion from the more senior managers in the room, good questions and clearly identified issues but at the moment no generally accepted answers to the challenge of governance oversight and control.

Overall a great way to spend 3 days and recommended for anyone looking for a good reason to visit Frankfurt next year (or one of the other conferences organised by Stamford Global Ltd).

What is Agile?

Agile? Sourced from

Agile is not a project management methodology but Agile principles can and should be applied to the management of projects and in the right circumstances the various forms of Agile offer an effective way to develop software. In their original design, Waterfall and the various forms of Agile are software development methodologies, not project management methodologies, and effective project management adapts to the processes being used to develop the project’s deliverables.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavours; this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work, for more on this see: De-Projectising IT Maintenance

With these misconceptions cleared, there seem to be two key areas for discussion.

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

  • There is the need top select the right projects for Agile, for more on this see: Selecting the right projects for Agile
  • There is a need for a much lighter “touch” managing an Agile project; for more on this see: Managing Agile Projects
  • There is a need for a higher level of trust in managing Agile teams, for more on this see: Advising Upwards
  • There is a need for robust change management and configuration management to track the evolution of the Agile project
  • There is a critical need to develop the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

  • The need to trust knowledge workers more than manual workers
  • Success measured by customer satisfaction rather than quantitative outputs
  • The need to keep the client involved

Our discussion paper Thoughts on Agile looks at theses questions in more detail. The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated. The paper can be downloaded from:

Selecting the right projects for Agile

I have just read an interesting article by Bob McGannon on selecting the right IT projects for Agile development. Bob is a Founder and Principal of MINDAVATION, a company providing project management training, consulting, keynotes & coaching services throughout North America, Europe, the Middle East and Australia.

Here is a précis of Bob’s guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.

  • An eager sponsor willing to conduct frequent reviews and evaluations of the evolving product.
  • Ambitious, knowledgeable and available business representatives – The Agile process is purposefully collaborative.
  • Minimal time to verify product viability: its power comes from its ability to produce quickly, adjust consistently to new knowledge and business change but only if the learning can be understood, interpreted and absorbed quickly.
  • Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
  • A willingness to consider a very different approach; the ability to invest in a different work and management approach is necessary for the project stakeholders.
  • The ‘DNA’ to deal with a bit of ambiguity. Priorities are consistently reassessed and work sequences changed.

The full article can be found at

Bob’s approach is closely aligned to the ideas discussed in Mosaic’s White Paper on Project Strategy; see:; one approach to every problem seldome dilivers optimum outcomes.