Unit 2: Defining The Project

I. Foundations of Project Definition

Project definition is the process of establishing the basic information, scheduling rules, calendars, and display conventions that govern a project plan. In Microsoft Project, these settings determine when work can occur, how dates are calculated, what descriptive information is stored, and how the schedule appears in different views.

• Core objective: Convert project assumptions into a structured scheduling model containing dates, working times, tasks, resources, and dependencies.
• Scheduling engine: Microsoft Project calculates task dates by combining durations, dependencies, constraints, resource assignments, and calendars.
• Project calendar: Defines the project's general working and non-working periods, such as Monday-Friday working weeks and organizational holidays.
• Calendar hierarchy:
  • Base calendar: A reusable working-time template, such as Standard, 24 Hours, or Night Shift.
  • Project calendar: The base calendar selected to control the overall project schedule.
  • Resource calendar: Represents the availability of an individual work resource.
  • Task calendar: Applies special working-time rules to a particular task.
• Project views: Present the same underlying schedule in different forms; the Gantt Chart emphasizes time, the Network Diagram emphasizes dependencies, and the Calendar view emphasizes scheduled dates.
• Formatting principle: Formatting changes presentation rather than scheduling data. Changing a bar's color does not change its duration, dates, or dependencies.
• Common convention: Procedures refer to Microsoft Project desktop; tab names and dialog layouts can vary slightly by version.

II. Project Information and Calendar Fundamentals

Project information establishes the schedule's principal dates and calculation direction, while the project calendar defines when scheduled work is permitted.

A. Understanding Project Information

Project Information contains the high-level scheduling controls from which Microsoft Project calculates the plan.

• Access point: Open Project > Project Information to inspect or modify the principal project settings.
• Start date: When scheduling from a project start date, this is the earliest normal point from which unconstrained work is calculated forward.
• Finish date: When scheduling from a finish date, this is the target boundary from which tasks are calculated backward.
• Schedule-from option:
  1. Project Start Date: Tasks are scheduled as early as possible by default; this is the usual planning method.
  2. Project Finish Date: Tasks are scheduled as late as possible by default; this is useful when planning backward from a fixed deadline.
• Current date: Usually defaults to the computer's system date and provides a reference for status or reporting.
• Status date: Represents the date up to which progress is being measured. If no explicit status date is set, Microsoft Project commonly uses the current date for relevant calculations.
• Calendar field: Selects the base calendar that serves as the project calendar.
• Priority field: Uses a value from 0 to 1000 to influence resource-leveling decisions; a higher value gives the project greater protection when projects share resources.
• Calculation relationship: A project start of 7 July, 8:00 AM, a one-day task, and an eight-hour working day normally produces a finish of 7 July, 5:00 PM when the calendar includes a one-hour lunch break.

B. Understanding The Project Calendar

The project calendar is the general time model used to convert task durations into scheduled dates and times.

• Working time: Periods during which Microsoft Project may schedule work, such as 08:00-12:00 and 13:00-17:00.
• Non-working time: Periods excluded from normal scheduling, including weekends, holidays, shutdowns, and breaks.
• Standard calendar: Commonly represents an eight-hour Monday-Friday working pattern, although its exact times can be edited.
• 24 Hours calendar: Treats every hour of every day as working time; it suits continuously operating processes.
• Night Shift calendar: Provides an alternative pattern for work performed mainly during evening and overnight periods.
• Duration effect: A task requiring 16 hours under an eight-hour weekday calendar normally spans two working days, not two elapsed calendar days.
• Calendar interaction: The effective schedule may depend on the intersection of project, task, and resource availability. A resource holiday can delay assigned work even when the project calendar marks that day as working.
• Elapsed duration: A duration such as 2 edays means two continuous elapsed days and does not stop for ordinary non-working periods.

C. Choosing Your Calendar For The Project

The selected project calendar should represent the working pattern followed by most project activities.

• Selection criterion: Choose a calendar based on actual operational hours rather than the appearance of the desired finish date.
• Standard calendar use: Appropriate for office, academic, and administrative projects operating mainly on weekdays.
• 24 Hours calendar use: Appropriate for continuous server processing, curing, monitoring, or plant operations that genuinely continue without scheduled interruption.
• Night Shift calendar use: Appropriate when the project's normal work is conducted during night-shift hours.
• Custom calendar use: Required when the organization has regional weekends, split shifts, seasonal hours, or recurring shutdown periods.
• Application procedure:
  1. Open Project > Project Information.
  2. Select the required entry in the Calendar field.
  3. Confirm with OK, then inspect task dates for resulting changes.
• Decision caution: A project calendar should express general availability. Exceptional availability for one employee or task belongs in a resource or task calendar.
• Concrete comparison: A 24-hour task started Monday at 08:00 may finish Tuesday at 08:00 on a 24 Hours calendar, but may occupy three working days on an eight-hour Standard calendar.

III. Project File Metadata

A project file stores both scheduling content and document properties that support identification, ownership, organization, and retrieval.

A. Understanding File Properties

File properties are metadata attached to the project document rather than tasks within the schedule.

• Basic identification: Properties can include title, subject, author, manager, company, category, keywords, and comments.
• Access route: In desktop versions, use File > Info, then open Project Information > Advanced Properties where available.
• Summary properties: The Summary tab records descriptive values such as project title, author, company, and comments.
• General properties: The General tab can show technical information such as file type, location, size, and creation or modification dates.
• Statistics: The Statistics tab may show timestamps, revision information, and editing details maintained by the application.
• Custom properties: Named metadata fields can hold organization-specific information, such as contract number, department, client code, or approval status.
• Operational value: Accurate properties make project files easier to search, classify, audit, and distinguish when filenames are similar.
• Data distinction: Changing the Author property does not change the project manager resource, task assignments, schedule owner, or resource costs.
• Example: A file named Implementation.mpp can be made unambiguous by setting Title to ERP Implementation - Phase 2, Manager to the responsible manager, and Keywords to ERP, migration, finance.

IV. Calendar Configuration and Schedule Application

Calendar configuration translates an organization's real working arrangements into rules that the scheduling engine can apply.

A. Creating new calender and setting working and non-working days

A new base calendar provides a reusable schedule for projects, resources, or tasks with a distinct working pattern.

• Creation path: Open Project > Change Working Time, select Create New Calendar, enter a meaningful name, and choose whether to copy an existing calendar or create a new base calendar.
• Naming practice: Use operational names such as Six-Day Site Calendar or Regional Support Shift, rather than vague names such as Calendar 2.
• Working Weeks tab: Select the default working-week entry, choose Details, select weekdays, and define working periods.
• Split working day: Two ranges such as 08:00-12:00 and 13:00-17:00 create eight working hours while preserving a non-working lunch interval.
• Non-working weekday: Select a day such as Sunday and choose Set days to nonworking time.
• Exceptions tab: Enter named exceptions such as Foundation Day with start and finish dates to create holidays or temporary working periods.
• Recurring exceptions: Use Details to define recurrence, such as an annual holiday or the first Saturday of each month.
• Validation: Review several weeks in the calendar display to confirm shifts, weekends, exceptions, and recurrence boundaries.
• Scheduling consequence: If Friday is made non-working, an eight-hour task beginning Thursday at 13:00 completes on Saturday only when Saturday is defined as working; otherwise, it continues on the next available day.

B. Applying calender on Gantt chart

Applying a calendar causes tasks displayed in the Gantt Chart to be scheduled against the intended working-time rules.

• Project-wide application: Choose the new base calendar in Project > Project Information > Calendar to make it the project's default calendar.
• Task-specific application: In the Gantt Chart, open Task Information > Advanced and select a calendar in the Calendar field.
• Resource effect: For resource-driven tasks, Project also considers assigned resource calendars; limited resource availability may move the task.
• Ignore option: Scheduling ignores resource calendars makes a task calendar govern scheduling without intersecting it with resource availability. It should be used only when the task can truly proceed regardless of normal resource hours.
• Visual verification: Check the Start, Finish, and Duration columns after application, because bars may move when non-working periods are introduced.
• Timescale shading: Non-working periods can be shaded in the chart area, helping users compare bar placement with the active calendar.
• Example: Applying a six-day calendar to a five-day construction task beginning Wednesday can permit Saturday work and produce an earlier finish than the Standard calendar.

V. Formatting Schedule Views

View formatting improves communication by emphasizing the type of information that each audience needs without modifying the schedule's underlying logic.

A. Formatting Bar Styles in a Gantt Chart View

Bar Styles control the appearance and placement of categories of Gantt bars, such as normal tasks, milestones, summaries, and critical tasks.

• Bar Styles command: In a Gantt Chart view, use the contextual Format tab and open Bar Styles.
• Style categories: Rows can target task classes through conditions such as normal, critical, milestone, summary, or progress-related bars.
• Bar structure: The Bars tab controls the start shape, middle pattern, end shape, color, and bar row.
• Text placement: The Text tab can place fields such as task name, resource names, duration, start, or finish to the left, right, above, below, or inside a bar.
• Individual formatting: Format Bar changes a selected bar, whereas Bar Styles defines formatting rules for categories of tasks.
• Ordering rule: Bar-style definitions can overlap, so row order and matching conditions affect which style is visible.
• Useful convention: Distinguish milestones with symbols, summary tasks with stronger bars, and critical tasks with a consistent high-contrast color.
• Presentation limit: Excessive colors, patterns, and labels reduce readability; formatting should encode a small number of meaningful schedule distinctions.

B. Formatting the Network Diagram View

The Network Diagram displays tasks as connected nodes, making dependency structure and sequence easier to inspect.

• View selection: Open the View tab and choose Network Diagram.
• Node meaning: Each box represents a task and may contain fields such as ID, name, duration, start, finish, and resource names.
• Link meaning: Connecting lines represent task dependencies; arrow direction indicates predecessor-to-successor flow.
• Box Styles: Use Format > Box Styles to change the border, background, template, or appearance of categories such as critical, noncritical, milestone, and summary tasks.
• Data Templates: Templates determine which fields appear inside nodes and how those fields are arranged.
• Layout controls: The Layout command adjusts box arrangement, alignment, spacing, link style, and page positioning.
• Analytical emphasis: Formatting critical boxes consistently helps reveal the dependency chain most likely to influence project completion.
• Readability control: For a large network, apply filters or collapse summary structures before formatting; showing hundreds of nodes at once obscures logical relationships.

C. Formatting the Calendar View

The Calendar view presents tasks within daily, weekly, or monthly date cells for date-centered communication.

• View selection: Choose View > Calendar to display scheduled tasks against calendar dates.
• Display span: Zoom or timescale controls determine how many weeks appear and how much room each day provides.
• Bar Styles: Calendar-view bar styles can distinguish normal tasks, milestones, summaries, critical work, and completed work.
• Visible fields: Task names are commonly displayed, while additional fields should be limited because each date cell has restricted space.
• Working-time appearance: Formatting options can differentiate working and non-working days, headings, date boxes, and gridlines.
• Task overflow: When too many tasks occupy one date cell, not every bar may be visible; adjusting row height, displayed weeks, filtering, or zoom improves visibility.
• Practical use: The view is suitable for communicating deadlines, events, short tasks, and milestone dates to stakeholders familiar with conventional calendars.
• Interpretive limit: Calendar view is weaker than Gantt Chart or Network Diagram for examining dependency logic, long overlapping tasks, and the critical path.