Focus Your Project

						
© 2003 Johanna Rothman, www.jrothman.com

						
Do you ever wonder what you're really supposed to focus on for your project?

						
Companies create a variety of products, and different releases of those products, for many reasons. Some product releases can tolerate glaring defects; others have to be extremely reliable. Some releases are bound by time to market. For other products, the customers will wait. Some releases are loaded with features; other releases have a minimal feature set.

						
The goals for quality, schedule, and features for a project are intimately related to the reasons for creating the release in the first place. Since the definition of quality is determined by the goals you’re trying to achieve, you need to define quality for your project, and figure out what you need to focus on.

						
Each project has one, and only one, of these goals as its top priority, and then addresses the other two goals within that context. This prioritization determines the tradeoffs the project manager and staff will make during the project, and should help define the product development process to use in developing the product.

						
An honestly designed project has two priority thresholds: the absolute bottom line and everything else. The bottom line is generally implicit—unless the top management is clueless, if a product destroys the hard drive of even 5% of the testers, the product will not ship even if time-to-market is the dominant priority. Why? Because the organization knows that shipping a destructive product will decrease its market share. In the same way, there is an absolute limit to features. A release has to have something new, even if there is just a requirement not to wipe disk drives. It might be a very minimal requirement, but it exists.

						
Project focus is about making "everything else" explicit. One way to focus priorities for a project is to use Geoffrey Moore’s high-tech marketing model to understand the market imperatives. Table 1 provides a view, based on his model, of the interaction between the definition of quality and the product lifetime. The users (and potential users) have different perceptions of product quality over the lifetime of a product.  The chart shows how the three possible priorities are sorted for different classes of users. As a product evolves, it moves from one target user group to another, and (in the model) the priorities shift accordingly.

						

							Table 1: Quality Perceptions over Product Lifetime
							
								

  Product
  Life/ Market Pressure
  Introduction

										(Enthusiasts)		
  Early Adopters

										(Visionaries)		
  Mainstream

										(Pragmatists)		
  Late Majority

										(Conservatives)		
  Skeptics

										(Laggards)		
 

								

  Time to Market
  High
  High
  Medium
  Low
  Low
 

								

  Features
  Low
  Medium
  Low
  Medium*
  Medium
 

 

  Low Defects
  Medium
  Low
  High
  High
  High
 



						
* Medium pressure for features does not mean pressure for new features. It means that the promised features must be in the product and must be working.

						
If you're working on a product for Visionaries, you want to focus on time-to-market, not terribly low defects. If you're working on a product for Pragmatists, you want to focus on low defects, not time to market.

						
I worked once on a project where the developers thought they were working on a project for Pragmatists. Management thought they were working on a product for Visionaries. Management panicked when developers missed a milestone about 6 weeks before expected ship. The developers' priorities were low defects; time-to-market, then the feature set. Management's priorities were time to market; feature set; and then low defects. 

						
Since management realized they were not going to meet the original schedule with the original features, they then asked for anything the developers could get done in the next six weeks, to meet the original dates. Since the project focus was not explicitly stated, the developers did not change how they were working. The developer's priorities remained the same. 

						
This change of focus happened twice more, where management reduced the feature set, accepted higher defects, to get the product to ship as early as possible. SmartStore's product development process was not flexible enough to accommodate the shifting goals, and the project manager was not capable of explaining to the organization how the shifting goals would prevent the project's success. 

						
After three sets of shifting goals, the Test Manager realized they might never ship a product. The Test Manager then chose specific product goals (a certain smaller set of features, moderate defect levels including performance no worse than the previous release, and an aggressive time to market) and formulated measurable release criteria. The project was complete when the release criteria were satisfied.

						
Even with all these goal changes, the product development activities did not change until the final product goals were defined. The development staff never understood the goals and what they needed to do to make those goals. Throughout the entire process, the product developers spent most of their time fixing defects to make a (lower priority) market ship target. 

						
At the end of any project, defect-fixing is the main activity, it’s the choice of which defects to fix that is the most interesting. At the end of this project, the developers were able to consider which defects to fix, based on the release criteria.

						
If you've ever found yourself in the dilemma of shifting project goals, then consider how you focus your project goals on low defects, time to market, or features.

                

        
 Email this article to a friend.

        

        
Comments to: