Work Performance Management (WPM) is a new project controls tool that is being developed by Mosaic Project Services. WPM is designed to calculate the current status, and predicted completion date for any project in a consistent, repeatable, and defensible way. It is primarily intended for use in projects, applying Agile or Lean Construction management approaches, where traditional CPM scheduling cannot be used effectively, but will add value on most projects. The types of projects where WPM can provide an effective controls tool include:

• Relatively small projects requiring a straightforward controls system
• Large projects with a single primary deliverable that is easy to measure
• Large projects using CPM where there is a need to overcome the CPM optimism bias[1]
• All project applying Agile[2] and Lean Construction approaches where the project team determine the sequence of working
• Distributed projects[3] where CPM is inappropriate, and management has chosen not to use the ES extension to EVM.

WPM is an easy to use, robust, performance measurement system. The two requirements to implement WPM are:

• A consistent metric to measure the work planned and accomplished, and
• A simple but robust assessment of when the work was planned to be done

Based on this data, WPM can calculate how far ahead or behind plan the work currently is, and based on this information, the likely project completion date (assuming work will continue at the current rate). Recording the status and expected completion at each update provides reliable trend information. This means there is no longer any excuse for, a project team, senior management, and/or the organization’s governing body, ‘not to know’ how the work of each project is progressing.

For a more detailed overview of WPM, see: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

Or download Overview of WPM: https://mosaicprojects.com.au/Mag_Articles/AA037_-_Overview_of_WPM.pdf

[1]     For more on WPM and the CPM optimism bias see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-CPM

[2]     For more on applying WPM to Agile and Lean projects see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Agile

[3]     For more on applying WPM to distributed projects (and a definition of distributed projects) see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Dist

Project controls are facing a dilemma, on one hand there is a strong push to make projects agile and adaptive, on the other the need for on time delivery, organisational reporting requirements, and the law of contracts require precision and certainty from project control systems. For a wide range of projects, traditional critical path scheduling (CPM) is no longer fit for purpose, a new controls paradigm is needed.

CPM is based on scientific management concepts. It assumes there is one best way to undertake the work of a project, management know what this is, and their intentions can be modelled in a CPM schedule. While the CPM paradigm remains true for many projects, experience shows there are also many where this assumption is simply not correct including both soft and distributed projects. In this type of project, there is an ongoing level of flexibility in the sequencing of work that can be exploited to the benefit of the project and the client. However, most of the available management tools such as burndown charts, Kanban boards, sprint planning, last planner, etc., are specific to a methodology, focus on optimising work in the short term, and lack a rigorous predictive capability. 

This presentation define the characteristics of projects that are not suited to CPM, including agile, adaptive, and distributed projects, and describe an approach for managing this type of project based on agile and lean, while recognising there are likely to be some mandatory sequences that must be followed. WPM offers a rigorous framework for identifying progress and predicting the project completion date based on the quantity of work achieved compared to the quantity planned to be accomplished.

This presentation is part of an ongoing project focused on identifying the challenges, and opportunities created by adapting an improved management approach to control agile, adaptive, and distributed projects focused on optimising resource productivity.

Download the presentation: https://mosaicprojects.com.au/PDF_Papers/P214_Controlling_agile_and_distributed_projects.pdf

See more on WPM: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM

In a recent paper, Scheduling Challenges in Agile & Distributed Projects, we developed a classification framework of project characteristics to help define the potential usefulness of CPM scheduling:

1. Physically constrained – there is only one viable work sequence – The CPM paradigm is ideal for this type of project.

2. Practically constrained – management has agreed the one best work sequence. The CPM paradigm is ideal for this type of project.

3. Overarching constraints – there is a required overall sequence of working, with a degree of flexibility in the way the detailed work is performed to achieve the overall objectives. The CPM paradigm may be useful at the high level in a Class 3 project, but has significant limitations at the detail level.

4. Arbitrary constraints – there is no required sequence of working (as in Class 1 or 2), but management has decided to impose a detailed sequence of work as a matter of choice. The CPM paradigm is imposed for little or no practical benefit. Should be managed as Class 3

Building on from this starting point, in the paper we identified two general types of project in Class 3, ‘soft projects’, typically managed using Agile methods and ‘distributed projects’ where the work consisted of a set of deliverables dispersed over an area with no (or limited) real constraint on the order the work is accomplished. Both Agile and Lean offer methods for optimizing the work on Class 3 projects, but when you are applying adaptive work processes how do you assess completion and deal with claims for delay and disruption?

The answer to assessing status and predicting the current expected completion date for Class 3 projects appears to be solved by the concept of Work Performance Management (WPM) offers a simple, robust tool for assessing status and calculating the expected completion regardless of the actual sequence work is being performed.

WPM looks at the quantity of work produced, compared to the quantity planned to be produced. Provided you know what the project has to produce, and have a means of measuring the production, WPM works!  If management does not know what has to be produced and has no way of defining this, it is questionable if the endeavour is a project.

For more on WPM see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM

The next challenge will be developing a protocol for assessing delay and disruption in Class 3 projects, more on this later.

Over the last couple of weeks, we have been updating the estimating pages on our website, partly in response to the #NoEstimating idiocy.

There is no way an organization that intends to survive will undertake future work without an idea of the required resources, time, and cost needed to achieve the objective and an understanding of the anticipated benefits – this is an elementary aspect of governance. This requires estimating! BUT there are two distinctly different approaches to estimating software development and maintenance:

1.  Where the objective is to maintain and enhance an existing capability the estimate is part of the forward budgeting cycle and focuses on the size of the team needed to keep the system functioning appropriately.  Management’s objective is to create a stable team that ‘owns’ the application. Methodologies such as Scrum and Kanban work well, and the validity of the estimate is measured by metrics such as trends in the size of the backlog.  For more on this download De-Projectizing IT Maintenance from: https://mosaicprojects.com.au/PMKI-ITC-040.php#Process1

2.  Where the objective is to create a new capability, project management cuts in.  Projects need an approved scope and budget which requires an estimate! The degree of detail in the estimate needs to be based on the level of detail in the scope documents. If the scope, or objectives, are only defined at the overall level, there’s no point in trying to second guess future developments and create an artificially detailed estimate. But, with appropriate data high level estimates can be remarkably useful. Then, once the project is approved, normal PM processes cut in and work well. Some of the sources of useful benchmarking data are included in our update estimating software list at: https://mosaicprojects.com.au/PMKI-SCH-030.php#Cost

The #NoEstimating fallacies include:

The fantasy that software is ‘different’ – its not! All projects have a degree of uncertainty which creates risk. Some classes of project may be less certain than others, but using reliable benchmarking data will tell you what the risks and the range of outcomes are likely to be.

Estimates should be accurate – this is simply WRONG (but is a widely held myth in the wider management and general community)! Every estimate of a future outcome will be incorrect to some degree.  The purpose of the estimate is to document what you thought should occur which provides a baseline for comparing with what is actually occurring. This comparison highlights the difference (variance) between the planned and actual to create management information. This information is invaluable for directing attention towards understanding why the variance is occurring and adjusting future management actions (or budget allowances) to optimize outcomes.

Conclusion

The fundamental flaw in #NoEstimating is its idiotic assumption that an organization that commits funding and resources to doing something without any concept of how long its is going to take, or what it will cost will survive.  Good governance requires the organizational leadership to manage the organization’s assets for the benefit of the organization’s stakeholders. This does not preclude risk taking (in many industries risk taking is essential). But effective risk taking requires a framework to determine when a current objective is no longer viable so the work can be closed down, and the resources redeployed to more beneficial objectives. For more on portfolio management and governance see: https://mosaicprojects.com.au/PMKI-ORG.php  

In summary #NoEstimating is stupid, but trying to produce a fully detailed estimate based on limited information is nearly as bad.  Prudent estimating requires a balance between what is known about the project at the time, a proper assessment of risk, and the effective use of historical benchmarking data to produce a usable estimate which can be improved and updated as better information becomes available.  For more on cost estimating see: https://mosaicprojects.com.au/PMKI-PBK-025.php#Process1

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

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

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

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

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

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

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

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

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

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

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

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

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

Maybe there is a need for a reframing of the discussions.

• 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 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 21^st 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.

The first key finding is that project management maturity is starting to develop. 80% of the organisations surveyed by Itcom had some form of PMO and most had a defined PM methodology; 30% based on the PMBOK® Guide, 30% on PRINCE2 and 20% an in house methodology. The trend over the next few years is likely to be focused on enhancing existing PMOs capability and value rather then creating new PMOs.

The second key finding was the increasing trend towards people seeing project management as a career. Over 70% of the people surveyed expected to stay in project and program management moving to larger projects or program manager/project director roles as their career develops. At the junior end of the spectrum, the emergence of PMOs provides an employment opportunity for project support staff to begin their working life as project admin staff, schedulers, etc., and then progress into project management.

The strategic importance of project management capability is also being increasingly recognised by senior management with a significant trend towards making project managers permanent staff roles rather than contract roles. The weak spot in this finding was that over 60% of organisations did not appear to have a project management career path defined to help develop their staff. Staff development will become increasingly important as 85% of organisation expect to increase their project spend this year and the job market is already starting to see shortages of appropriately qualified applicants.

The resources needed to develop a career framework are freely available, the PMI PathPro Career Framework can be used free of charge by any organisation to develop a customised framework and is also free to any PMI member to plan their own career development. Organisations that back the framework with effective training and mentoring to help employees grow their careers can offer a clear point of delineation in an increasingly competitive market for skilled employees. For more on PathPro and the various PM certification frameworks see: http://www.mosaicprojects.com.au/Training-PMI_Framework.html or download our report on the certification frameworks used in the Australian project management arena.

In 2006 the Kingsway Hall Hotel paid £49,999 plus an annual licence fee of £7,528 for software vendor Red Sky’s Entirety package, which covered bookings, check-in and sales. Kingsway selected the system based on Red Sky’s recommendation.

Problems arose almost immediately. Issues included incorrect room availability and no-show reports, unallocated mini-bar charges and a main server crash. Entirety could not cope with group bookings and the servers frequently froze.

Kingsway’s solicitors wrote to Red Sky saying that Entirety was unfit for its purpose and Kingsway was entitled to reject it and seek damages. Kingsway claimed for loss of profit on lost room sales of between £222,000 and £311,000, plus £13,500 for an additional reservations manager, £36,333 for three additional shift leaders and £13,500 for wasted staff costs.

Red Sky claimed Kingsway had bought an off-the-shelf package after having ample opportunity to investigate it.

The judge held that Red Sky had been aware of Kingsway’s requirements and under section 14 of the UK Sale of Goods Act 1979 it could be implied that the Entirety software system would be fit for the purpose of increasing revenue and occupancy levels and allowing quicker check-in and check-out. Entirety did not meet that purpose, nor the standard a reasonable man would consider acceptable.

The court awarded Kingsway £50,000 in lost profits £24,000 in wasted expenditure and £38,000 for extra staff costs.

To avoid similar problems, effective requirements analysis is becoming mandatory backed up by delivering on the contracted promises to meet the identified stakeholder requiremets.

References:

Kingsway Hall Hotel Ltd v Red Sky IT (Hounslow) Ltd [2010] EWHC 965 (TCC) – UK Technology and Construction Court May 2010

BSkyb Ltd & Anor v HP Enterprise Services UK Ltd & Anor (Rev 1) [2010] EWHC 86 (TCC)

Earlier this year, the UK High Court handed down its decision in the long running case of BSkyB v EDS (now owned by HP) with the damages awarded against EDS likely to exceed £200m (US$300 million). The judgement will be appealed but stands as a warning for all IT vendors world-wide.

The dispute concerned the failed implementation by EDS of a new customer relationship management (CRM) system for use in BSkyB’s Scottish call centres. The project did not go well. After numerous key deadlines had been missed and various attempts to rectify the situation had failed (including re-planning delivery of the project by signing a ‘Letter of Agreement’ to supersede the primary contract), BSkyB severed its relationship with EDS in 2002 and completed the project in house (at a reported cost of £265m).

Litigation ensued, in which BSkyB made claims of, among other things, deceit (fraudulent misrepresentation), negligent misstatement and breach of contract by EDS. Despite EDS arguing that the project was derailed by the inherent risks in an IT project of this nature and BSkyB’s ‘vague and shifting requirements’, EDS was held liable for fraudulent misrepresentation, negligent misstatement, and breach of contract.

This decision highlights the fine line that must be trodden by service providers in promoting their offerings whilst pitching for jobs. Above all else, service providers should ensure that during tender processes they do not exaggerate their capabilities and should conduct thorough, documented assessments of prospective delivery timing before making any representations. Reliance on inherent risks in IT projects is unlikely, in itself, to be sufficient to substantiate any failure to meet representations “made by the sales guys”.

Welcome to the ‘real world’ guys…… See more on the judgement