Monday

Tag Archives: IT Project Management

There’s Agile and there’s Agile, understand the difference!

Posted on January 1, 2020 by | Leave a comment

One size does not fit every situation even in an agile world!  The focus of this new article is to identify the differences in management approach needed to maximize value in three different situations where an ‘Agile’ approach can be used.

For any Agile approach to achieve its promise, the upper echelons of the organisation need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of Agile processes to maximize the creation of value. Download the article from: https://mosaicprojects.com.au/Mag_Articles/SA1060_Agile_Spaces.pdf

For more papers on Managing Agile see: https://mosaicprojects.com.au/PMKI-XTR-010.php#Process1

Leave a comment

Posted in Agile Ideas

Tagged , ,

The Evolution of Project Management

Posted on September 25, 2017 by | 1 comment

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: /2016/08/11/seeking-a-definition-of-a-project/

1 Comment

Posted in Agile Ideas, General Project Management

Tagged , , , , , , , , , , ,

Unscrambling Verification & Validation (V&V)

Posted on June 13, 2017 by | 1 comment

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).

1 Comment

Posted in General Project Management, IT Project Management

Tagged , , , , , ,

The maturing or ‘agile’

Posted on May 8, 2016 by | 1 comment

A 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

1 Comment

Posted in Agile Ideas

Tagged , , , ,

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

Posted on January 24, 2016 by | 10 comments

PMI’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!

10 Comments

Posted in General Project Management, Governance

Tagged , , , , , , , , , , , , , , ,

Directing for Performance. The AICD moves beyond conformance.

Posted on December 12, 2015 by | Leave a comment

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

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:

Recognising 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.

Leave a comment

Posted in Governance, IT Project Management, Project Management Conferences

Tagged , , , , , ,

Workflow Management

Posted on May 31, 2014 by | 1 comment

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/

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.

1 Comment

Posted in Agile Ideas, General Project Management

Tagged , , , , ,

Project Controls – A Definition

Posted on November 21, 2013 by | 9 comments

Several 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.

9 Comments

Posted in Project Controls

Tagged , , , , , ,

Why governance matters

Posted on October 15, 2013 by | Leave a comment

Governance is not management!  The governance of an organisation is the responsibility of the ‘governing body’, typically the Board of Directors or their equivalent. This ‘governing body’ is responsible for developing processes and systems to provide oversight of, and direction to, the organisation’s management to ensure the management work to achieve the organisation’s agreed strategic objectives, whilst operating within the moral, ethical and social frameworks set by the ‘governors’.  Consequently, the root cause of most management failures can be traced back to a governance failure; either a failure to set the right objectives for management, or a failure to properly oversee the performance of management.

Obviously a Board of between 5 and 20 people meeting every few weeks cannot oversee every aspect of management in a major organisation themselves.  Effective governance requires the delegation of appropriate authority to various levels of the organisation’s management but this delegation needs to be planned and properly overseen. You can delegate authority, you cannot delegate responsibility!  The interaction of the management and governance systems within an organisation is the subject of a peer reviewed paper available as a pre-publication document from http://authors.elsevier.com/sd/article/S026378631300094X (if you do not have access to an academic library see: WP1084 Governance Systems & Management Systems  for an earlier discussion of the subject).

From this perspective, the collection of reports into government IT project failures recently discussed in Mark Toomey’s ‘Infonomics Letter’  is worrying.

The general theme of the reports consistently point to a ‘governance failure’ but none of the reports hold the Department Secretary and/or the relevant Ministers responsible for their failure to ensure the governance systems were working effectively. Almost without exception the reports are rigorous in their analysis of government IT. And whilst every investigation carries its own fascinating stories of who did what, and how things went wrong, it is important to consider the overarching lessons that come from aggregating the findings from the collection of investigations. Mark suggests we look at the 2008 Gershon review into the Australian Government’s use of ICT and the follow-up Reineke Review of 2011, and contrast that with reports from the Victorian Government’s Auditor General and Ombudsman. Add in multiple layers of investigation from the payroll system debacle experienced by Queensland Health, and the parallel failure with the Ministry of Education payroll in New Zealand. Australian Customs‘ effort in closing down the national supply chain in October 2005 produced substantial insight, as did one of the globe’s highest profile and most expensive IT failures – the United Kingdom National Health Service Program for IT, and South Africa has its cases (as illustrated in its plan for governance of IT) and no doubt do many other nations.

Mark’s discussion of these is focused on the need for the ‘governing body’ and senior management to own the business initiatives that drive the need for IT innovation (rather then allowing the IT ‘tail’ to wag the organisational ‘dog’. And this is important.

My question is why the ‘governing bodies’ allowed their management to operate in this way in the first place. Spending $billions on projects and programs that do not have a properly defined management structure with properly assigned personal accountabilities is a fundamental failure of governance. And therefore the ‘governors’ need to be held accountable.  How many more years and $billions in failures will go past before accountability is properly assigned?

Project’s involve risk, and sensible ‘light’ systems cannot prevent every failure but if there is properly assigned accountability, the senior managers and directors who are accountable will be encouraged to apply their skills to the challenges sooner rather than later.  The reports linked from this post (thanks to Mark’s research) are sobering reading.

Leave a comment

Posted in Governance

Tagged , ,

The failure of strategic planning

Posted on July 23, 2012 by | 11 comments

Projects struggling for management support are one of the key indicators of a sub-standard value creation system that is failing to make full use of the deliverables created by projects and programs. But the problem is likely to be much deeper; surveys consistently show that between 15% and 80% of projects undertaken by organisations cannot be linked to the performing organisations strategy. These ‘ferrel projects’ are either symptoms of inadequate governance, or symptoms of inadequate strategic planning!

In many organisations, and particularly in business areas focused on system support such as IT the typical path taken by an innovative idea through to some confused delivery of value is a straight line from the innovation, to a business case, to a project that has to seek management support and the surviving projects eventually deliver their outputs to a bunch on unprepared and unwilling end users. The generation of value is far from certain!

Over the last few years, Portfolio Management has started to emerge. Portfolio management should have a strategic focus and make selections based on strategic priorities but in most current implementations tends to be a process oriented, stand alone function. Certainly by applying capacity constraints the number of projects that fail due to lack of organisational resources will be reduced but the focus on value creation is minimal. Management support and organisational change are not central to the process. There is literally a ‘fence’ between the executive ‘strategic planning’ processes and innovation within the organisation.

Most authorities describe project and programs as the ‘change agent’ responsible for creating the ability to implement strategic initiatives to grow and improve the organisation. For this to occur, the strategic planning system needs to be far more engaged with the organisation and central to the process of innovation, guided and supported by the organisations executive!

Within a value driven framework, the strategic planning process should be central to innovation, initiating work to develop prospective ideas, and receiving all of the innovative ideas to enhance the organisation from every source. Innovative organisations such as Google actively encourage innovation and experimentation within parameters but have careful selection processes before burning money on significant projects. They are also prepared use the innovative ideas to inform strategy, and to take significant strategic risks if an innovation warrants the speculation on a ‘whole new future’ for the organisation.
Within this framework, the evolution of the strategic plan is a cyclical process, possibilities and ‘blue sky’ ideas are communicated to the governing body, who formulate, review and update the overall strategic guidelines as new ideas and possibilities emerge.

However, my feeling is there is a tactical level missing from strategic thinking that will be needed for this process to work effectively. The overarching ‘strategic guidance’ needs to be fairly stable and take a long view and only be updated as needed (possibly twice a year). Based on this strategic guidance, a detailed strategic plan is developed at a ‘tactical level’, to frame the current implementation of the strategy. This process needs more rigour and more flexibility (the two are not mutually exclusive) compared to the high level plan, should only take a medium term view and be updated continuously. Based on this plan, feasible ideas that support the strategy are authorised for the development of a value oriented business case.

The creation of this flexible but rigorous tactical-level strategic process would place the ‘plan’ at the forefront of processes such as Portfolio Management and virtually eliminate ferrel projects.

Portfolio management also has a central role to play in developing strategy. The current strategy informs the portfolio selection process, and information on current projects and programs, the viability of assessed business cases and other consolidated information is absorbed back into the strategic planning process. Based on these factors, the key job of the portfolio managers is to select the most strategically important business cases, within the capability and capacity limitations of the organisation, for initiation as projects or programs, and cancel or modify projects that no longer align with the evolving strategic plan.

The role of management is firstly to implement the executive guidance by supporting the Portfolio Management processes and the selected projects. More importantly, management is also responsible for managing the organisation so that the necessary change initiatives are implemented to make effective use of the project deliverables to generate valuable returns over the life of the initiative, frequently a period of many years!

Developing a value driven system similar to the one described in this post is primarily a governance issue. The organisations directors and executives need to lead the process and be closely involved in the strategic management of the organisation.

Strategic planning also needs to evolve from a fluffy ‘high level’ process to a far more useful function that actually sets the strategy for the organisation’s management to implement. Within this framework, the organisations governance systems and leadership need to ensure their management support the process and are focused on creating value.

The Value Chain

However, the value creation chain is only as strong as its weakest link, which includes effective strategic planning supported by effective governance that ensures management support for the overall process. A clear indication the strategic governance processes are not working is when projects and programs have to fight to receive executive support to ‘exist’ and the organisation’s measure of success is limited to the ‘iron triangle’ of time, cost and scope focused at the end of the project.

Successful organisations focus on the more difficult, but more important measures of benefits realised and the value created for the organisation as a result of the project deliverables being used by the organisation to support its strategic initiatives and generate lasting improvements.

Most of the work needed to make this process work is in management areas outside of the traditional Portfolio, Program and Project management (PPP) arena. But no organisation will achieve the optimum results from its PPP initiatives without the front and back ends of the overall value chain being of equal ‘strength’.

This is not rocket science, many successful organisations, particularly in mining and engineering achieve this type of integration in their core business. For more on the governance aspects see: Mosaic WP1073 – Project Governance.  

For more on the overall project delivery capability see: Mosaic WP1079 – Project Delivery Capability.

11 Comments

Posted in Governance

Tagged , , , , , , , , ,