the Project Manager (PM). Be sure that your personal contribution is clear.

the Project Manager (PM). Be sure that your personal contribution is clear.
Your PP will turn into your Research Project (RP).

1) Write a couple of paragraphs to introduce your project.
2) Develop the scope for your project including all required sections. Please see the sample scope at the end of this document.
3) Explain what you learned from the process of developing the scope. One reference required.

Project Topic: Students may pick any project at all to analyze. However, it is strongly recommended that you pick an organization or company you are familiar with and analyze a project in that organization. By picking a familiar project you can ask for and obtain realistic data. You may pick yourself as the organization. That is, you may pick the remodeling of your basement if you wish. In some ways, it is much better to pick small projects than large corporate projects from your professional work. It is difficult for us to assess what part you actually played in a very large project.

Using a known organization also shortens the learning curve. Students should resist the temptation to select large, famous projects (such as Boston’s Big Dig). While such projects have mountains of data available, they can be overwhelming. Also, it is difficult to say something that has not been said before.

You will need to obtain some data.
An important aspect of the project is that there needs to be a significant contribution from a data analysis. Therefore, it is wise to select an organization you know quite a bit about, or that you have access to.

You may pick a project that has not started (new), one that is ongoing (current), or one that has been completed (historical). The requirements and outline will vary somewhat depending on what type of project you choose. How you approach the recommendations will also vary.
Avoid the temptation to write pages describing the project. Ruthlessly concentrate on your own analysis. Assume the audience knows about the project and is primarily interested in your analysis.

Take some time to consider this carefully as you will be developing assignments and using this project for the next several weeks.
Essential Components of the Scope

I. The Specification/Objective

The spec defines what the project is all about.

For a party project, the spec is where one defines all of the features of the party, such as invitations, food, drinks, and venue. However, you must also pay attention to the party’s theme. These are the features that personalize the party and, most likely, will determine whether the party is a success.

The specification completely and precisely defines the required features and functions that characterize the project.

The spec defines the project and it is so important that it is often made into a separate document. This is a good idea, even if the spec document is only a few pages long, because it is constantly being referenced by stakeholders. Also, changes to a separate document are easier to control.

The first thing to emphasize in the definition is the word required. The specification says what is required, not how to do it. Unfortunately, it is sometimes hard to distinguish the “what” from the “how.”

In fact, it is naive to think that one can completely specify what is to be done without some notion of how it is to be accomplished. Suppose you ask a contractor to build a house. You can specify the requirements for the house: a kitchen, 3 bedrooms, 2 bathrooms, etc. However, the cost will certainly depend on how it is built: One floor or three?

Requirements cannot be specified without a context. Most projects have a requirements definition phase, and part of that work is preliminary design. This design work is not to define how to do the job, but to demonstrate the project’s feasibility.

“Feasibility” applies to a multitude of issues: Scope performance, cost and schedule. For example, the preliminary design might demonstrate: that performance requirements are achievable (a web site’s response time, the span of a bridge); that the cost is appropriate (the design allowed you to conduct a parametric cost analysis); and that the schedule is achievable (a preliminary network diagram resulted in a reasonable schedule).

The primary responsibility of the requirements definition phase is to produce a feasible specification.

As you try to refine the requirements, it becomes harder and harder without including design details. For example, suppose you require 25% more kitchen cabinet space in a new kitchen. This is a clear requirement. But it becomes difficult to specify it more precisely without explaining what the new kitchen will look like (i.e., you are specifying a design).

For example, suppose the specification said, “The new kitchen should have 25% more cabinet space.” You have the responsibility to demonstrate that it is feasible both technically (in a suggested plan) and practically (via preliminary cost and schedule estimates). If the only way to get the 25% more space is to knock down walls, then a cost estimate for that (very expensive) activity should be developed. You can then determine if the cost of knocking down walls is prohibitive or not.

II. The Project’s Justification

Why are you doing the project? The project might be justified as a new business opportunity. Often, a project is required by changing regulations (tax, privacy, environmental, etc.). In this case, the motive is not profit, but compliance. Whatever the project’s justification, it is important to demonstrate that the project is essential to the company’s business goals.

III. Deliverables and Milestones

For a complete discussion of deliverables and milestones, see Chapter 3. Examples of deliverables for a party are listed in Table 7.1. Note that we have divided them into the major milestones and intermediate milestones. We have also added dates, which might be considered information that goes in the schedule section. However, this is an example of combining information from different sections of the scope into one place. If a change occurs, you will only have to change the information once, eliminating a potential for errors.”

IV. Budget

Customers almost always have a budget, or a target cost for the project, and so it is useful to identify this in the scope.

If possible, the cost drivers should be established, so that a range of costs can be considered. For example, when planning a party, you determine that the major factor driving the cost is the food and drink, estimated at $20 per person. You are planning to invite 50 people, so you might establish a preliminary food and drink budget of $1,000, and an overall party budget of $1,500.

V. Acceptance Criteria

What will satisfy the stakeholders? How will you know when you are done?

Some thought about the acceptance criteria helps to clarify the scope. For example, for the PMA website, specifying response times will help to define ease of use.

VI. Major Risks

It us useful to identify any major risks that are recognized at this stage. Risks are discussed in Chapter 17—Risk.

VII. Constraints

It is important to identify the constraints, so they can be analyzed and negotiated.
A constraint is any factor that limits the options for the project.
Some examples of constraints are:

• Personnel Constraints: The unavailability of a key technical person will hold things up. For example, in the kitchen project, the architect was the only one who had the skills to use the software program that analyzed beam loading. All changes to the structural design had to be checked by the architect. When he wasn’t around, the project suffered a delay.
• Equipment Constraints: On construction projects, the availability of bulldozers and earth moving equipment is often a constraint, because they cannot be moved quickly from job to job.
• Contractual Constraints: The contract often contains provisions, such as the specification of a particular person by name. It is not unusual for the customer to demand a “right of approval” for the assignment of a new project manager.
• Financial Constraints: Cash flow and borrowing can impose financial constraints.
• Schedule Constraints: These may arise from several sources. For example, in the PMA web site, upgrades must be operational at the beginning of each semester. In the City of Boston, construction of roads cannot continue after October 31st.
• Legal Constraints: Projects are subject to many laws and “ANSI standards.
Every constraint involves an associated risk because it limits one’s options. Therefore, project managers should proactively manage constraints.

For example, suppose a deliverable must be available by a specific date. This is a schedule constraint, and if it proves problematic, the project manager may conduct a trade-off analysis to analyze options.

The schedule might be accelerated by hiring an outside consultant, but at increased cost. Adding a consultant may also introduce a new risk because, as an outsider, he or she may not be familiar with critical technical details. On the other hand, if the deliverable is a low priority, the project manager may propose to the customer that it be delayed, or perhaps even deleted altogether.

These examples shows how constraints affect projects and how trade-offs allow the project manager to examine carefully the different aspects of the issues and propose appropriate solutions.

VIII. Limits and Exclusions

It is useful to define what the project will not do. This often provokes interesting discussions with the customer.”

IX. Assumptions
An assumption is any factor considered to be true.

All projects contain assumptions, and they are sometimes hidden or not obvious. Assumptions can arise from diverse issues: The customer’s desire to review documents; interactions with company management; technical issues; availability of personnel; and external events.

An example of a Technical Assumption is: The specification of a particular piece of hardware by the customer.

The project manager would then explicitly define the assumption in the scope document, along with relevant details: “The hardware shall be provided by the customer, and the selected model shall be sufficient to process all transactions in the required time frame.”

We see immediately how important it is to have the assumption explicitly documented. In the above case, if the customer-provided hardware did not perform satisfactorily, the project manager may seek schedule relief or additional funds from the customer. If the assumption were not explicitly documented, it is not clear who would have to pay for the hardware upgrade.

If the hardware provided by the customer turns out not to meet the throughput requirement, the project manager may offer the following options to the customer:

The current throughput is close to the specified performance, and might be acceptable to the users, so the throughput requirement may be relaxed. Some minor modifications to the user manual and training may be required. This is low risk, and will incur no additional cost.
Upgrade the server at a cost of $5,000. This is considered a low risk solution that will work.
Redesign the database to speed up the transactions at a cost of $8,000. This is considered high risk, and may not accomplish the throughput goals.
Other examples of assumptions are:

• Schedule Assumptions: The approval date of permits by city or state governments; the availability of plans from an architect; the availability of hardware or software by certain dates.
• Personnel Assumptions: When redecorating, we all know how frustrating it can be to wait on plumbers, electricians, carpenters, and painters, who never seem to be available when they were scheduled
• Financial Assumptions: This may involve the availability of funds for equipment, or cash to pay people.

X. Technical Requirements

A project is usually subject to external standards, which are called Technical Requirements. Many technical requirements are found in industry standards, such as plumbing and electrical codes, environmental regulations, and tax laws. Other technical requirements are found in accounting standards and human resources regulations.

For example, if you decide to include fireworks in your party project, you must satisfy the local fire department regulations and, maybe even, have to pay for an on-duty fireman at the event. Another example of technical requirements are the legal implications of serving alcohol at the party.

The detailed Technical Requirements are usually not included in the scope, but are incorporated “by reference.” This means that the applicable standards are referenced in the scope, and all of their conditions must be upheld.”

Writing the Scope
Good writing is essential in project management and nowhere is that more important than in the scope.

One might be tempted to think that the scope is always a long and complicated document. That would be wrong!20 While the scope must be complete and precise, one should ruthlessly cut it.21 Clarity is the objective, not length.

The scope sections above should be regarded as a checklist, not an outline. If you include a table of deliverables, you can satisfy the milestone requirement by simply adding a date column to the table. This is an example of specifying information in exactly one place. If a separate milestone table were included, when a deliverable changed, information would have to be changed in two places. This is inefficient, a source of errors, and to be avoided at all costs.

Many scope sections are interrelated. For example, a construction permit may involve an assumption (customer will obtain permit), a schedule constraint (permit in 30 days), and an exclusion (does not include environmental permit). All such permit information should be one place so that if anything about the permit changes, only one part of the scope need change. If the information were scattered among multiple sections, a change to the permit would require multiple changes to the scope, an error-prone process

Finally, not all sections of the scope are equally important. Early on it is vital to establish key ideas. For example, in party project it is crucial to establish the style of the party, e.g., a Spanish-costumed, dance party. It is easy to get caught up in the technical details (assumptions, technical requirements, etc.) and forget to provide the essential feel of the project: Spanish dancing!

Do not put statements in the negative form.
And don’t start sentences with a conjunction.
If you reread your work, you will find on rereading that a
great deal of repetition can be avoided by rereading and editing.
Never use a long word when a diminutive one will do.
Unqualified superlatives are the worst of all.
De-accession euphemisms.
If any word is improper at the end of a sentence, a linking verb is.
Avoid trendy locutions that sound flaky.
Last, but not least, avoid clichés like the plague.