Managing Client Expectations with SLIM-Control
ChallengesJim Kirk, a software quality manager for a major medical equipment supplier, was brought in to track the progress of an 8-9 month old software project. The project (called BSR, or Bild System Roentgen) employed a team of 65 engineers to build cardio imaging software for internal clients in Germany. They, in turn, would assemble the equipment and ship it to an end user. Jim’s German clients complained that they were receiving unfinished, unreliable software that compromised the firm’s reputation for delivering high quality products. A big part of the problem was the schedule: because the team never sanity checked the project plan in SLIM-Estimate, they had committed to an unrealistic schedule which fell further behind each time the client added new requirements. Requirements volatility only complicated the problem: a project originally estimated at 250k lines of C++ code had grown to more than three times the baseline size.
SolutionLeveraging nearly 10 years of experience with SLIM products, Jim’s reaction was swift and decisive. He suggested using SLIM-Control to determine the rate of schedule slippage. Each month the development team entered a few core metrics into SLIM-Control. The schedule forecast revealed that development was falling 2 months farther behind with every elapsed month of schedule time. The reliability picture was even bleaker: each month the project fell 3-4 months farther behind the quality goals for delivery. The forecasted reliability at completion was only 55% of the target quality goal. Using SLIM-Control’s Consistency View, Jim compared BSR to QSM’s industry database and several similar systems from sister companies. Against these benchmarks, BSR program was competitive for effort, cost, and staff size. Quality was another matter.
OutcomesArmed with evidence from SLIM-Control, Jim was able to demonstrate the impact of requirements growth on quality and schedule. His German clients quickly realized the true “cost” of unrealistic schedule and constant requirements changes. Jim convinced them to cut down on requirements changes and provide enough time and money to achieve their quality goals. This was a “win” for both developer and client: the team was able to stop runaway schedule and requirements inflation and his clients got the high quality product they expected.