Tag Archives: Software Development

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 collaborative management paradigm inherent in Agile – a new frontier

The Agile software development methodology has a fascinating range of ideas that can provide valuable learning’s to traditional project managers and in the wider sphere of stakeholder management.

Over the last few months I have been publishing a series of posts on this topic on the PMI Voices on Project Management blog. The key posts with a brief summary and links are:

Agile: The Great Debate
An overview of the Agile software development methodology and its impact on project management.

Creating Trust in Agile
Managing upwards, the trust and communication needed for Agile to succeed.

The Role of Agile Advocates
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements.

The Gentle Art of Managing Agile
Applying the PMBOK to managing Agile projects.

Learning From Agile
The importance of customer engagement and going ‘light and lean’.

I invite you to read these posts and think on your project management and/or stakeholder management practices.

Agile is NOT a Project Management Methodology

A range of IT commentators are confusing a product development methodology with project management. Agile is not an IT project management methodology any more than choosing to use pre-cast concrete in preference to brickwork is a construction project management methodology.

Agile is certainly a useful product development methodology for many IT applications and would probably be extremely useful in other situations such as developing training materials and many business change projects where most of the deliverables are relatively intangible. However this cannot turn it into a project management methodology.

Project management is the process of defining scope, deciding on methodologies, creating teams, and all of the other project management processes defined in the PMBOK® Guide. If agile is chosen as the product development methodology for an IT project it will certainly influence the way the project is planned, resourced and controlled but Agile itself is not ‘project management’. This is no different to the need to plan and execute a building project differently if all of the walls are delivered to site as precast panels compared to having workers build the walls in situ using bricks or blocks. If a project exists, project management is the overall controlling process not the selected work delivery process.

What is lacking in most commentary I’ve seen on Agile is any sensible discussion on using Agile within a project environment. The critical changes to scope management, change management, cost management and time management needed to effectively deal with the fluidity of Agile, within the constraints of a project, need discussion. Project Management is still about delivering optimum value based on a predefined framework of time, cost and output and managing changes within this structure.

It would seem many of the advocates of Agile are actually suggesting abandoning project management in situations where the client cannot really define its requirements and adopting a different form of management where conversations control the process development in a collaborative environment and the overall team’s focus is on achieving a ‘happy outcome’ for everyone. The primary constraint in this space is the resources capacity to deliver ‘sprints’ and the organisation’s budgeting process is focused on paying for a more or less stable team of people working consistently on improving the business’ IT infrastructure to service its operational areas.

This would suggest there are limitations to the traditional ‘project management’ paradigm (and I have always felt PM was a focused form of management – see Project Fact or Fiction from 2002) and the emergence of a different paradigm. If this observation is correct the real focus of discussion should be where PM works best and where the new collaborative ‘agile paradigm’ works best.

Comments are welcome and I will blog more on this idea later!!