DO I NEED TO BE A SOFTWARE DEVELOPER TO UNDERSTAND THIS MATERIAL?

Obviously, the more you know about software development, the better you will be at managing development projects. You don’t have to be an expert in software architecture, design, development, and validation to apply these measures, however. You only have to be a facilitator.

There’s no reason why you can’t involve your project team in architecting and implementing your measures. In fact, there’s one very good reason to do so: ownership. Development teams are more likely to see the value in measurement if they have had input into the measures and how they are going to be used. Draw on their expertise and experience when identifying causes for run-rate variances. Have them determine the best measurement points for defect injection phase measures, or the categories for time and effort measures.

A few team brainstorming sessions early in the project will not only help you identify and specify your measures, but will serve as good team-building exercises as well. Laying out the workflow on a whiteboard as a team exercise is a good place to start. You might be surprised to find how little one group knows about another group’s responsibilities or about how their group’s activities impact other groups. After that, work through some of the exercises with your project team (particularly those at the end of Chapters 1, 2, and 4). These can be very helpful in coaxing implementation details out of your project team.