Selecting the best organization in the company to head a software project isn\'t always easy.

At times, the first decision made on a software package implementation project determines its success or dooms it to failure. This decision is usually arrived at with little thought, or is determined by company tradition (i.e., with no thought at all). With either method, executive management may be rolling the dice on a multimillion-dollar project. Their instinctive choice of the organization within their company to \"own\" an implementation is usually the most important one they will make.

My company is often involved with these decisions, or in dealing with their aftermath. Poor choices are the source of many of the problems we find, so I would like to challenge your thinking on this subject. Some day, you may \"choose to choose.\"

What indications are there that your past choices have been appropriate? Certainly no one can argue with success. After filtering out the normal complaints of departments undergoing organizational changes that new systems create, look for some measurable criteria for success in your past projects:

• Backlog of projects less than 18 months.
• Project expense within 30 percent of original estimates.
• Project milestones within 90 days of original plan.
• System functions at initial implementation closely resemble or exceed original plan.
• Visible, positive change in user organizational procedures and staffing patterns.

A \"no surprises\" implementation history like that indicates the right organization is in charge. If you aren\'t seeing these success criteria every time, you might want to revisit the question of project ownership.

Unless history provides compelling reasons not to select the Information Technology (IT) unit to head the project, this is the most usual choice. After all, they are often seen as the company experts in both data processing and project management. Certainly most IT organizations would find it difficult to decline ownership due to their self-perception of expertise in such matters. But this self-perception of expertise is often a compelling reason not to choose IT. The phenomenon of the IT organization assuming responsibility for defining functional content of the delivered system and/or the way it is tested and delivered to the users is so common in our experiences to become a cliche. IT is I honest in its motivations to do this. They reason, \"We know best what our company really needs in computer systems.\" If you find this message implicit in your own thinking or in the thinking of your IT management, be careful. Look at your alternatives.

In most of these projects, the critical factors are human and organizational rather than technological. The best software package, with top-notch technicians behind it, may linger in a twilight zone for years if the intended users do not accept the product or support the project.

Since functionality and reliability are essentially user-acceptance concerns along with documentation and training, user perception of these criteria is ultimately the measure of success for the project. The user organization is therefore an attractive candidate for the job of managing the project. We have found that it is often easier for a user organization to acquire project management, software product and implementation skills than for the majority of technical organizations to develop a sensitivity to the user/business issues that often surround an implementation.

Another attractive option is the task force or \"special project\" approach. Headed by a staff-level project manager usually reporting directly to the chief financial officer (CFO) or chief operational officer (COO) of the organization, these teams are often highly successful. Advantages of this approach include objectivity (neither IT nor the user?s project), visibility (with positive effects on morale), and clout (if the staff manager reports high in the organization). The problems you will experience with this are either political in nature due to the basic shortcomings of matrix management. Don\'t focus on the short term problems to the exclusion of long-term benefits; each of the matrix management problems has a solution.

A variation of this idea is a permanent staff organization to handle all implementation projects in a ma management mode. Conceptually, is a good idea if you have a series of projects on the docket. In practice, it may routinize or bureaucratize projects that are notably not routine. It is a viable approach if it is carefully managed to retain an implementation (read as "get-it-done\") mentality.

Assuming you conclude that a s in project ownership is necessary, there are a few things that will greatly reduce any associated trauma.

Avoid mid-project shifts in responsibility unless the project is \"on ropes.\"

Publicly characterize the shift as experiment, and try it for a single n project.

Make sure that sufficient train and tools are available to the receiving organization

to let them assume a project management role.

Take the time to produce written roles and responsibilities for each, affected organization.

This minimizes ambiguity often associated with organizational shifts.

You may find it helpful to consider such a shift a long term process and proceed with a carefully measured pace of change. With the right organization controlling your projects, and with managers suited by attitude and experience to their responsibilities, chances are good that you never have to say you\'re sorry.