Skip to main content
 
au

  • Increase Speed to Market
    Deliver quality quicker by optimising your delivery pipeline, removing bottlenecks, getting faster feedback from customers and iterating quickly.

  • Enhance Customer Experience
    Delight your customers in every digital interaction by optimising system quality and performance to provide a smooth, speedy and seamless user experience.

  • Maximise Your Investment
    Realise a positive ROI sooner and maximise your investment by focusing your energy on high-value features, reducing waste, and finding and fixing defects early.
  • The Wellington City Council (WCC) wanted to deliver quality outcomes without breaking the bank. Find out how Planit’s fast and flexible resources helped WCC achieve this goal.

this is a test Who We Are Landing Page


INSIGHTS / Articles

Who cares about quality?

 23 Feb 2012 
INSIGHTS / Articles

Who cares about quality?

 23 Feb 2012 

ABSTRACT: This paper presents a method for assessing the levels of care about quality on an IT project. It can then be used to stimulate discussion about and give visibility to a team’s ownership of quality.

Starting Point

An IT project is a complex entity, but no matter how complex, if a simple key driver such as the level of care about quality is missing, the outcome will be uncertain at best. How might teams or individuals protect themselves from failure caused by a lack of care about quality?


I recently spent the majority of my time on an IT project managing the consequences of a stakeholder’s lack of care. It is a simple enough assessment of how I spent my time and energy, but there were multiple stakeholders who cared about different project outcomes. Does my simple assessment do justice to the full picture? In this paper I want to evaluate who cared about delivering a quality project, and present a simple method for doing this that can be applied to any project.

I was engaged as Test Manager by Bigcorp on the Data-On-Demand project. It seemed like an unpromising opportunity – it took three kick-off meetings to get it going.

For the purposes of this paper, I take quality software to be: software that is useful, functional and reliable, delivered at a reasonable cost, within a reasonable timeframe, summarised as:

  • Functional – the product works
  • Reliable – the product always works
  • Valuable – the projected product benefit outweighs its cost
  • Timely – the product is delivered in sufficient time to realise its value

Jack, the Delivery Project Manager told me in a moment of frustration that the Vendor Project Manager, on whom I was dependent for information and issue resolution, had a Care Factor of Zero. In other words, he didn’t care. One subtext being that I should lower my expectations of the service he could provide testing. Another subtext, supported by other conversations with Jack, was that he had a Care Factor of Maximum. By association, it was implied that I was also a member of the group that cared about the end result and the ways in which a quality result could be achieved.

Since ‘Care Factor’ is just a figure of speech, I didn’t have any artefacts to refer to – such as the Care Factor Grading Table or Total Project Care Factor Estimate. But in the same way that risk is identified and managed during the life of a project, why not care? Maybe it is common sense – but a little investigation into what is considered common sense could be very rewarding, especially if we take Gerald Weinberg’s maxim that “If you don’t care about quality, everything else is trivial”, to be true.

The Client, Bigcorp (Australia) engaged a Vendor, EuroNet (Europe & World) to deliver a tool to be used by Customer Service Representatives in India and Tasmania. A separate division of EuroNet was also responsible for managing the Bigcorp infrastructure. The tool, “Data-On-Demand” was ostensibly a commercial product that was being upgraded and delivered to clients around the world.

There now follows an assessment of ‘care about quality’ for the Data-On-Demand project, which will be translated into a factor so that we can evaluate it as a component of project dynamics.

A review of some of the challenges presented to testing suggests a significant gap between the Vendor’s and Client’s care for quality . For example, the existence of a clearly communicated plan for the delivery of the software including phased quality checks supports a claim that quality is important, since this mitigates risks associated with functionality, reliability and timeliness. No plan or evidence of risk mitigation was provided by the Vendor.

The test basis was a Solution Design document. This proved to be inaccurate and out of date.

The Vendor’s developers worked in Europe and were unavailable for consultations.

The Vendor PM engaged the Sales team to answer technical questions. Instead, they spent time selling the Next Big Thing to end users and other project members.

EuroNet Software engineers could and did apply fixes and configuration changes to components in the Bigcorp environment as they wished, despite Bigcorp’s explicit requests not to do so.

After two months of issues and requests for a conversation, the EuroNet architect attended a webinar where application problems were demonstrated and discussed. He in turn provided a presentation on suggested solutions. He cared about functionality and reliability, but seemed constrained in his availability.

Given their approach to mitigating risks to quality, it would be hard to argue that Euronet cared significantly about any of the key components of quality.

For the Client, Bob, the Program Project Manager was pragmatic: Clearly this was not a commercial off-the-shelf product as the Vendor had claimed. What he needed was evidence in the form of test results so that he would have leverage in future contract negotiations. He cared that the product was functional, but he also held a long term commercial perspective that would allow him to accept something ‘good enough’. He cared most about value.

Bob engaged Jack to deliver the project. Jack championed timeliness and supported all efforts to secure a functional and reliable product.

In order to provide the Program Project Manager with the value he needed, the Test Manager was hired to care about functionality and reliability.

The BA cared about functionality (including ease of use), reliability and timeliness.

The above assessments will be translated into a factor. The number of factors will be kept small to reduce complexity and will be applied at the level of role. The purpose of this is to depersonalise the ownership of care in order to better understand project level dynamics.

The Care Factor

The Care Factor is a number indicating the level of care about quality exhibited by person, role or organisation.

Swipe to see more
Care Factor
Description
0
Doesn’t care about quality
1
Cares about quality as it affects them personally
2
Committed to a good enough outcome for the project
3
Committed to a best quality outcome

Based on the assessment on page 2, we can create a table of roles, quality components and care as below:

Swipe to see more

Table 1: Data-On-Demand Care Factor

 
Role
Functional
Reliable
Value
Schedule
Total
Client
Programme PM
2
3
3
3
11
 
Project Delivery PM
3
2
3
3
11
 
Test Manager
3
3
2
2
10
 
BA
3
3
2
2
10
Vendor
Vendor PM
1
0
1
1
3
 
Product Line Architect
2
2
1
1
6
 
Product Line Developers
1
1
1
1
4
 
Sales
1
1
1
0
3
 
Total Care Factor Points
16
15
14
13
58
 
Average Care Factor
(Actual/Max*3)
2.0
1.9
1.8
1.6
1.8
 
Client Care Factor
2.8
2.8
2.5
2.5
2.6
 
Vendor Care Factor
1.3
1.0
1.0
0.8
1.0

Note: Average Care Factor is calculated as Actual/Maximum Possible (in this case 8 roles X 3 points = 24) to derive the percentage, and then multiply by 3 to derive the overall Care Factor for the component or project.

We can also diagrammatically represent the data:

Diagram 1: “Data-On-Demand” Care Factor Distribution

Commentary

In Diagram 1 we can see the disparity of Care distribution, whereby the majority of Care is owned by the Client. The purpose of this diagram not necessarily to tell us something that we don’t already know, but to give us a way to objectify the information we have in such a way that it can be used as a project or personal tool.

Given that this approach has been applied retrospectively to one project only, the full range of uses and interpretation of the numbers is speculative, but I believe this simple tool can be effectively used in at least 2 ways.

Firstly, quality can mean different things to different people, so understanding and resolving those differences before starting a project could make a significant difference. The Care Factor table could be used by the Project Manager during a project initiation meeting or by the Test Manager before a risk workshop as a way to provide clarity about who cares about the various components of quality. This could result in a change in the way the delivery of quality is approached. For example, one outcome could be an improvement in shared ownership for quality, which would be a strong mitigation for the risks inherent in only having one or two people “own” the quality of the project outcome (often, by default, this responsibility falls to the Test Manager).

Secondly, as a part of an individual or project review process: For myself, the process of deconstructing the ownership of care on a project I worked on has given me a way to look at how other people regard quality, and to challenge my own assumption that people seeking to deliver a project ipso facto care about quality in the same ways. The Care Factor table can be easily set up in Excel to reflect different projects and parameters and can quickly turn subjective observations into care data as part of a personal review process. Likewise, it could be utilised at a team or project level review by a Project Manager or Test Manager to reflect differing approaches to quality throughout the life of a project. This kind of assessment would have a 360° viewpoint. Each team or role could quickly produce a diagram that could be shown to other team members for feedback and discussion.

Quality, what it means and how it can be delivered needs to be on the agenda on every software project. This simple tool could help achieve that.

Download Whitepaper

Deliver Quality Quicker

At Planit, we give our clients a competitive edge by providing them with the right advice, expert skills, and technical solutions they need to assure success for their key projects. As your independent quality partner, you gain a fresh set of eyes, an honest account of your systems and processes, and expert solutions and recommendations for your challenges.
 
Find out how we can help you get the most out of your digital platforms and core business systems to deliver quality quicker.

 

Find out more

Get updates

Get the latest articles, reports, and job alerts.