Management Buy-In: The most critical criterion is management buy-in. Each item in the following list can make or break a project. Management buy-in means the assessment of each item is documented and management has signed the bottom line. Quite often this is neglected with a busy executive saying, "just get it done." Then as resources are tapped to accomplish the following tasks, executive support evaporates.

Carefully Limit Scope: The scope of the project should be limited to the minimum 1st step. What is to be accomplished to get to the first useful implementation. Never set a target that requires too much staff adaptation. The 1st step should demonstrate time saving features, the reduction of human errors or standardized processes. Each release of an application must further the primary objective, improved performance, in such a way as to clearly prove to all users that the project was a success.

Application Champion: The larger a project, the more important the champion. The champion understands software engineering enough to manage all the project elements listed here. If the project is too big for a single person then a team may be needed with a project manager. For every 10 staff members using the application, a representative is needed. Quite often the champion is a person already working a 50 hour week who is expected to handle project management on top of everything else. If so, cancel the project because it has a high probability of failure.

Staff Skills Assessment: Revisit scope. The proposed project needs to further some meaningful objective that is self-evident to the staff using the application. To that end, the proposed application should be presented to the people who will use it before it is engineered. The user interface should be discussed. If a complex operation is being replaced, the champion needs to carefully address the changes. Quite often a complex series of steps get automated by an application. Staff members will need to relearn their tasks which may have taken considerable training. Are they willing & able?

Minimize Feature Creep: Revisit scope. An immediate risk to any project is feature creep. As soon as management & staff begin to see the possibilities, before the 1st step is accomplished, new features get added to the requirements. Thus the 1st target is never completed: where "completion" means all items below are done.

Minimize Discovery: This is mostly a problem with legacy applications (large, previously engineered application). It can also occur if requirements are not thoroughly researched. For legacy applications, the software engineer must thoroughly examine the application, assessing all tiers (see configurations). In assessing requirements, make sure the planned scope has buy-in from management & staff. A good software engineer will warn you if there are too many unknowns or fuzzy requirements -- the key here is to listen carefully. More often than not I'm told "just get it done, quickly." Another common practice is "sample requirement specifications" wherein a set of target outcomes are given to me with "this is what we want." My 1st question is, "is this comprehensive?" Whether or not that question is taken seriously determines the success of a project.

Test Planning: A good requirement is stated in such a way that verification is self-evident. However, results are often open to interpretation. An engineer often sees the world differently. Thus every requirement must be thoroughly tested/examined by the people using the feature. This can get complex as testing will require certain data. Hence the term "test planning." What are the test cases & what data are needed to perform the test cases? Testing takes test resources. Before committing to the project, the champion gets buy-in from management for the requisite testing resources. Whether or not testing is taken seriously determines the success of a project.

Careful Introduction & Training: If skills assessment & testing were done adequately, then introduction is much easier. It's a good idea to have a tester for every 6-10 people using an application. That tester becomes an advocate & trainer. Skills assessment has prepared everyone for the new application. As the tester verifies the requirements they inform other staff members regarding progress. Ideally they demonstrate as they go for additional buy-in. If the targeted 1st step is too complex to demonstrate, project success is compromised.