Project Management with Microsoft Project

Course Description

Project Management with Microsoft Project introduces fundamental project management concepts, with students using Microsoft Project to develop and build project plans.

Within the SCNS taxonomy, CTS is the Computer Technology and Software prefix. Daytona State publishes this at 3 credits, prerequisite CGS2100, offered fall, giving approximately 45 contact hours consistent with the published CTS2450 in this repository.

The pairing in the title is worth reading carefully. The tool and the discipline are not the same thing, and the most common failure in project management education is producing people who can operate scheduling software and cannot manage a project. The software encodes a particular model — scope decomposed into tasks, tasks with durations and dependencies, resources assigned — and understanding what that model captures and what it omits is more valuable than fluency with the interface.

Learning Outcomes

Required Outcomes

• Describe what distinguishes a project from ongoing operations.
• Describe the project lifecycle and its phases.
• Describe the project management knowledge areas and process groups.
• Describe the roles of project manager, sponsor, team, and stakeholders.
• Develop a project charter defining objectives, scope, and success criteria.
• Identify and analyze stakeholders and plan communication with them.
• Define scope and construct a work breakdown structure.
• Estimate task durations and describe estimating techniques and their limits.
• Establish task dependencies and describe the dependency types.
• Build a project schedule and calculate the critical path.
• Interpret float and describe its use in schedule management.
• Assign resources, identify over-allocation, and level resources.
• Develop a project budget and describe cost estimating approaches.
• Set a baseline and track progress against it.
• Apply earned value concepts to measure schedule and cost performance.
• Identify, assess, and plan responses to project risks.
• Manage change requests and describe scope change control.
• Produce and interpret project reports, including Gantt and network views.
• Use Microsoft Project to build, resource, baseline, and track a plan.
• Describe quality planning and its role in a project.
• Describe project closure, acceptance, and lessons learned.
• Communicate project status clearly to technical and non-technical audiences.

Optional Outcomes

• Describe agile approaches and contrast them with predictive planning.
• Describe hybrid delivery approaches.
• Describe procurement and contract management in projects.
• Describe programme and portfolio management.
• Describe collaborative and cloud-based project tools.
• Prepare for the CAPM or a comparable entry credential.

Major Topics

Required Topics

• Projects versus operations
• The project lifecycle
• Knowledge areas and process groups
• Roles and responsibilities
• The project charter
• Stakeholder analysis and communication planning
• Scope definition and the work breakdown structure
• Duration estimating
• Dependencies and sequencing
• Schedule development and the critical path
• Float and schedule management
• Resource assignment and levelling
• Budgeting and cost estimating
• Baselines and progress tracking
• Earned value measurement
• Risk identification, assessment, and response
• Change control
• Reporting: Gantt and network diagrams
• Microsoft Project operation
• Quality planning
• Closure and lessons learned
• Status communication

Optional Topics

• Agile approaches
• Hybrid delivery
• Procurement and contracts
• Programme and portfolio management
• Collaborative and cloud tools
• CAPM preparation

Resources & Tools

• Information Technology Project Management (Kathy Schwalbe) — the standard text for a course of this shape, and it integrates Microsoft Project throughout.
• Microsoft Project — the course's tool; check whether your institution provides access through Azure Dev Tools for Teaching or a comparable programme before purchasing.
• ProjectLibre and GanttProject — free and open-source alternatives that implement the same scheduling model; useful for practising at home.
• Microsoft Learn — free official training for Project and Project for the web.
• PMI (pmi.org) — the PMBOK Guide is the field's reference; student membership is inexpensive and includes access.
• CAPM — PMI's entry-level credential, which requires no project experience and is realistic for a student; PMP requires documented experience and comes later.
• Agile Alliance and the Scrum Guide — the Scrum Guide is free, short, and worth reading for the contrast.
• Excel — genuinely useful alongside Project for estimating, tracking, and reporting; see this repository's ISM2000 guide.
• Local PMI chapter — Florida has active chapters, and student rates plus networking are worth the membership.

Career Pathways

• Project coordinator — the realistic entry role, supporting a project manager; this course maps onto it directly.
• Project manager — reached through experience; see the honest note below on sequencing.
• IT project manager — a large market, and technical background is an advantage.
• Business analyst — requirements and scope work overlaps substantially.
• Scheduler or planner — construction, engineering, and defence employ dedicated schedulers, and Microsoft Project or Primavera skill is the qualification.
• Programme and portfolio roles — later-career.
• Operations and process improvement.
• Construction project management — a substantial Florida sector; see this repository's BCN guides.
• Aerospace and defence — Florida's Space Coast runs schedule-driven programmes and employs planners.
• SOC codes 13-1082 Project Management Specialists and 11-3021 Computer and Information Systems Managers.

Special Information

⚠ The tool is not the discipline — and a beautiful plan can still fail

The framing that determines whether this course produces a project manager or a scheduler.

• Microsoft Project will happily produce a detailed, precise, entirely wrong plan. It calculates faithfully from whatever estimates and dependencies you enter; it has no opinion about whether they are realistic.
• Garbage estimates produce garbage schedules. The critical path is computed from durations, and durations are guesses. A schedule showing completion on a specific date carries a precision the underlying estimates do not support.
• Projects fail for reasons the software cannot model — unclear objectives, absent sponsorship, stakeholders who disagree about what success means, unavailable people, and requirements that change because they were never understood. None of those appear on a Gantt chart.
• Over-decomposition is a common error. A work breakdown structure with four hundred tasks is unmaintainable, and the effort of updating it displaces the effort of managing.
• The plan's value is largely in the planning. Building it forces the conversations that surface disagreement, missing work, and unrealistic expectations — which is why the exercise is worth doing even when the plan changes.
• Update it or abandon it. A stale plan is worse than none because it produces confident false reporting.
• Manage the people, not the file. A project manager who spends the week in the scheduling tool and not with the team is doing the visible part of the job and not the effective part.

⚠ Critical path and float are the two concepts worth genuinely understanding

The technical core, and the part most examinable and most practically useful.

• The critical path is the longest sequence of dependent tasks, and it determines the project's minimum duration. Tasks on it have zero float — a day lost is a day lost from the project.
• Float is slack. A task with five days of float can slip five days without affecting the end date, which is what tells you where to relax and where to intervene.
• Compressing the schedule has costs. Crashing adds resources and increases cost; fast-tracking overlaps tasks that were sequential and increases risk. Both only help on the critical path — adding people to a non-critical task changes nothing.
• The critical path moves. As tasks complete or slip, a different sequence can become critical, which is why recalculating rather than assuming is necessary.
• Dependencies should be real. Finish-to-start is the default and it is over-used; genuinely parallel work modelled as sequential inflates the schedule artificially.
• Be careful with constraints. Hard date constraints override the logic and produce schedules that look feasible and are not. Let the dependencies drive the dates wherever possible.
• Resource levelling changes everything. A schedule that is achievable in the abstract may be impossible once you notice one person is assigned to three simultaneous tasks — and levelling frequently extends the end date, which is information rather than a problem.

⚠ Estimates are uncertain — and pretending otherwise is the root of most schedule failure

• Estimates are predictions, and predictions about work are systematically optimistic. The planning fallacy is well documented, and it applies to experienced estimators as much as to novices.
• Estimate ranges, not points. Three-point estimating — optimistic, most likely, pessimistic — produces a more honest figure and communicates uncertainty.
• Have the people doing the work estimate it, and be aware that they will still be optimistic.
• Use historical data where it exists. Analogous and parametric estimating from past projects beats intuition.
• Padding hidden in every task is worse than explicit contingency. Buffers concealed inside estimates get consumed invisibly; a stated contingency reserve is managed.
• Effort and duration are different. Forty hours of work is not one week if the person is only available half-time, and the tool distinguishes them for a reason.
• Communicate uncertainty honestly. "We expect completion between mid-March and mid-April, most likely late March" is more useful and more defensible than a single date that everyone treats as a commitment.

The related discipline: scope change control. Requirements change legitimately, and the professional response is not to refuse but to make the trade-off visible — additional scope means additional time, cost, or reduced scope elsewhere. Scope creep is what happens when changes are accepted without that conversation, and it is the most common way projects quietly fail.

⚠ The honest career note — and the agile question

• Few people are hired directly as project managers. It is a role built on domain knowledge and delivery experience; project coordinator or an analyst role is the realistic entry, and this course maps onto that.
• Domain knowledge matters. Managing a software project, a construction project, and an event require different technical understanding, and credibility with the team comes from it.
• CAPM is achievable now — PMI's entry credential requires no project experience. PMP requires documented experience and is the credential that carries weight later.
• Learn agile too. Much of software and product delivery uses iterative approaches in which detailed up-front schedules are deliberately avoided. The Scrum Guide is free and short; reading it clarifies what the predictive model assumes.
• Neither approach is universally right. Predictive planning suits work with well-understood scope and hard dependencies — construction, infrastructure, regulated delivery. Iterative approaches suit work where requirements are discovered. Hybrid is common in practice, and dogmatism about either is a poor professional signal.
• Microsoft Project skill is genuinely marketable in construction, engineering, defence, and government, where schedules are contractual — Primavera P6 is the other major tool in those sectors.
• Soft skills are the job. Negotiation, communication, and managing people you do not have authority over are what distinguish effective project managers, and they are not in the software.

⚠ Only about three Florida institutions carry this number — hedge accordingly

This course appears at roughly three institutions statewide. Content, credit value, and emphasis vary more than they would for a widely taught course. Read your own institution's catalog description and syllabus rather than assuming this guide describes your section exactly, and have any transfer evaluated in writing.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement.

CTS2214 is 3 credits and approximately 45 contact hours, offered fall. Expect hands-on plan building in Microsoft Project — a work breakdown structure, a resourced and baselined schedule, tracking against it, and reports — alongside the conceptual material. Build the plan for a real project if you can; the estimating and stakeholder problems only become real when someone else has an opinion about the answer.

The course transfers on the ordinary lower-division basis. Computing and business A.S. degrees are applied and do not carry the A.A.'s guaranteed junior-status transfer, though Florida institutions publish B.A.S. and B.S. pathways for that population.