Log In to My ASQ



Log-In Help

Register with ASQ

Sign up for access to ASQ's free articles, case studies, and general information. For more access, join ASQ.
Magazines & Journals
Software Quality Professional

Printer Friendly
Issues
I Want To
Article Access Key
  • Public Article
  • Log-In to View

June 2000
Volume 2 • Number 3

Contents

A Study of Schedule Slips in a Large Firm

Editor’s note: This contribution is the first in a series of short reports that SQP intends to publish, conveying insights directly from the trenches where software quality is practiced on a day-to-day basis.

Key words: estimating, leadership, management style, project management

by Milt Boyd

INTRODUCTION

A large firm was plagued by time-to-market problems. Most software products depended upon several projects completing their work. If any project slipped its schedule, then the product was likely to be delayed. I was charged with determining what aspects of a project correlated with schedule slips. The usual suspects were: a) project leader characteristics, such as experience or education; b) project characteristics, such as size, novelty, or complexity; and c) project member characteristics, such as background or experience. The hope was that, armed with foreknowledge, management could prevent or reduce the occurrence of schedule slips. Leaders and members could be assigned projects suitable to their talents, experience, and background. Project characteristics could be flagged to warn management of danger.

PROPOSED METHOD OF ANALYSIS

It was proposed that I identify a half dozen “good” projects and another half dozen “bad” projects. I could interview the players and their managers, and examine the documentary records, including selected personnel files. I could then do a compare-and-contrast exercise to find the factors shared by the good projects and the factors that distinguished them from the bad projects. I was suspicious of this method. It was not clear to me that there were good and bad projects. I had some experience with projects in different parts of the firm, and I had found that all projects experienced much the same difficulties. Rather, I thought it likely that all the projects formed a single population, with tails. There might be several overlapping populations. In that case, it would be good to start with the whole, and then break it into subpopulations.