Project Assumptions And Constraints

Project Assumptions And Constraints

When projects have problems, the cause is frequently an assumption that turned out to be invalid, or a constraint that was never identified. By documenting the assumptions and constraints, you can spot danger areas that may require some work.

Assumptions and constraints are frequently the reverse of one another. For example, if a project needs a network administrator and one is available half of the time, you may assume that the resource is available half time, while being under the constraint that it is not available more.

Assumptions

In general, the things you assume to be true will assist the project. If your assumptions are invalid, the project will suffer, and, converesely, if there are assumptions you do not identify, the project will usually benefit. For example, if you assume that the client mainframe will be available twenty-four hours a day, the project will suffer if the client restricts the team to a normal eight-hour day. On the other hand, if you have assumed a normal workday and overtime becomes necessary, the project will benefit when the client offers twenty-four-hour access.

Assumptions, therefore, positively affect a plan by reducing effort and ensuring resources. You usually assume, for example, that hardware and people will be available when you need them, that statistics used in planning are accurate, that critical components will be delivered on time, and that key people on both the project and client teams will perform adequately.

Exhibit 4.4 lists typical types of assumptions. For any given project, the specific assumptions will vary, but this list will provide a starting point. Several of the assumptions refer to project planning components such as project organization. It is sufficient to refer to a chart or table in which you have described the component.

Exhibit 4.4 Sample List of Project Assumptions

Resource Assumptions

Project staff resources will be available when and as they are needed.

Required computer resources will be available when and as they are needed.

Required client resources will be available when and as they are needed.

At least n percent of the project staff will be experienced with the development environment.

The client will provide staff capable of adequately describing in detail the functional requirements of the system.

Delivery Assumptions

Deliverables submitted for approval will be returned within n working days.

Equipment order lead times will be [specify].

(continues)

Exhibit 4.4 (continued)

Environmental Assumptions

No industrial action will be taken that will affect the project.

Issues will be resolved in a timely manner.

The project organization [describe it] will be put in place.

The methodology [name it] will be used in the project.

Client internal processes (such as purchasing) will be completed in a timely manner.

Systems development components will be capable of being integrated.

Budgetary Assumptions

The statistics used in preparing the estimates [list them] are accurate within n percent.

No travel and living expenses will be required, or Travel and living expenses are limited to those described.

No outside consulting will be required, or Outside consulting will be limited to n days at $n per day.

Functionality Assumptions

The scope of the project is limited to [describe it].

Constraints

Constraints are limits or boundaries within which you must work. If your constraints prove not to exist, the project will probably benefit, whereas constraints that you fail to identify will cause the project to suffer. For example, if your plans include the constraint that a key analyst will be available half time, the project will benefit if the constraint turns out not to exist. Conversely, if you did not identify that constraint, the project will suffer when it surfaces.

Constraints, therefore, negatively affect a plan by limiting resources and increasing work. Your constraints usually include limitations on availability of hardware or people, the need to consider effects on other application systems, or requirements to conform to a methodology.

Exhibit 4.5 lists some areas in which you need to look for potential constraints.

Exhibit 4.5 Sample List of Project Constraints

Resource Constraints

Key staff resources will be available only on a part-time basis.

Computer resources will be available on a limited basis.

Key client resources will be available on a restricted basis.

Delivery Constraints

Deliverables submitted for approval will require at least n working days for review.

Equipment order lead times cannot be specified with accuracy.

Environmental Constraints

The development environment is new and no members of the development staff are familiar with it.

An overtime ban is in effect, restricting all work to normal working hours.

Key decision makers are based out of town and difficult to contact when issues arise.

The project does not have a client project manager (or executive sponsor, or steering committee).

Client internal processes (such as purchasing) are inefficient and unpredictable.

The methodology [name it] is new and not familiar to the development team.

The systems development environment is new, and the components have not yet been successfully integrated.

The project depends upon the successful and timely completion of associated projects.

Budgetary Constraints

Statistics used in preparing the estimates are unreliable.

Travel and living expenses cannot be accurately estimated.

(continues)

Exhibit 4.5 (continued)

Outside consulting requirements cannot be accurately estimated.

Functionality Constraints

The scope of the project is unclear.

The project depends upon receiving data from other, external applications.

The project has relationships to other projects in progress and will depend on their status.

Why Identify Assumptions and Constraints?

Not all assumptions and constraints need to be stated. For example, it would be gratuitous to state the assumption that the estimates will be met. What else would you assume? Similarly, you would not want to offend the client by stating the assumption your bills will be paid on time. Nevertheless, most assumptions and constraints need to be made explicit for two reasons. First, your client, your management, and you need to understand the basis on which you are planning. For example, if you have assumed that deliverables will be reviewed and returned within five working days, it is valuable, if frustrating, to hear your client say, "We can't guarantee fewer than ten days." Documenting the assumption allows it to be challenged. Similarly, documenting constraints allows the client or management to remove them if possible.

The second reason to identify assumptions and constraints is to help you when you need to negotiate with the client during the project. If you have explicitly assumed that deliverables would be reviewed in five days and none have come back in fewer than ten, you have a case for extending the schedule and increasing the costs. But if the assumption was unstated, you have no defense when your client says, "We never committed to a five-day turnaround."

By making your assumptions and constraints explicit, you allow them to be challenged and you establish a basis on which the project will run.

What If?

Somebody Challenges Your Assumptions.

Normally, you welcome a challenge to your assumptions. You need to find out as quickly as possible whether or not they are correct so that you can revise your plan appropriately. However, in some cases, you may not trust the challenge. For example, suppose the client says, "Of course we'll provide whatever user people you need. You don't need to state that as an assumption." However, your experience tells you that you will have trouble getting commitments from client staff because of their workloads. In such a case, if you drop the assumption, you will have no recourse when the project slips because client staff are unavailable.

Actions

Unless you are convinced that the assumption need not be stated, leave it in. You can do this by saying, "I'm sure there's no problem, but I like to document all the assumptions I made when I prepared the estimates." Then move on to another subject.

If the client insists that the assumption be removed, do so, but revise your estimates based on its being excluded.

Somebody Challenges Your Constraints.

As with assumptions, you want to hear these challenges, particularly those concerning constraints, because removing constraints will make your job easier. However, if you discover during the project that the constraint actually exists, your project will suffer.

Actions

Ask the client for a commitment that the constraint does not exist. For example, if you have stated the constraint that on-line access will be limited to normal working hours, and the client says that you can have access twenty-four hours a day, you can ask the client to inform the system manager so that any account setups can be completed properly.

Turn the constraint into an assumption. In the above example, your  assumption would be that on-line access is available twenty-four hours per day. If the client does not object to the assumption, it is now part of your plan.