Unit 2: Defining The Project - Subjective Questions

Project information is the collection of facts, assumptions, constraints, requirements, resources, and scheduling details used to plan, execute, monitor, and control a software project.

Important types of project information include:

• Project objectives: The expected outcomes and business purpose of the project.
• Scope information: Features, deliverables, exclusions, and acceptance criteria.
• Task information: Activities required to complete the project, including duration, dependencies, and milestones.
• Resource information: People, equipment, facilities, and materials assigned to activities.
• Cost information: Estimated task costs, resource costs, and the approved budget.
• Time information: Start dates, finish dates, deadlines, and project duration.
• Risk information: Potential events that may affect scope, cost, quality, or schedule.
• Progress information: Actual work completed, remaining work, delays, and performance against the baseline.

Understanding this information allows the project manager to create a realistic schedule and make informed decisions throughout the project lifecycle.

A project calendar defines the working and non-working periods available for project activities. It provides the time framework within which tasks can be scheduled.

Its importance includes:

• Identifying normal working days and working hours.
• Representing weekends, public holidays, vacations, and organizational shutdowns.
• Preventing tasks from being scheduled during unavailable periods.
• Calculating realistic task start and finish dates.
• Supporting accurate project duration and completion-date calculations.
• Helping coordinate the availability of project resources.

For example, if a task requires five working days and a holiday occurs during that period, the task finish date is extended unless work is specifically allowed on the holiday. Therefore, the calendar directly affects the critical path, milestones, resource utilization, and final project completion date.

The three calendars control scheduling at different levels:

• Project calendar: Defines the general working and non-working time for the entire project. It is suitable when all project activities follow the same organization-wide schedule.
• Resource calendar: Defines the availability of an individual resource or resource group. It records personal leave, shifts, part-time availability, training, or other resource-specific restrictions.
• Task calendar: Defines special working and non-working periods for a particular task. It is useful when a task can be performed outside normal project working hours or requires a special schedule.

The project calendar provides the default schedule. A resource calendar overrides the default for a particular resource, while a task calendar overrides the normal schedule for a specific activity. These calendars must be coordinated to avoid assigning work when either the task or the required resource is unavailable.

Choosing an appropriate project calendar requires analysis of the project's operational environment and constraints. Important factors include:

• Organization working pattern: Determine whether the organization follows a five-day, six-day, or shift-based week.
• Team location: Consider different time zones, regional holidays, and local working practices.
• Resource availability: Check part-time schedules, planned leave, training, and other commitments.
• Project deadlines: Evaluate whether extended hours or weekend work are necessary to meet contractual dates.
• Development methodology: Agile teams may use fixed iteration calendars, while other projects may use milestone-driven schedules.
• External dependencies: Consider vendor, client, testing laboratory, or deployment-window availability.
• Legal and organizational policies: Include labor laws, public holidays, and approved working-hour restrictions.
• Special project conditions: Account for maintenance windows, release freezes, or twenty-four-hour operations.

The selected calendar should represent actual availability. An unrealistic calendar produces inaccurate duration, cost, resource, and completion-date estimates.

A general procedure for creating and configuring a calendar is as follows:

1. Open the project calendar management or change-working-time feature.
2. Select the option to create a new calendar.
3. Choose whether to create a blank calendar or copy an existing calendar.
4. Provide a meaningful name, such as "Software Development Calendar".
5. Define the normal working days of the week.
6. Set the working hours for each working day, such as morning and afternoon shifts.
7. Mark weekends, public holidays, vacations, and shutdown periods as non-working days.
8. Add exceptions for unusual working days or special project events.
9. Review the calendar for overlapping or contradictory settings.
10. Save the calendar and assign it to the project, tasks, or resources as required.

The calendar should be validated against the actual organizational schedule before it is used for project forecasting.

The terms describe different scheduling conditions:

• Working time: Periods during which project work can normally be performed. For example, Monday through Friday from 9:00 a.m. to 5:00 p.m.
• Non-working time: Periods during which work is not normally scheduled. Examples include weekends, public holidays, annual leave, and organizational shutdowns.
• Exception time: A special calendar rule that changes the normal pattern for a specific date or period. An exception can convert a normal working day into a non-working day or make an otherwise non-working day available for work.

For example, a software team may normally work from Monday to Friday. A national holiday converts a weekday into non-working time. If an urgent production release is planned for a Saturday, that Saturday can be entered as exception working time. These settings help the scheduling system represent real project conditions accurately.

A Gantt chart displays tasks against a time scale, and the project calendar determines which portions of that time scale are available for work.

When the calendar is applied:

• Task bars are placed only across valid working periods unless a task-specific rule permits otherwise.
• Non-working days appear as gaps or shaded periods in the chart.
• Task durations are calculated using working time rather than simple elapsed calendar time.
• Dependencies are scheduled according to the finish or start dates calculated from the calendar.
• Milestones move when preceding tasks are extended by holidays or other non-working periods.
• The project finish date may be delayed when available working time is reduced.

For example, a task requiring three working days that begins on Friday may finish on Tuesday if Saturday and Sunday are non-working days. Therefore, changing the calendar can change the entire network of scheduled activities and may affect the critical path.

The task requires 16 working hours. The calendar provides 8 working hours per working day, so the duration is:

The task starts on Thursday:

• Thursday: 8 working hours are completed.
• Friday: The remaining 8 working hours are completed.
• Saturday and Sunday: These are non-working days and do not contribute to task progress.

Therefore, the task finishes on Friday. The weekend does not extend the finish date in this example because the required two working days are completed before the weekend.

File properties contain descriptive and control information about the project file. Important properties include:

• Project title: Identifies the project clearly.
• Author or manager: Records the person responsible for maintaining the file.
• Subject and description: Summarizes the purpose, scope, or contents of the project.
• Project start date: Defines the beginning of the schedule.
• Project finish date: Shows the calculated or planned completion date.
• Calendar setting: Identifies the working-time model used by the project.
• Status date: Indicates the date used for progress measurement and reporting.
• Baseline information: Shows whether an approved schedule baseline exists.
• Version or revision information: Helps track changes to the project file.
• Keywords or classification: Supports searching and organizing project documents.

Correct file properties improve traceability, communication, reporting, and configuration control. They also help prevent confusion when multiple project versions or related schedules exist.

File properties provide context that helps users understand the identity, purpose, ownership, and current state of a project schedule. They support:

• Traceability: Users can identify who created or updated the file.
• Version control: Revision information distinguishes the current schedule from older copies.
• Reporting: Project title, status date, and description improve the accuracy of reports.
• Accountability: Ownership information makes responsibility clear.
• Coordination: Teams can confirm that they are using the correct calendar and schedule assumptions.
• Auditing: Historical and descriptive information helps explain planning decisions.

Incomplete or incorrect properties can cause users to work with an outdated schedule, misunderstand the project scope, apply the wrong calendar, or report incorrect dates. This can lead to duplicated work, poor decisions, schedule disputes, and loss of confidence in the project management system.

A standard project calendar uses a predefined working pattern, such as Monday through Friday with fixed daily working hours. A customized project calendar is created or modified to represent the specific conditions of a project.

Standard project calendar:

• Advantages: Quick to apply, easy to understand, consistent across projects, and simple to maintain.
• Limitations: May ignore regional holidays, shift work, part-time availability, special release windows, or project-specific constraints.

Customized project calendar:

• Advantages: Represents actual working conditions, improves schedule accuracy, supports shifts and exceptions, and accounts for project-specific deadlines.
• Limitations: Requires more setup and maintenance, can be misunderstood if poorly documented, and may make comparisons between projects more difficult.

A standard calendar is appropriate when project conditions match organizational norms. A customized calendar is preferable when the project has unusual working hours, distributed teams, or significant exceptions.

Incorrect calendar settings cause the scheduling system to calculate availability and duration incorrectly. Common effects include:

• Tasks being scheduled on holidays or weekends when staff are unavailable.
• Project durations being underestimated or overestimated.
• Milestones and deadlines appearing earlier or later than they should.
• Resources being assigned during leave or outside their working hours.
• Critical path activities being identified incorrectly.
• Budget and labor-cost estimates becoming unreliable.
• Dependencies being calculated from incorrect start and finish dates.
• Progress reports showing misleading schedule performance.

For example, if a public holiday is incorrectly entered as a working day, a task may finish one day too early. That error can propagate through successor tasks and produce an unrealistic final completion date. Calendar settings should therefore be reviewed whenever project assumptions or organizational working patterns change.

Bar styles define the visual appearance of task bars in a Gantt chart. A style may control the bar shape, color, pattern, position, text labels, and the task category to which it applies.

Formatting bar styles improves communication by:

• Distinguishing summary tasks from detailed tasks.
• Showing critical tasks with a visually prominent style.
• Separating baseline bars from current schedule bars.
• Identifying milestones using special symbols.
• Displaying progress through a different fill or pattern.
• Making external, inactive, or manually scheduled tasks recognizable.
• Adding labels such as task names, dates, or resource names.

Good formatting creates a visual language that allows stakeholders to interpret schedule status quickly. Styles should remain consistent, readable, and meaningful. Excessive colors or decorative formatting can reduce clarity rather than improve it.

A systematic procedure is:

1. Open the Gantt Chart view and access the bar-style formatting settings.
2. Review the existing style rules and identify the categories that require modification.
3. Select a task category, such as summary, milestone, critical, baseline, or progress.
4. Specify the bar shape, color, pattern, and row position.
5. Configure the text fields displayed beside or inside the bar.
6. Arrange style rules in the correct order so more specific rules are applied properly.
7. Preview the chart using tasks from different categories.
8. Check that labels do not overlap and that colors remain distinguishable when printed.
9. Apply the settings and save the view or template if it will be reused.

The final format should emphasize schedule meaning, support rapid scanning, and remain accessible to users who may view the chart in grayscale or have color-vision limitations.

A Gantt chart can represent multiple schedule dimensions by assigning separate visual styles to each category:

• Planned work: Use the normal task bar to show the currently scheduled start and finish dates.
• Actual progress: Use a progress fill, overlay, or completed percentage indicator inside the planned bar.
• Baseline dates: Display a second bar or thin marker beneath the current task bar to show the originally approved schedule.
• Critical activities: Use a distinctive but readable color or pattern for tasks that affect the project finish date.
• Milestones: Use a diamond or another standard milestone symbol.

This formatting makes variance visible. If the current bar extends beyond the baseline bar, the task is delayed. If progress is smaller than expected for the elapsed time, execution may be behind plan. The chart should use a clear legend and avoid conflicting styles so that each visual element has one unambiguous meaning.

A network diagram view represents project activities as connected nodes or boxes. The connecting lines show logical relationships such as finish-to-start, start-to-start, finish-to-finish, or start-to-finish dependencies.

A Gantt Chart view emphasizes the time dimension. It shows task bars along a calendar timeline and is useful for understanding duration, dates, progress, and overlap.

Key differences include:

• Network diagram: Emphasizes logical sequence, dependencies, branching, and convergence.
• Gantt chart: Emphasizes dates, duration, working time, progress, and resource-related timing.
• Network diagram: Helps identify missing links, dependency chains, and potential critical-path relationships.
• Gantt chart: Helps communicate when work occurs and how long it is expected to take.

Both views describe the same schedule from different perspectives and should be used together when analyzing and communicating a project plan.

Important Network Diagram formatting options include:

• Node shape: Different shapes can distinguish summary tasks, milestones, critical tasks, and ordinary tasks.
• Node size: Larger nodes can display more task information, while smaller nodes reduce clutter.
• Node fields: Fields such as task name, duration, start date, finish date, and identification number can be displayed.
• Node color or pattern: Visual emphasis can identify critical, completed, delayed, or high-priority activities.
• Connector style: Different line styles or arrowheads can clarify dependency direction and relationship type.
• Layout arrangement: Horizontal, vertical, or automatic layouts can improve the readability of complex networks.
• Filtering and highlighting: Unnecessary tasks can be hidden while important paths are emphasized.

Effective formatting helps users trace the sequence of work, locate logical gaps, identify bottlenecks, and understand which activities may affect the final project date.

Formatting makes logical relationships and schedule risks easier to inspect. To support analysis, a project manager can:

• Highlight critical tasks with a distinctive style.
• Display task duration and start and finish dates inside each node.
• Use directional connectors to show predecessor and successor relationships.
• Arrange nodes in sequence so the flow from project start to project finish is clear.
• Display tasks with missing predecessors or successors in a separate style.
• Mark dependency types and lag values where they are relevant.

The critical path is the sequence of activities that determines the project completion date. Highlighting this sequence allows the manager to focus on tasks with little or no total float. Dependency problems, such as isolated tasks, circular relationships, or an incorrect predecessor, become easier to detect when the network is logically arranged and visually consistent.

The Calendar view presents scheduled tasks in a familiar daily, weekly, or monthly calendar layout. Tasks are displayed on the dates during which they are planned to occur.

It provides information about:

• Task names and scheduled dates.
• Task durations and overlapping activities.
• Milestones and deadlines.
• Work planned for a particular day or week.
• Periods with heavy or light scheduled activity.
• Non-working days and calendar exceptions.

Its limitations include:

• It may not display complex task dependencies clearly.
• Long-duration tasks can be difficult to interpret in a compact calendar cell.
• Resource loading and float may not be as visible as in other views.
• The critical path is usually less obvious than in a network diagram.
• Detailed progress and baseline comparisons may require additional fields or views.

Therefore, the Calendar view is useful for short-term planning and communication but should be used with Gantt and Network Diagram views for complete schedule analysis.

A practical procedure is:

1. Open the Calendar view and select the required date range, such as one project week.
2. Set the calendar scale to display days clearly.
3. Configure the view to show task names, durations, milestones, and responsible resources where appropriate.
4. Apply readable colors or patterns to distinguish task categories or status.
5. Mark non-working days clearly so planned work is not confused with unavailable time.
6. Resize or rearrange task boxes to prevent text overlap.
7. Filter the view to show only active, upcoming, delayed, or meeting-relevant tasks.
8. Highlight milestones, deadlines, and tasks requiring decisions.
9. Review the result for readability on screen and on printed reports.
10. Save the formatted view for repeated use.

The view should focus on actionable weekly information rather than displaying every available project field.