If you're new here, Welcome! To learn more about what this site is all about click here [link].

I am a small business Conversation Consultant and public speaker that uses the power of the internet to leverage your success. Productivity in Context is a web magazine focused on Productivity and tools for organizing. Make this your headquarters for improving your life and work through increased mindfulness, education, and workflow practices.

Subscribe by E-mail for updates on: Productivity methods, Lifestyle innovation, and the collaborative design of the next-generation personal knowledge management system.

Click Here for an overview of the content. Please take a look at our sponsors. (Hosting isn't free...)
Please contact me via e-mail: stephen @ hdbizblog dot com

Successfully completing a project typically requires that you complete a set of tasks on time, within budget, and make sure your customers are happy with the end result. That sounds simple enough, but how many projects have you heard of (or worked on) that were completed late, or cost too much, or didn’t meet the needs of the end users? Let’s walk through the definition to clarify what a project is and is not.

What is a Project?

First of all, a project is temporary. The duration might be just a week, or it might go on for years, but every project has an end date. You may not know that end date when the project starts, but it has to end somewhere in the future. A projects is not the same as an ongoing operation, though the two have a lot in common. Ongoing operations, as the name suggests, go on indefinitely.

Examples include most general business activities like manufacturing or accounting. People who run ongoing operations might also manage projects; for example, a manager of a human resources department for a large company might plan a job fair. But projects are distinguished from ongoing operations by an expected end date, such as the date of the job fair.

Next, a project is a set of actions that may or may not consume resources. The most common description of resources: The people, equipment, and material that are used to complete the tasks in a project. Projects have a sense of being intentional, planned events. Successful projects don’t happen by themselves, some amount of preparation and planning happens first.

Finally, every project creates a unique product or service. This is the deliverable. The deliverable is a tangible or measurable result or outcome, or an item that is produced to complete a project or part of a project. Typically, the project team and project stakeholders agree on project deliverables before the project begins. This is generally the reason that the project was undertaken.

Seeing projects in terms of time, cost, and scope

You can visualize project work in many ways, but there are three features common to all projects:

1. Time - some element of a time constraint set on the start or finish date of a task. You can specify that a task must start on or finish no later than a particular date. The time constraints can be flexible [not tied to a specific date] or inflexible [tied to a specific date].
2. Cost - some type of budget the estimated cost of a project that you establish in your basic plan.
3. Scope - the combination of all project goals and tasks, and the work required to accomplish them.

If you adjust any one of these features, the other two are affected. For example, if you adjust the project plan to shorten the schedule, you might increase costs and decrease scope. Let’s consider these features one at a time.

Time

Have you ever worked on a project that had a deadline? (Maybe we should ask whether you’ve ever worked on a project that did not have a deadline.) Limited time is the one feature of any project with which we are all probably most familiar. If you’re working on a project right now, ask your team members what the project deadline is. They might not know the project budget or the scope of work in great detail, but chances are they all know the project deadline.

Here are some examples of time constraints:

• You’re building a house and you must finish the roof before the rainy season arrives.
• You are building a new website for a sales program that starts in two months.
• You are developing a new inventory tracking system that must be tested and running by the start of the next fiscal year.

Most of us have been trained to understand the value of time and for many projects that create a product or result in an event, time is the most important feature to manage.

Cost

You might think of cost simply as dollars, but project cost has a broader meaning: costs include all the resources required to carry out the project. Costs include the people and equipment who do the work, the materials they use, and all the other events and issues that require money or someone’s attention in a project.

Here are some examples of cost constraints:

• You have signed a fixed-price contract to deliver an inventory-tracking software system to a client. If your costs exceed the agreed-upon price, your customer might be sympathetic but probably won’t be willing to renegotiate the contract.
• The president of your company has directed you to carry out a customer research project using only the staff and equipment in your department.
• You have received a $5,000 grant to create an after-school art program. You have no other funds.

For virtually all projects, cost is ultimately a limiting feature; few projects can go over budget without eventually requiring corrective action.

Scope

You should consider two aspects of the scope of a project: product scope and project scope. Every successful project produces a unique product: a tangible item or a service. You might develop some products for one customer you know by name. You might develop other products for millions of potential customers waiting to buy them (you hope). Customers usually have some expectations about the features and functions of products they consider purchasing.

Product scope describes the intended quality, features, and functions of the product—often in minute detail. Documents that outline this information are sometimes called product specifications. A service or an event usually has some expected features as well. We all have expectations about what we’ll do or see at a party, a concert, or a sporting event. Project scope, on the other hand, describes the work required to deliver a product or a service with the intended product scope. Whereas product scope focuses on the customer or the user of the product, project scope is mainly the concern of the people who will carry out the project. Project scope is usually measured in tasks and phases.

Here are some examples of scope features:

• Your organization won a contract to develop an automotive product that has exact requirements—for example, physical dimensions measured to 0.01 mm. This is a product scope feature that will influence project scope plans.
• You are constructing a building on a lot that is zoned for a maximun height of 30 feet.
• You can use only internal services to develop part of your product, and those services follow a product development methodology that is different from what you had planned.

Product scope and project scope are closely related. The project manager who manages project scope well must also understand product scope or must know how to communicate with those who do.

Time, cost, and scope: managing project constraints

Project management gets most interesting when you have to balance the time, cost, and scope features of your projects. For example, if you adjust the project plan to shorten the schedule, you might increase costs and decrease scope. This illustrates the process of balancing features because the three features are connected, and changing one of the features affects at least one other.

Here are some examples of feature balance:

• If the duration (time) of your project schedule decreases, you might need to increase budget (cost) because you must hire more resources to do the same work in less time. If you can’t increase the budget, you might need to reduce the scope because the resources you have can’t do all of the planned work in less time.
• If you must decrease a project’s duration, make sure that overall project quality is not unintentionally lowered. For example, testing and quality control often occur last in a software development project; if the project duration is decreased late in the project, those tasks might be the ones cut back. You must weigh the benefits of decreasing the project duration against the potential downside of a deliverable with poorer quality.
• If the budget (cost) of your project decreases, you might need more time because you can’t pay for as many resources or for resources of the same efficiency. If you can’t increase the time, you might need to reduce project scope because fewer resources can’t do all of the planned work in the time you have.

If you must decrease a project’s budget, you should also look at the costs of the human and equipment resources you have planned to use. Can you hire less experienced people for less money to carry out simpler tasks? Reducing project costs can lead to a lower quality deliverable, however. As a project manager, you must consider (or communicate to the decision makers) the benefits versus the risks of reducing costs.

If your project scope increases, you might need more time or more resources (cost) to do the additional work. Changing project scope midway through a project is not necessarily a bad thing. For example, your intended customer might have changed and you need to deliver a different product to the new customer. Changing project scope is a bad thing only if the project manager doesn’t recognize and plan for the new requirements—that is, when other features (cost, time) are not correspondingly examined and, if necessary, adjusted.

Time, cost, and scope are the three essential features of any project.

If you found this post useful, please share it with your friends on Twitter using the tinylink http://tinyurl.com/6re4e9. Thanks, I appreciate it! Feel free to comment below, I enjoy discussing these ideas. ~@Stephen