Tag Archives: IT Project Management

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.

Why governance matters

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.