For example, an IT department may be tasked with rolling out an accounts payable system. If it just considers the technology aspects of that rollout, it could easily overlook usability-related issues. A framework, however, should require assignment of a product management role. This person is responsible to ensure that the project satisfies its customers. The role could include a focus on marketing, developing, and measuring business value, and prioritizing requirements. A framework might provide that the project manager should never be the product manager, as the roles oftentimes are at odds with one another. The project manager is oftentimes motivated by schedule, whereas delivering features motivates the product manager.

A firm should define not only a framework and standard process but also standard documentation. When drafting an agreement, a lawyer seldom starts from a blank Word file. Most lawyers use prepared precedents, or past agreements, as a starting point. These provide structure and key terms. They keep the lawyer from reinventing the wheel at the clients expense. The same should be true for project managers.

Especially on smaller projects, it may be the first time a person has acted as a project manager. The person may be a skilled technician, but not a skilled writer. A standard document template can speed up the planning process. Even for skilled project managers who write well, a standard document template can ensure best practices are followed and keep them on the essential points, shortening the documents delivered.

Documents should be well focused. They should be written for their intended audience. A document that describes the projects objectives, scope, business justification, and budget, and is intended for steering groups and partners to read before the project is approved should be jargon free. A detailed design specification may be jargon rich.

Documents should be short. The goal is to communicate. If you e-mail a document to someone, who sees that it is 67 pages long, it is likely he or she will either simply scan it or put it aside for later. If, however, it is 5 pages long, it is much more likely to be read. If your documents never exceed 5 pages, reviewers will become accustomed to this, and you will receive better feedback. Break longer documents apart to focus on issues for particular audiences if need be, but always keep them short.

Speed of implementation can be critical in a competitive market (e.g., whether to meet a clients standard billing requirements, to provide an extranet, or to make an existing process more efficient), but it can be difficult to balance speed against the need to select the right system and establish clear user requirements and buy-in around the firm.

A firm should phase and structure projects to deliver substantial value quickly and then follow up by providing the remaining requirements in a later phase. This approach is referred to as quick wins. Phasing and structuring allows projects and baseline efforts to deliver key requirements quickly to meet the stated business demand. Requirements that are less

critical or simply harder to deliver will be scheduled for later phases of the project to allow progress on the immediate requirements. The quick win strategy, as a part of your project methodology, can increase customer satisfaction and reduce the projects exposure to risk.

A project framework, form documents, and a quick win philosophy provide certain economies. They keep project teams from reinventing the wheel. They allow you to identify, coordinate, and control project interdependen-cies. They help you move quickly to deliver value. But, perhaps most importantly, they allow the project teams to focus on the real issue, delivering the project, and improve the chances that the project will be on time, within budget, and deliver the expected value.

Project teams want to succeed. A project, however, is a minefield where ignoring principals of change management or working to the wrong requirements or underestimating the effort can make even a project that delivers what it promised look to its customers like a failure. A project framework rigorously applied can help avoid these mines. It also provides the project team comfort that it is proceeding properly and, as a result, instills an attitude of success.

A valid business justification should support every project undertaken at a law firm. This concept is easy to understand but oftentimes is hard to put into practice. Since projects cost money, it is best to justify them with money arguments. That approach is not, however, always feasible. A project might be justified because the firms biggest client demands it. A project might be justified because it fits the firms strategy. A project might be justified in that it makes life easier for the firms attorneys, even if there is no direct financial gain. In short, there is no one-size-fits-all solution to determining business justification. There are, however, some accepted and customary approaches that should be considered.

For projects that will provide a direct and readily measurable income stream or cost savings, a financial analysis may be appropriate. This analysis can take many forms, but usually it includes a spreadsheet of project and ongoing operating costs set against income and cost savings over time. The project may be justified from a business perspective if this analysis shows the project breaks even or shows gain within a reasonable time period. This does not mean, however, that other nonfinancial issues should be ignored; this financial analysis is one justification, not necessarily the whole story.

For example, assume a mid-size office is considering whether to implement an automated fax solution for an office. The solution has a project cost (hardware, software, personnel resource cost) and an ongoing cost (software and hardware maintenance and support). The solution also provides financial benefits. It replaces a mail room employee. It provides an income stream through cost recovery (net of what was previously charged, if any). Comparing the costs involved with the costs saved and potential income and factoring in the potential that e-mail is replacing faxing (this requires an assumption as to

the replacement rate), the firm can calculate whether this project will make or cost them money. This is a financial analysis.

Some businesses apply various financial measures. Some apply a payback period analysis where there is a set time frame within which a project must show a net positive for project approval. Some businesses apply a net present value approach, which requires a calculation of potential income stream in the future and potential costs in the future. If the project has a net positive present value, it is more likely to be approved by the firm. While this distinction is interesting from a theoretical point of view and may be a good way to set thresholds in other industries, a professional service firm likely uses a simpler calculation by just determining whether the project has a net positive or negative cash flow.

While a financial analysis should be conducted where appropriate, nonfi-nancial considerations normally play a major role in justifying projects. For example, the payback on a knowledge management application is typically long and would likely have a net negative value. In this case, these types of projects would never be approved if qualitative improvements were to be made. One argument for a knowledge management system is that it will reduce the time to prepare work product and improve the quality of that work product. Since law firms sell time, billable hours, adopting such a system would reduce the number of billable hours sold while keeping the same number of production use (the producers) lawyers. Therefore, from both a net present value and a payback rule perspective, a knowledge management system would not be appropriate.

Another issue with financial analyses is making valid assumptions. If you include cost of funds or a discount rate, how do you select them? A small change in that rate can change the financial viability of the project. In our previous fax example, if you assume a rate that e-mail is replacing faxing, how do you determine the correct rate to apply? If you have a way to measure this historically, for example, using manually recorded historical data available in your accounting system (if you billed clients for your manual faxes), you likely have some valid basis for such an assumption. Otherwise, consider ignoring the variable in your actual financial analysis and noting it textually as part of the overall justification. This avoids being seen as selecting values to make the analysis work. (Remember the adage: Figures dont lie, but liars figure. )

In short, use financial analyses when there is good solid financial data, but dont stretch to make such an analysis. When you do, present the numbers you are confident with, and note the other factors in your textual discussion.

We refer to a third method for valuing projects as the obscenity method after the U.S. Supreme Courts Associate Justice Potter Stewart said, I cant define obscenity but I know it when I see it. 7 Many partners look at projects and have an intuitive belief as to whether the project is justified. The problem here is that partners intuition may not validly reflect