Tag Archives: IT Project Management

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: https://mosaicprojects.com.au/shop-pmbok-guide-6th-ed.php

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

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

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

Advertisements

Unscrambling Verification & Validation (V&V)

Verification and validation are processes that are used together to check that a product, service, or system meets requirements and specifications and that it fulfils its intended purpose. Our latest White Paper V&V = the Verification and Validation of Deliverables provides an overview of these important processes and:

  • Defines the purpose of each;
  • Shows how they work together to deliver quality to the client; and
  • Seeks to unscramble the different acronyms used by different people such as V&V and IV&V.

The White Paper is free to download from http://www.mosaicprojects.com.au/WhitePapers/WP1098_V_and_V.pdf (no log-in or registration required).

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: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf

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: http://www.mosaicprojects.com.au/PDF_Papers/P070_A_Simple_View_of_Complexity.pdf

[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: http://www.mosaicprojects.com.au/WhitePapers/WP1051_Cost_Estimating.pdf

[3] For more on ‘rolling wave’ planning see: http://www.mosaicprojects.com.au/WhitePapers/WP1060_Rolling_Wave.pdf

PMI’s Practice Guide for the Governance of Portfolios, Programs, and Projects

governance-of-portfolios-programs-and-projectsPMI’s newly released Practice Guide for the Governance of  Portfolios, Programs, and Projects, provides some useful guidance to organisations and practitioners on the implementation of the management of portfolios, programs, and projects, but very little on the governance of this important aspect of most organisations.

The understanding of project management, program management and portfolio management is well developed and easily accessible to all organisations, many of which have well developed capabilities in these areas, but most still see their projects and programs fail on a regular basis.  Our 2012 post Project or Management Failures? highlighted the issues.

The source of many of these failures lies in the organisation’s ability to manage the overall function of ‘doing projects’ – defined by Professor Peter Morris as ‘the management of projects’ to differentiate this area of middle and executive management from traditional ‘project and program management’. The overall domain covered by the ‘the management of projects’ concept is outlined in our White Paper WP1079 The Strategic Management of Projects.

Despite confusing the governance function and the management function, this PMI Practice Guide is a valuable contribution to this area of management and to a lesser extent the governance of projects, programs and portfolios.  As previously mentioned, the major weakness in the PMI Practice Guide is its failure to differentiate and understand the different functions of governance and management.  Whilst this confusion is common in documents prepared by practitioners and academics focused on IT management and project management, it is rarely seen in any other area of management.

Governance is the exclusive responsibility of an organisation’s governing body; in corporations this is the ‘board of directors’, in other types of organisation, their equivalent.  The governing body is responsible for setting the objectives, culture, and ethical framework for the organisation, employing the organisation’s senior management, oversighting the organisation’s management functions and providing assurance to external stakeholders the organisation is operating effectively and conforming to its obligations (for more on this see: WP 1096 The Functions of Governance). Elements of some of these functions can be delegated to management, particularly in the areas of surveillance and assurance, but accountability remains with the governing body. Importantly in a well governed organisation, the governing body does not interfere in or directly undertake the management of the organisation – it is impossible to govern your own work!

The functions of management were defined 100 years ago by Henri Fayol in his book Administration Industrielle et Generale.  Management involves planning, forecasting, employing other managers and workers, and organising as in creating the organisation; then coordinating, controlling and directing the work of suppliers and subordinates to achieve the organisation’s objectives; whilst working within the ethical and cultural framework set by the governing body (for more on this see: WP 1094 The Functions of Management). A key function of every management role is ensuring subordinates and suppliers conform to the ‘rules’ set by the governing body.

In short, the role of governance is to set the objectives and rules; the role of management is to manage the resources of the organisation to achieve its objectives, working within the ‘rules’. This approach to governance is clearly defined in ISO 38500 the international standard for the corporate governance of information technology, and ISO 21505 the draft international standard for the governance of projects, programs and portfolios.  PMI has completely failed to understand this distinction and as a consequence invented a range of meaningless definitions in the Practice Guide along with a framework that defines basic management functions such as providing resources to undertake work as ‘governance’.

The simple fact of life is the governing body employs managers to undertake management functions and this involves allocating resources, deciding on priorities and making decisions within the strategic framework approved by the governing body. The basic functions of management were clearly defined by Henri Fayol in 1916 had have stood the test of time and the rigours of academic scrutiny.

The tragedy of the decision by PMI to ignore legislation, international standards and a range of governance authorities ranging from the OECD to Cadbury and try to invent its own definition of governance, is that in the PMI model, virtually every management role above that of the project manager is turned into a ‘governance role’.

The proposition made by PMI that every manager responsible for organising and coordinating the work of subordinate managers is engaged in governance is simply untenable – good effective prudent management is simply good effective prudent management!

The role of governance is to create the environment that allows good effective prudent management to occur; ensure the organisation employs people capable of implementing good effective prudent management and to oversee the working of management so the governors can provide assurance to the organisation’s stakeholders that their management team is in fact providing good effective prudent management. The actual work of providing good effective prudent management to achieve the objectives of the organisation is the role, responsibility and duty of managers

Strangely enough most people in real governance positions know what governance is and know what management is.  Alienating this group is a real pity because once you get past the problem of describing almost every management role as a ‘governance role’ the Guide contains a lot of very useful information focused on improving the abysmal performance of many organisations in the complex area of the ‘management of projects’.

  • Section 2 describes organisational project management and the tailoring management practices to meet organisational needs; the essential relationships and considerations; roles and responsibilities; and domains, functions, and processes. It describes how ‘the management of projects’ can be implemented as a program or project for integrated portfolio, program, and project management.
  • Section 3 describes portfolio management, its links to governance and its central role in the ‘management of projects’.
  • Section 4 describes program management and Section 5: management at the Project Level.

In summary PMI’s Practice Guide for the Governance of Portfolios, Programs, and Projects is a good attempt to focus attention on the vital executive and middle management roles that routinely fail to properly support the delivery of projects and programs; the Practice Guide is spoiled by the delusion that middle level managers and executives undertaking their normal management responsibilities are somehow ‘governing’ the organisation.  As a consequence, the governing bodies of organisations and corporations will tend to dismiss the Practice Guide as an irrelevance.

The key element missed by PMI is the understanding that good management practice is an outcome of good governance, and bad management practice is a symptom of governance failure. The role of governance is to ensure its organisation’s management structures and systems are ‘good’. The fact PMI have completely missed this important distinction in their Practice Guide and as a consequence significantly reduced its value to organisations is an opportunity lost! In most organisations both the governance of projects programs and portfolios needs improving and the overall management of projects programs and portfolios needs improving – these are both important, but require very different improvement processes!

Directing for Performance. The AICD moves beyond conformance.

The Australian Institute of Company Director’s (AICD) inaugural Australian Governance Summit 2016 focuses on ‘directing for performance’. The summit will explore beyond compliance to frame governance as a fundamental driver of performance outcomes.  A view we strongly support. For more information see: http://www.companydirectors.com.au/ags

The AICD have also identified a range of challenges and ‘disruptors’ that will affect organisations in 2016 presenting opportunities to organisations that can adapt and exploit the situation and threats to those who are slow. The vast majority of the threats and opportunities involve the rapidly changing digital economy which will require a radical change in the way most organisations integrate ICT into their businesses. Rather than being an enabler of business, in a connected world IT will increasingly be the business.

The Gartner IT Hype Cycle. See: http://www.gartner.com/newsroom/id/2819918

The Gartner IT Hype Cycle.
See: http://www.gartner.com/newsroom/id/2819918

One of the major challenges for organisations of all types identified by the AICD is a chronic lack of IT skills among Board members, with many boards populated by Directors who believe the digital economy will not affect their organisation because that are in the (fill in the gap) industry, not the IT industry.  The simple fact of life in the 21st century is that it does not matter if you are in agriculture, mining, manufacturing, personal services or any other business the successful organisations will be driven by the creation and use of information. Successful organisations will be able to find and use the ‘right information’ from the ever increasing torrent of ‘stuff’ being generated minute by minute:

Internet minuteRecognising the challenges and opportunities is one thing, adapting organisations to benefit from the changes is another!  What’s missing from the AICD evaluation this year is a focus on the central role of governing projects and programs to deliver the performance outcomes. Every change needs a project or program to create the ability to change backed up by organisational change capabilities to realise value.

Governing for change is the focus of ISO 21505, a project I’ve been involved with for the last 6 years, due for publication late 2016. It is also the focus of the annual Project Governance and Controls Symposium (PGCS), held in Canberra each May; see: http://www.pgcs.org.au/.

The challenge for organisations of all types and sizes is to adapt their governance and management structures to exploit the rapidly changing world.

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 http://www.comindware.com/tracker/

An example of an automated workflow management tool from http://www.comindware.com/tracker/

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 Controls – A Definition

ControlsSeveral months ago at the Project Governance and Controls Symposium in Canberra I was asked to define project controls. Everyone talks about ‘controls’ but exactly what is included and how does ‘controls’ relate to other disciplines such as project governance?  To answer this question, my proposed definition for ‘project controls’ is:

Project controls are the data gathering, management and analytical processes used to predict, understand and constructively influence the time and cost outcomes of a project or program; through the communication of information in formats that assist effective management and decision making.

This definition encompasses all stages of a project or program’s lifecycle from the initial estimating needed to ‘size’ a proposed project, through to the forensic analysis needed to understand the causes of failure (and develop claims).

The functions undertaken by project controls professionals includes estimating future works, determining the current status of work in progress, understanding the reasons for this status and recommending appropriate actions or alternatives based on the observed status and trends. Within this framework, for a recommendation or prediction to be useful, the reliability of the information upon which it is based needs to be understood, and additionally, any realistic estimate or forecast must take into account uncertainty and the cost and time consequences of identified risk events.

Consequently, the project controls discipline can be seen as encompassing:

  • Project strategy, planning and methods studies to optimize future outcomes,
  • Scheduling including development, updating and maintenance,
  • Cost estimation, cost engineering/control and value engineering,
  • Risk management,
  • Earned Value Management and Earned Schedule, including WBS, OBS and other breakdown structures,
  • Document management,
  • Supplier performance measurement / oversight (but excluding contract administration),
  • The elements of a project management methodology that integrate these disciplines both within the ‘controls’ domain and with other project management functions, and
  • The ability to communicate effectively the information generated by these processes.

This proposed definition deliberately excludes the actual management of the project scope, including scope related disciplines such as quality control, and general management disciplines such as team development, stakeholder management and communication. ‘Controls’ information is often an important input to these functions but the ‘controls’ role is information generation, management’s role is making effective use of the information.

This means: Project Controllers are the experts who gather, manage and analyse data to generate useful information and insights for others to use. And the primary users of the ‘controls information’ are the project management team and project governance and oversight entities within the organisation such as PMOs and ‘project control boards’ (PCBs).

Certainly, the surveillance aspects of time, cost and risk are intimately linked to the accomplishment of scope, to the quality standards required by the stakeholders, by the project team; but the ‘controls’ processes are not directly involved with the management of project work. Project controls professionals work with the team and other stakeholders to plan the optimum way of accomplishing the work, then measure the actual performance of the team against the agreed plan and use this data to recommend future actions and predict outcomes.

Most authorities recognise that it is impossible to effectively manage or govern a project (or program) in the absence of reliable information on the current status of work in progress, and reliable predictions of future outcomes. This is supported by this proposed definition, with the key delineator between ‘controls’ and ‘management’ being the recognition that it is management’s role to make use of the information and advice generated by the controls professionals.

This theme is carrying forward to the 2014 governance and controls symposium – you are invited to be a part of the debate! To catch the ‘web hot specials’ and/or submit a proposal for a paper visit the symposium website at: http://www.pgcsymposium.com/

Once the definition of ‘controls’ is resolved, the next step will be establishing a framework of certifications and qualifications to benchmark ‘professional’ knowledge and behaviours. There is already good progress in this area with developments by AACEi, Planning Planet, PMI and CIOB to name a few (see more on PMI and CIOB credentials).  What’s lacking in the general ‘market’ is a general recognition that effective controls professionals need domain knowledge as well as tools knowledge.  Developing this recognition is the next challenge.