Next Up Previous Contents Index
Next: Corporate Functions Up: Product Lines Previous: New service centers:

Existing Organizations Proposed As Service Centers

In this proposal, technical publications would become a service center. Though some of the product lines may employ a number of writers full time, the requirement for writers and for publication production varies over the course of the product life cycle. The publications group also supplies a level of format standardization that gets regular praise from our foreign subsidiaries.

The Build group could conceivably become a service center. If the GMs were to decide to continue to use the Build group as it stands, it would continue in its current form, with the addition of a bill-back process so the GMs and PMs account for how much money they've spent on builds. If most of the build work were to move inside the product lines, it would make more sense for the people remaining in the build group to move to Developer Services, from which they could sell build services along with other software-related services. Even if the Build group were to be completely dismantled, it would be necessary to develop a guideline document for the build process, and to maintain a ``certifying agency'' that checks to make sure that source and object files track one another, for QA purposes. This certification agency could be independent, run from Developer Services, or what could be more appropriate, the certifying action could be performed by the QA organization, since QA is the group for which the certification is being performed. This proposal suggests putting the build certification process with QA.

Dev Test has a similar relationship to becoming a service center: if the PMs wish to use Dev Test services through a service center, it would continue in its current form. Otherwise, some Dev Test people will go with the products that they work on full time, and the others will join Developer Services.

This proposal assumes that many of the people of Dev Test and Build will go into product lines, in which case the rest would be merged together into the Developer Services organization.

QA is a most difficult case. One can argue that QA should be an overhead function, not a service center: if a product goes out the door with serious flaws, it reflects on the whole company, not just on an individual product. Therefore, it is in the best interest of the company to eliminate any disincentive for using this service, such as direct costing to the product line. On the other hand, such a quality black mark is not as damaging to the company as some kinds of legal problems: as the Microsoft Word 3.0 fiasco demonstrated, you can ship an utterly vile product and still retain your reputation for being the superstar of the industry, indeed without even noticeably impairing your premier status in the market.

It is also possible to argue cogently that QA should be a part of the individual product line. The General Manager's incentives with respect to individual product are essentially identical to those of the President of the company: they are focused on the long-term welfare of the product, and suffer from neither a technical team's natural inclination to ship sooner rather than later, nor a QA team's natural inclination to ship later rather than sooner.

On the other hand, breaking up the QA process would reduce the application of QA standards across the company; and on the third hand, breaking up the QA process might result in some interesting innovations in QA methodology.

The middle course is to keep QA as a service center while we see how the rest of the restructuring plays out. This proposal recommends keeping QA as a service center. Our current QA department supports a number of processes other than software testing, which is the service center part of QA; these other activities may be more appropriately operated as overhead operations. The FM of QA should come up with a proposal on this matter, as discussed as a general need for FMs earlier in this paper.

Technical support would become a service center as it is already divided into product lines.

Training could conceivably become a business unit. This, however, would involve making a change in the corporate strategy, since a profit-motivated training center would want to compete, in some sense, with our distributors. For the moment, this proposal recommends making training a service center as well.

Sales could fit any of the three categories of organizations.

Whether thought of as a corporate function, or viewed as a business unit. the underlying dynamic for the sales group is the commission structure. Commissions take sales outside the breakout into business units, service centers, and corporate functions.

Sales could also be made part of individual product lines. Not having sales as part of the product lines could disenfranchise the PM and GM from a very important part of the process of getting the product into the customer's hands. On the other hand, sales is also the critical point at which the company and all its products are presented to the distributors and customers as a unified family. Certainly, even though sales is kept together as a single organization, it would make sense to have a structure internal to sales that can parallel the product families (i.e., have people in sales devoted to selling each product family).

This proposal recommends making sales a service center. This would allow the PM to trade off marketing expenditures with sales expenditures. Having a structure inside sales that parallels the product families would facilitate its setup as a service center.

This proposal further recommends keeping the retail sales organization at Generic separate from the sales organization in Sausalito, although this situation warrants further review.

General procedure for moving people from service-like existing departments to the new structure

For some people, there may be multiple, functionally similar locations in the new structure for them to move to. An author who works nearly full time on AutoCAD, for example, could reasonably continue in that role either as a part of the tech pubs service center, or as a member of the AutoCAD product family.

Here's a proposal for how these negotiations should be carried out:

The product manager chooses whether to make an offer to the individual to join his/her product full time. The individual then has the choice of joining the product line, or staying with the service center. There is one point the individual should be aware of if he/she chooses to stay with the service center: the product manager has the authority to hire a full-time person to undertake the individual's existing tasks inside that product line. If the PM does this, then the individual will of course find his job altered, since the PM will have effectively hired a replacement for the existing job.


Next Up Previous Contents Index
Next: Corporate Functions Up: Product Lines Previous: New service centers:

Editor: John Walker