Software sales hype and the law

Effective and ethical stakeholder management is becoming mandatory. For decades the software industry has been able to largely ignore the needs of its clients, but the world is changing. The UK Construction and Technology Court is following the lead set in the BSkyB v EDS judgment and making software vendors live up to their promises! You can bet the rest of the world won’t be far behind….

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)

The Scope of Change

This blog is going to try and link project and program management with change management and benefits realization.

As a start, the only point of undertaking a project or program is to realize some form of value. Benefit realization! To realize value, three elements need to be brought together:

1. There needs to be a new product or process created (an artifact);
2. People within the organization need to make effective use of the artifact to deliver a service;
3. The service as delivered needs to be accepted and used in the ‘market’.

The role of Strategic management and Portfolio management is to determine what services are likely to be accepted or needed by the market; a new shopping centre, an improved insurance package or simply a more efficient process to deliver information. These decisions will depend on the objectives of the organization, and is not the province of this blog.

The generally accepted role of project management is to create a unique product, service or result (an output) and the role of program management is to manage a group of related projects to achieve an outcome more efficiently than if the projects had been managed in isolation. Neither of these processes achieves real value in themselves. The realization of sustained value is achieved by the organization using the program’s outcome effectively over many months or years.

The Scope of Change Management

Projects and, to a greater extent, programs can realize some benefits, partially in the design and delivery of their respective outputs. Early benefits realization is frequently linked to ‘soft’ elements in the range of deliverables such as developing effective training, managing the transition to operations and ensuring a proper support framework is developed. Achieving these elements require the project/program team to really understand the requirements of their stakeholders. However, as demonstrated by the cost/benefit graph, benefits realization should continue for years after the program is finished and closed.

The extended timeline for value realization has important ramifications for organizational change management. Each project is an intense burst of change and the program absorbs these changes and has additional change effects of its own. These ‘activity related changes’ will include beneficial and negative impacts on a range of associated stakeholders. Some changes are disruptive caused by the execution of the work, learning curves, etc. Some changes positive caused by the improvements the projects and programs were initiated to deliver. Achieving a successful project/program outcome requires the effective management of these stakeholder communities, but the stakeolder management activity is essentially tactical.

The critical requirement to deliver sustained value is the organizational culture change needed to actively embrace the program’s outcomes and make valuable use of them. Embedding a culture change into an organization is a 2 to 3 year process as the change migrates from ‘new and threatening’, to ‘accepted (but the old way are still fondly remembered)’ to the ‘established old way’ things are done around here. This type of long term organizational change can only be accomplished by the organization’s line management supported by senior management. This is the realm of the program sponsor and executive management!

These ideas also have important ramifications for effective stakeholder management:

• Project level stakeholder management is relatively short term and focused on minimizing opposition to the work whilst ensuring necessary organizational support is in place to deliver the project’s outputs effectively. This is essentially tactical in nature.
• Program level stakeholder management has a wider view that needs to engage with the organizations strategic vision to ensure the program’s outcome is optimized to the changing circumstances within and around the organization. The key issue here is identifying and responding to changing stakeholder requirements, needs and expectations/perceptions over time; so as to optimize the value of the ‘outcome’ the project was established to deliver.
• Organizational level stakeholder management needs an even broader and longer term view focused on the strategic needs of the organization and its long term relationship with both internal and external stakeholders. Sustained value creation requires both the organizations internal staff and its external customers to jointly perceive the programs ‘output’ as valuable to them and also to perceive the organization favorably so they together maximize its use:
  • For a new shopping center with a 20 year lifespan this translates to retail tenants being willing to rent space and the ‘public’ seeing the shopping center as a ‘good place to shop’.
  • For a new call centre management system this translates into the call centre staff seeing the system as efficient and easy to use and clients of the business perceiving the system and staff as friendly, efficient and effective so they are happy to make repeated use of the system.

Conclusions

Change management and stakeholder management are closely aligned. Effective stakeholder management is essential for successful change management.

Change management and stakeholder management must start as soon as the project or program are initiated but should continue well after the project/program are completed.

The on-going organizational component of change management supported by strategic stakeholder management is critical if the real value of the outputs/outcomes created by the projects and program are to be realized.

Benefits realization is a line management responsibility starting with the project sponsor. All project and program managers can do is ensure their deliverables are crafted to facilitate and encourage benefits realization.

When does a project start and end?

There seems to be an attempt by many senior managers to make their project managers responsible for all aspects of a project from understanding the business need through to realising the benefits years after the project has finished. Whilst this can seem a very effective ‘buck passing’ to blame someone else for another failure, it is hardly fair or reasonable and is highly detrimental to the organisation.

PMI and the new ISO21500 have the view a project starts when it is officially started and it finishes when it has delivered all of the required deliverables. This raises a number of sensible considerations.

Starting a project
Only the managers of an organisation are in a position to determine its strategic direction and then identify and prioritise the ‘needs’ that require meeting to implement the strategy. After a ‘need’ is defined a project can be initiated to deliver the required outputs. This does not mean the business managers need to have a fully defined specification but they must know how much they know about what’s required:

• If the requirements are clearly understood, a project can be initiated with defined time and cost parameters and limited contingencies.
• If the requirements need to be defined or clarified, the project needs to be established with success criteria understood, adequate time and cost contingencies in place and a ‘gateway’ process defined to ascertain the ongoing viability of the project as the requirements are progressively firmed up. If the project continues to offer a valuable contribution to the organisation it should continue. If its value drops below an acceptable level it should be terminated at the appropriate gateway review.

The PMBOK® Guide is relatively silent in these areas but there’s plenty of good information available from OGC and the Association for Project Management in the UK.

Finishing a project
Whilst the project manager needs to be aware of the value proposition for the project, to assist in decision making within the project, the project manager can only be responsible for delivering the required outputs optimised to the needs of the organisation. The rest of the value chain is dependent on the organisation’s line managers making effective use of the outputs to change the way the business actually works and instigate positive changes to realise the benefits that create value to the organisation.

For more on this topic see two earlier blogs:
- Value is in the Eye of the Stakeholder
- The Scope of Change

More in a couple of days on understanding the degree of certainty involved in projects.

Defining Project Scope

If a project’s client cannot ask for what it needs, the project team is highly unlikely to deliver what’s wanted!  A key element in effective project stakeholder management has to be asking enough questions to ensure everyone understands what the project is to deliver.

On Thursday 20th November 2008, I was privileged to attend the launch of a new report,  ‘Scope for Improvement 2008’, focusing on the issues of scope definition in major Australian construction projects. The total value of projects surveyed was approximately AU$60 billion with an average project value of AU$360 million.

The 2008 survey has shown a slight deterioration from the initial 2006 survey, in the overall performance of the industry in developing adequate project scoping documents. The 2008 findings also show inadequate scope specification is now an endemic problem in Australia with a growing trail of budget blowouts, delays and disputes.

The worry is the construction and engineering industries are generally seen as being far more mature in their project management practices then most other sectors of the project management industry and Australia has one of the more advanced industries world-wide. The key findings from the report, outlined below, are a salient lesson for anyone involved in defining the scope for a project:

Key Findings and Recommendations of the report:

The present situation:

• There is a high prevalence of deficient scoping in Australian construction and infrastructure projects with over 50% of projects being inadequately scoped prior to going to market.
• Scoping inadequacies are being discovered far too late with 64% of deficiencies only being discovered during execution.
• The consequences of poor scoping are significant: 61% of project experienced cost overruns, 58% delays and 30% contractual disputes.

The main factors contributing to poor scoping:

• Lack of experienced and sufficiently competent personnel with 83% of projects reporting adverse effects. This is to an extent explainable by the construction boom of the last few years but compensating factors such as increased time and/or contingencies do not seem to have been allowed.
• Insufficient time to prepare the scope documents.
• Inadequate definition of project objectives by the principal resulting in subsequent changes to the scope and corrections to the scope documents.
• Lack of consultation with end users, insufficient clarity of objectives and a lack of understanding of why the project is required and the benefits the project will produce.
• Insufficient research to understand the environment the project will be executed within.

Practical steps for successful scoping:

• Industry needs to think and act differently.
• Clearly identify project objectives.
• Identify and bring together all relevant stakeholders and end users for the project and maintain their involvement in the scope definition process.
• Set realistic timeframes and budgets for developing the scope requirements (and the overall project).
• Interface the proposed project with related projects and existing infrastructure.
• Identify and establish a core project team early.
• Empower a project leader with appropriate and clear authority and accountability.
• Clearly describe the project objective and requirements once identified.
• Choose the right approach for scope description (performance criteria, detailed specification, etc) and choose the right contract delivery model that aligns with the scope – risk needs to be properly apportioned.
• Check the overall contract package for consistency.
• Involve the tenderers / project management team in getting the scope documents right.
• Capture the value from a successful bid in the final contract.
• Resolve scoping issues and disputes under a contract.

The research was conducted by partners at Blake Dawson with support from the Australian Constructors Association and Infrastructure Partnerships Australia. A full copy of the report can be downloaded from http://www.mosaicprojects.com.au/Resources.html#Construction