IT Project Management

Course Description

IT Project Management introduces the concepts, methodologies, techniques, and tools of managing software development, and extends to the configuration of hardware, computer networks, and communication systems. It is the course in which computing students learn that delivering a system is a different problem from building one.

Within the SCNS taxonomy, CIS is the Computer Information Sciences prefix, and the 4000-level number places this in the upper division — the senior year of a B.S. in information technology, computer science, or software engineering. Daytona State publishes it at 3 credits with prerequisite CEN4801, offered in spring. It appears at approximately three Florida institutions.

The subject earns its place in a computing curriculum for an unglamorous reason: software projects fail at a high rate, and they rarely fail for technical reasons. They fail on unclear requirements, scope that grew without a corresponding change in schedule or budget, communication that did not happen, and estimates that were never realistic. Those are management problems, and an engineer who does not understand them is a good engineer on a doomed project.

Learning Outcomes

Required Outcomes

• Describe the project management lifecycle and the distinct concerns of each phase.
• Describe what distinguishes IT and software projects from projects generally.
• Develop a project charter and define scope, deliverables, and acceptance criteria.
• Elicit, document, and manage requirements, and trace them through to delivery.
• Construct a work breakdown structure for a software or infrastructure project.
• Estimate effort, duration, and cost, and state the basis and uncertainty of the estimate.
• Build and manage a schedule, identifying the critical path and dependencies.
• Plan and manage resources, including staffing and skill availability.
• Develop and control a project budget.
• Identify, assess, and plan responses to project risks, and maintain a risk register.
• Apply change control and distinguish legitimate change from scope creep.
• Compare predictive, agile, and hybrid delivery approaches and select appropriately.
• Apply agile practice: iterations, backlogs, estimation, and review.
• Plan for quality, testing, and defect management within a project.
• Plan deployment, migration, configuration, and operational handover.
• Manage stakeholders and communicate status honestly to technical and non-technical audiences.
• Use project management tooling to plan, track, and report.
• Conduct project closure and a retrospective that produces usable lessons.

Optional Outcomes

• Describe vendor selection, procurement, and contract types.
• Describe IT governance frameworks and portfolio management.
• Describe DevOps and continuous delivery and their effect on project structure.
• Describe security and privacy requirements as project constraints.
• Describe managing distributed and outsourced teams.
• Prepare for the CAPM or an agile certification.

Major Topics

Required Topics

• The project lifecycle and the project manager's role
• Why IT projects differ; the historical failure record
• Project charter, stakeholders, and scope definition
• Requirements elicitation, documentation, and traceability
• Work breakdown structure
• Estimation techniques and estimation error
• Scheduling, dependencies, and the critical path
• Resource and staffing planning
• Cost estimation, budgeting, and control
• Risk identification, analysis, and response
• Change control and scope management
• Predictive, agile, and hybrid delivery models
• Agile practice: Scrum, backlogs, sprints, and velocity
• Quality planning, testing strategy, and defect management
• Deployment, migration, configuration, and handover
• Stakeholder management and status communication
• Project tooling and tracking
• Closure, retrospectives, and organizational learning

Optional Topics

• Procurement, vendors, and contracts
• IT governance and portfolio management
• DevOps and continuous delivery
• Security and privacy as project constraints
• Distributed and outsourced teams
• Certification preparation

Resources & Tools

• Information Technology Project Management (Kathy Schwalbe) — the standard text for this course specifically, and better suited than a general project management text.
• PMI — the PMBOK Guide, the Agile Practice Guide, and the CAPM credential pathway.
• The Mythical Man-Month (Brooks) — old and still the most quoted book in the field; Brooks's law and the second-system effect are directly relevant.
• Making Things Happen (Scott Berkun) or Peopleware (DeMarco, Lister) — the practitioner literature on why software teams actually fail.
• Tooling: Jira, Azure DevOps, Trello, Asana, or Microsoft Project; free alternatives include ProjectLibre and GitHub Projects.
• Scrum Guide (scrumguides.org) — free, short, and the authoritative definition of Scrum.
• Published post-mortems of failed public IT projects — extensively documented, free, and the most instructive case material available.
• Version control and CI/CD tooling the program already uses, viewed as project infrastructure.

Career Pathways

• IT project manager and technical project manager — the direct destination.
• Scrum master and agile delivery lead — a common entry point from a technical background.
• Product owner or product manager — a distinct and well-compensated path from the requirements half of this course.
• Business analyst — requirements elicitation is the core skill.
• Technical lead — engineers who understand delivery are the ones promoted to lead teams.
• PMO analyst — project management office roles.
• IT manager and director — with experience.
• Consulting and systems integration — where delivery discipline is the product.
• Florida employers: healthcare systems with substantial IT portfolios, financial services in Jacksonville and South Florida, the defense and aerospace corridor, theme park and hospitality technology organizations, state agencies, and a large managed services sector. SOC codes 15-1299 Project Management Specialists (IT) and 11-3021 Computer and Information Systems Managers.

Special Information

⚠ Requirements are where IT projects actually fail

The single most useful thing in the course. Surveys of software project failure have consistently identified incomplete, changing, or misunderstood requirements among the leading causes — well ahead of technical difficulty.

The mechanism is ordinary. A stakeholder describes what they want; the developer builds what was described; the stakeholder sees it and says that is not what they meant. Nobody lied and nobody was incompetent — the requirement was never actually shared, because natural language is ambiguous and because people frequently cannot articulate what they need until they see something wrong.

The practices that address it, and which this course should teach as habits:

• Show something early. Prototypes, wireframes, and working increments elicit correction far more effectively than documents elicit agreement. This is the strongest single argument for iterative delivery.
• Write acceptance criteria — a requirement without a testable definition of done is not a requirement.
• Trace requirements through to test. Traceability sounds bureaucratic and is what prevents a requirement from quietly disappearing.
• Talk to the people who will use it, not only to the people who commissioned it. They are frequently different, and they frequently want different things.

⚠ Estimation is systematically wrong in a predictable direction

Software estimates are optimistic, consistently and across decades of evidence. The causes are well documented: the planning fallacy, in which people underestimate their own tasks even having underestimated identical tasks before; anchoring on a desired date; and the fact that the work not thought of at estimation time is precisely the work that consumes the schedule — integration, environment problems, defect repair, and dependency waits.

Three defenses worth adopting:

• Reference class forecasting — how long did comparable projects actually take, rather than how long should this one take.
• Estimate ranges, not points, and communicate the range. A single number is heard as a commitment.
• Track actuals against estimates, which is the only way an organization ever improves. Most do not, which is why most keep estimating badly.

Brooks's law belongs here and is worth stating: adding people to a late software project makes it later, because of onboarding cost and the combinatorial growth in communication paths. It is not universally true, but it is true often enough that the instinct to fix a schedule by adding staff should be resisted.

⚠ Agile is not the absence of management, and the failure modes are specific

Students frequently arrive with a caricature: agile as freedom from process. The reality is that agile redistributes management work rather than removing it, and it fails in recognizable ways.

• The product owner role is where agile most often fails. Organizations supply someone without decision authority, without availability, or without domain knowledge, and a backlog that is an unordered wish list is the same as having no priorities.
• Velocity is a forecasting tool, not a performance measure. The moment it is used to evaluate or compare teams it stops being honest — story points are relative and team-specific, cross-team comparison is meaningless by construction, and a team measured on velocity inflates estimates while delivering identical work. This is the same dynamic this repository documents for earned value, KPIs, and repeat-rate analysis: a measure used as a target stops measuring what it did.
• "Agile" as an excuse for no documentation, no design, and no plan is not agile; the manifesto values working software over comprehensive documentation, not instead of all of it.
• Hybrid is normal. Most real organizations run something between predictive and agile, particularly where procurement, compliance, or infrastructure dependencies impose fixed milestones. A graduate who can only operate in one mode is limited.

The underlying point: agile requires organizational change, not just team practice, and a team practising Scrum inside an organization that fixes scope, schedule, and budget in advance is doing ceremonies rather than agile.

⚠ Honest status reporting is a professional obligation and a career skill

The behavior that most distinguishes a good project manager, and the one under most pressure.

The "watermelon" status report — green on the outside, red on the inside — is a recognized organizational pathology. Projects report green until they cannot, and then report red with no time left to respond. It happens because reporting bad news is uncomfortable and because organizations often punish it.

What the course should teach: report the trend, not just the state; escalate early enough that someone can act, which is the entire purpose of escalation; and bring the options with the problem — "we will miss the date; here are three things we could cut, and here is what each costs" is a professional communication, while "we're going to be late" is not.

This connects to the ethics content in CIS4250: an engineer or manager who conceals a schedule or quality problem is making an ethical choice, not merely a political one.

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

This course appears at roughly three institutions statewide, which is a small base. Content, credit value, and emphasis vary more than they would for a widely taught course, and one of the three may be a private institution rather than a Florida public college. 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.

Course format and transfer

CIS4510 is a lecture course, 3 credits and approximately 45 contact hours, consistent with this repository's upper-division computing courses. Daytona State requires CEN4801 and offers it in spring. Expect a team project carried through planning, execution, and closure with real deliverables — charter, WBS, schedule, risk register, status reports, and a retrospective — alongside case analysis of documented project failures.

The team project is the point, and it teaches by producing the very problems the course describes: someone will not deliver, the scope will grow, and the estimate will be wrong. Students who treat that as the curriculum rather than as bad luck get the most out of it.

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.

CIS4510 is upper division: a lower-division project management or business course will not substitute for it, and neither will a general management course such as MAN4583, because the requirement in a computing program is for IT project management. Have any substitution evaluated in writing.