Copyright © 1998 Cem Kaner (kaner.com) and Johanna Rothman Many project managers don’t know what to expect from a testing organization. They don’t know what the group does, how the product is going to be tested, when things will be done, what deliverables to expect, or how to find this information out. Complicating matters, some […]
Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule. Abstract Project management can be described as
© 1997 Johanna Rothman. Introduction Resistance, especially to process improvement, can take many forms and levels of intensity. Process improvement, the activities of changing how people work, can appear (and can be) very threatening to people. For some of us, it is difficult to see the resistance at first. We may think that people misunderstood
© 1997 Johanna Rothman. Abstract Recent writing in the software process improvement literature [1,2] discuss those organizations who start off at an ad hoc level (CMM level 1) and proceed to a repeatable level (CMM level 2) and higher. However, there are many organizations who cannot make progress towards level 2 until they have a
© 1997 Johanna Rothman. Abstract Organizations are spending more time and money on their testing and process efforts. But, how do you know whether or not the testing and process improvements efforts are paying off? One way is to define specific metrics to measure the effectiveness of your process, and the efficiency with which the
© 1997 Johanna Rothman. Abstract Product management is concerned with implementing new features. Developers are concerned with improving the existing features. How does a project manager bring these concerns together in a way that ensures both product direction and product robustness are addressed? One way to elevate competing concerns about implementing new or old features
Abstract If you manage software engineers, or software product development, sooner or later, you will be faced with a vexing problem: not all the people are in one place, or even in one time zone. This paper analyzes the problems associated with geographically distributed product development, and discusses possible solutions to reduce project risk. Real
© 1996 Johanna Rothman. This article was originally published in SQA Quarterly, May 1996. Product development teams are organized for one major purpose: to produce a product people will buy. Software product development teams have a secondary, but no less important goal- the ability to produce products again and again. To effect those goals, product
© 1996 Johanna Rothman. Introduction Many software organizations are working actively to improve their product and process quality. We can review their implicit and explicit management activities and ask: Which activities have had a positive impact on process and product quality improvement? Which activities have had a negative impact? We can then develop a list
Introduction Software product development is a difficult task. Not only is it mentally challenging, just to write and test software, but there are a number of interdependent problems when product teams attempt to create a product. Product teams have difficulties in these major areas: meeting the schedule, implementing the desired functionality, and removing enough defects