When a project delivers the expected product on time and on budget, Delivery Quality is an essential part for turning a merely satisfied customer into a returning one. However, many projects fail to meet customers’ expectations, posing the question if Delivery Quality is still relevant and the underlying decomposition is still valid. The case study shows that Delivery Quality is still relevant to the project when product quality clearly is lacking: Delivery Quality might be a requirement for being able to rescue the project. The case also shows that the decomposition of Delivery Quality into underlying factors has issues: the factor Transparency is clearly missed, and the factors Responsiveness and Partnership are too narrowly defined. Especially the lack of the factor Transparency is considered critical, since in this case the lack of Transparency led to a quite abrupt abortion of the project.

1. The role and decompesition of
Delivery Quality in a Failing Project,
a Case Study
IASTED SE 2016, Innsbruck
Jaap van Ekris, Senior Consultant
J.vanEkris@Delta-Pi.nl

2. Project success
• Narrow definition:
– Time, Budget and Product
• Wider definitions:
– Include Customer Satisfaction
– Include Rebuy Intentions

3. “Rebuy Intentions” is a tough goal

4. Factors in Rebuy Intentions
Delivery Quality
Product Quality
Functionality

5. A decomposition of Delivery Quality
• Extended SERVQUAL decomposes delivery quality as:
– Reliability, The supplier keeps his promises;
– Empathy, The supplier understands the industry, actively
thinks about the solution for the specific customer;
– Partnership, The supplier actively strives for the same
goals as his customer;
– Responsiveness, The supplier responds quickly to
questions and change requests;
– Knowledgeable acting, The supplier has a good reputation
and shows its technical experience;
– Tangibles, documents and materials look good.

6. A Failing Project
• Replacement of a mission critical system
• COTS product, developed by a highly
specialised company
• During the implementation of the product,
the project was aborted due to product
instability

7. Critical Incidents identified
- Product Instability
+ High commitment of support personnel
+ Excellent domain knowledge
- Inadequate fixes in production environment
- Lack of Transparency about architecture
problems

8. Attribution of “Commitment Personnel”
Respondent Attribution
A Mentioned in the CIT, attributed to Partnership
B Mentioned in the CIT, attributed to Partnership
C Mentioned in the CIT, attributed to Partnership
D Mentioned in the CIT, attributed to Partnership
E Not mentioned
G Mentioned in the CIT, attributed to Partnership

9. A higher bar for “Partnership”
• The supplier strives for the same goals as the
customer
• The respondents clearly expected the supplier
to stand behind his product, and do whatever
it takes to let the product succeed at the
customers’ site

10. Attribution of “Inadequate Fixes”
Respondent Attribution
A Mentioned in the CIT, attributed to Responsiveness
B Mentioned in the CIT, attributed to Responsiveness
C Mentioned in interview, attributed to Responsiveness
D Mentioned in interview, attributed to Responsiveness
E Mentioned in interview, attributed to Responsiveness
G Mentioned in interview, attributed to Responsiveness

11. A twist to “Responsiveness”
• The supplier responds quickly to questions
and change requests
• The respondents clearly expected some
effectiveness of the quick response as well

12. Attribution of “Lack of Transparancy”
Respondent Attribution
A Mentioned in the CIT, not attributed
B Mentioned in interview, not attributed
C Mentioned in interview, not attributed
D Mentioned in the CIT, not attributed
E Suggested at interview, not attributed
G Not mentioned

13. The Impact of “Lack of Transparency”
The lack of transparency triggered a loss of trust in the
developer.
2 out of 6 respondents indicated that being more
transparent throughout the project:
• The customer would have allowed for more repairs
• The customer would have financially contributed to
refactoring/reengineering
• The project could have delivered a functioning product
in the end

14. Conclusions
• Improvements to the Extended SERVQUAL model:
– “Partnership” contains a notion of taking responsibility for
the products’ effects on the customers’ process
– “Responsiveness” contains a notion of effectiveness
– “Transparency” is a missing factor
• Delivery Quality can influence project outcome, even
when the product fails. It might buy enough time to
avert project abortion.
• A lack of Transparency can terminate a project, but
some customers rather live in the bliss of ignorance