Lesson 8: Project Management, Documentation, and Capstone Readiness

Systems projects fail not only because of technical problems but also because of weak management. That is why many curricula connect SAD with project management.

At student level, project management means planning tasks, roles, schedule, deliverables, and monitoring.

Work breakdown

A large project becomes manageable when divided into smaller tasks. Example: problem definition; fact-finding; requirement analysis; process modeling; data modeling; interface design; testing plan; documentation; presentation. This is similar to a simple Work Breakdown Structure.

Scheduling

A schedule identifies what task will be done, by whom, when it starts, when it ends, and what it depends on. In class this may be shown through task lists, timelines, Gantt charts, or milestone tables. Simple dependency logic matters: you cannot fully finalize testing before requirements and design exist.

Team coordination

Usual student roles: project leader, analyst/documenter, UI designer, developer, tester, presenter. Even in small teams, define who owns each deliverable. "Everyone will do everything" often ends in confusion.

Systems Analysis and Design also includes professional judgment. A technically possible system may still be unacceptable if it violates ethics, law, or organizational trust.

Privacy and confidentiality

Personal, academic, medical, and financial records must be handled carefully. Teams should ask: Do we really need this data? Who should see it? How long should we keep it? How is it protected?

Accuracy and accountability

A system should not hide who did what. Audit trails matter, especially when money is involved, approvals exist, or records may be disputed.

Professional conduct

Project teams should avoid plagiarism in documents and diagrams, report limitations honestly, avoid fake evaluation claims, and communicate risks clearly.

Social and organizational impact

A new system may change work distribution, affect staff routines, or require policy changes. Analysts should anticipate these effects, not treat them as someone else's problem.

A mature project answer always considers both technical feasibility and responsible use.