1. Project Organization and Communication
Roadmap for today’s class
Project organization
organization
roles
tasks and work products
schedule – Gantt chart, PERT chart
Communication

2. Some Questions Related to Project Organization and Communication
Who is responsible for which part of the system
Which part of the system is due by when
Who should be contacted when a problem with a specific version of a component is discovered
In which form should new requirements be communicated to developers
Who should be informed of new requirements
Who is responsible for talking to the client

3. Basic Elements of a Project
Work Product
Schedule
Task
Participant
Project
Work Product: This is any item produced by the project
Schedule: This specifies when work on the project should be accomplished
Participant: This is any person participating in a project
Task. This is the work to be performed by a project participant to create a work product.

4. Team-based Organization*
Team *
Participant

5. A Simple Project Organization
Managerment
Team
Database
Team
Control
Team
UserInterface
Team
Member1
Member2 …

6. Relationships between Participants
Organizations can have many different types of associations between participants
The three most important associations for project organizations are: Reporting, decision making and communicating
Reporting association:
Used for reporting status information
Decision association
Used for propagating decisions
Communication association
Used for exchanging information needed for decisions (e.g., requirements, design models, issues).

7. An Organization with a Reporting and Decision Structure
The developers make local decisions and reports them via a status report to the leader (team leader, project manager)
The team leader, who has a local overview of the subsystem, can override these decisions. She reports them to the project manager.
The project manager, who has a global view of the project, can virtually override any decision.

8. Hierarchical Organization
Often also called centralized organization. Examples: Military, church, traditional businesses.
Key property: The organization has a tree structure. Decisions are made at the root and communicated to the leaf nodes. The decision association is also used for reporting and communication.
Advantages:
Centralized control over project selection
One set of management and reporting procedures for all project participants across all projects
Established working relationships among people
Clearly established lines of authority to set priorities and resolved conflicts
Authority to pressure people to honor their action items
Clearly defined career path

9. Hierarchical Project Organization
Control Flow
Information Flow
Chief Executive
First Level Manager
(“Front-Line Manager”)
Project Members A B
A wants to talk to B: Complicated Information Flow
B wants to make sure A does a certain change: Complicated Controlflow
Basis of organization:
Complicated information and control flow
across hierarchical boundaries

10. Liaison Based Project Organization
UserInterface
:Team
role
Alice
:Develolper
John
Mary
Chris
Sam
Team leader
API engineer
Documentation liaison
implementator
Management:
Team
communicates
Architecture:
Documentation:
Testing:

11. Definition: Role A role is a set of responsibilities
A role is instantiated during a project and assigned to one or more persons.
Instances of roles are often also called players („who are the key players?“) or stakeholders

12. Different types of roles
Developer
Liaison
Manager
Consultant
API Engineer
Document Editor
Configuration manager
Tester
Project Manager
Tam Leader
Application
Domain Specialist
Solution
Client
End User

13. Key Roles in Organizations
Project Manager: The person ultimately responsible for the successful completion of the project
Project Team Member: Participants who are responsible for performing individual activities and tasks (in a project organization)
Functional Manager: The team member‘s supervisor in the department (in a functional organization)
Upper management: People in charge of the departments or projects

14. Responsibilities of the Project Manager
Determine objectives, schedule and resource budgets
Design a software project management plan (SPMP)
Create and sustain focused and motivated teams
Determine the team‘s work procedures, reporting systems and communication infrastructure.
Accomplish project objective within time and budget
Monitor performance against the plan
Resolve technical conflicts and interpersonal conflicts
Control changes in the project
Report on project activities to upper management
Keep the client informed and committed
Contribute to the team members performance approval

15. General Responsibilities of Team Members
Technical responsibilities:
Perform assigned tasks within time and budget
Acquire technical skills and knowledge needed to perform the work
People responsibilities
Identify situations and problems that might affect your team members‘s tasks
Keep your team members informed of your progress and problems you encounter

16. Tasks and Work Products
A task is a well-defined work assignment of a role
Gruops of related tasks are called activities
A work product is a tangible item that results from a task

17. Tasks and Work Products
A task is a well-defined work assignment of a role
Gruops of related tasks are called activities
A work product is a tangible item that results from a task
Task name
Assigned role
Task description
Input
Output
Database subsystem Requirements elicitation
System architect
Elicits requirements..
Team liaisons
Database subsystem API
Database subsystem design
Object designer
Designs the database …
Subsystem API
Database subsystem design (UML diagram)
Schedule the tasks

18. How to develop an Initial Project Schedule
Identify all your activities (reuse a template if possible)
Identify intermediate and final dates that must be met
Assign milestones to these dates
Identify all activities and milestones outside your project that may affect your project’s schedule
Identify “depends on” relationships between all these identified activities
Draw a dependency diagram for all identified activities and relationships
Analyze the diagram to determine critical paths and slack times of noncritical paths.
Example: Establish a schedule for system integration testing

19. PERT Chart
Critical path

20. Gantt Chart
A Gantt chart is a compact way to represent the schedule of a software project along the time axis.
It is a bar graph on which the horizontal axis represents time and the vertical axis lists the different tasks to be done.
Tasks are represented as bars whose length corresponds to the planned duration of the task.

21. Gantt Chart Easy to read Activity 1 Activity 2 Activity 3 Activity 41 2 3 4 5 6 7
Time (in weeks after start)
Easy to read

22. Gantt Chart with milestones Good for reviews. Project Start Activity 1
Design Review
Activity 4
Activity 5
Project Finish 1 2 3 4 5 6 7
Time (in weeks after start)
Good for reviews.

23. Two Types of Gantt Charts
Person-Centered View
To determine people‘s load
Activity-Centered View
To identify teams working together on the same tasks
Joe A1 A2 A3 A1
Joe, Toby
Mary A2
Joe
Toby A1 A3 A3
Clara, Toby, Joe
Clara A3
Time
Time
Choose one view, stay with it. Usually base the view on the WBS structure
Managing Experienced Teams: Person-centered view
Managing Beginners: Activity oriented view

24. Review All These Concepts
Work out An Example Together
Class Project of CSC 4350/6350
Organization Chart
Tasks and roles table
Schedule Chart – Gantt chart

25. A Communication Example
"Two missile electrical boxes manufactured by different contractors were joined together by a pair of wires.
Box 1
Pair of Wires
Box 2

26. A Communication Example (continued)
Thanks to a particular thorough preflight check, it was discovered that the wires had been reversed."
Box 1
Box 2

27. After the Crash...
...
"The postflight analysis revealed that the contractors had indeed corrected the reversed wires as instructed."

28. “In fact, both of them had.”
Box 1
Box 2

29. Communication is important
In large system development efforts, you will spend more time communicating than coding
A software engineer needs to learn the so-called soft skills: technical writing, reading documentation, communication, collaboration, management, presentations.
In this course, we ask each of you to (acquire and) demonstrate the following skills:
Management: Run a team meeting
Presentation: Present an major aspect of STARS during its development phase.
Collaboration: Negotiate requirements with the client and with members from your team and other teams.
Technical writing: Write part of the documentation of STARS

30. Definitions Communication event
Type of information exchange that has defined objectives and scope
Scheduled: Planned communication (e.g., review, meeting)
Unscheduled:Event-driven communication (e.g., request for change, issue clarification, problem report)
Communication mechanism
Tool or procedure that can be used to transmit information
Synchronous: Sender and receiver are available at the same time
Asynchronous: Sender and Receiver are not communicating at the same time.

31. Classification of Communication
Event
is supported by
Communication
Mechanism * *
Planned
Event
Unplanned
Event
Synchronous
Mechanism
Asynchronous
Mechanism

32. Planned Communication Events
Problem Definition
Objective: Present goals, requirements and constraints
Example: Client Presentation
Usually scheduled at the beginning of a project.
Project Review: Focus on system model
Objective: Assess status and review system model, system decomposition, and subsystem interfaces
Examples: Analysis Review, System Design Review
Scheduled around project milestones and deliverables
Client Review: Focus on requirements
Objective: Brief client, agree on requirements changes
Client Review
Usually scheduled after analysis phase

33. Planned Communication Events (continued)
Walkthrough (Informal)
Objective: Increase quality of subsystem
Example: Developer presents subsystem to team members, informal, peer-to-peer
To be scheduled by each team
Inspection (Formal)
Objective: Compliance with requirements
Example: Client acceptance test (Demonstration of final system to customer)
To be scheduled by project management

34. Planned Communication Events (continued)
Status Review
Objective: Find deviations from schedule and correct them or identify new issues
Example: Status section in regular weekly team meeting
Scheduled every week
Brainstorming
Objective: Generate and evaluate large number of solutions for a problem
Example: Discussion section in regular weekly team meeting

35. Planned Communication Events (continued)
Release
Objective: Baseline the result of each software development activity
Software Project Management Plan (SPMP)
Requirements Analysis Document (RAD)
System Design Document (SDD)
Object Design Document (ODD)
Test Manual (TM)
User Manual (UM)
Usually scheduled after each phase
Postmortem Review
Objective: Describe Lessons Learned
Scheduled at the end of the project

36. Unplanned Communication Events
Request for clarification
The bulk of communication among developers, clients and users.
Example: A developer may request a clarification about an ambiguous sentence in the problem statement.
Request for change
A participant reports a problem and proposes a solution
Change requests are often formalized when the project size is substantial.
Example: A participant reports of a problem the air conditioner in the lecture room and suggests a change.
Issue resolution
Selects a single solution to a problem for which several solutions have been proposed.
Uses issue base to collect problems and proposals

37. Example of Request for Clarification
From: Alice
Newsgroups: cs413.architecture.discuss
Subject: SDD
Date: Thu, 10 Oct 23:12:
Message-ID:
MimeVersion: 1.0
Content-Type: text/plain; charset=us-ascii
When exactly would you like the System Design Document? There is some confusion over the actual deadline: the schedule claims it to be October 22, while the template says we have until November 7.
Thanks,
Alice

38. Example of a Change Request
Report number: 1291
Date: 5/3
Author: Dave
Synopsis: The STARS client crashes when empty forms are submitted.
Subsystem: User interface
Version: 3.4.1
Classification: missing/incorrect functionality, convention violation, bug, documentation error
Severity: severe, moderate, annoying
Description: <<Description of the problem>>
Rationale: <<Why the change should be done>>
Proposed solution: <<Description of desired change>>

39. Example of Issue Base

40. Synchronous Communication Mechanisms
Smoke signals
Supports: ?, Pros: ?, Cons: ?
Hallway conversation (face-to-face)
Supports: Unplanned conversations, Request for clarification, request for change
Pro: Cheap and effective for resolving simple problems
Con: Important information can be lost, misunderstandings can occur when conversation is relayed to others.
Meeting (face-to-face, telephone, video conference)
Supports: Planned conversations, client review, project review, status review, brainstorming, issue resolution
Pro: Effective mechanism for resolution of isssues, and building consensus
Con: High cost (people, resources); difficulty of managing them and getting effective results

41. Meeting Roles Primary facilitator Minute taker Time keeper
Responsible for organizing the meeting and guiding the execution.
Writes the agenda describing objective and scope of meeting.
Distribute the agenda to the meeting participants
Minute taker
Responsible for recording the meeting.
Identifies action items and issues
Release them to the participants
Time keeper
Responsible for keeping track of time

42. Structure of a Meeting Agenda

43. Asynchronous Communication Mechanisms
Supports: Release, change request, brainstorming
Pro: Ideal for planned communication events and announcements.
Con: taken out of context can be easily misunderstood, sent to the wrong person, lost or not read by the receiver.
Newsgroups
Pro: Suited for notification and discussion among people who share a common interest; cheap (shareware available)
Con: Primitive access control (often, you are either in or out)
World Wide Web
Supports: Release, change request, inspections
Pro: Provide the user with a hypertext metaphor: Documents contain links to other documents.
Con: Does not easily support rapidly evolving documents

44. Summary Communication Events Communication Mechanisms
Planned (stipulated by the schedule)
Unplanned (driven by unexpected events)
Communication Mechanisms
Asynchronous communication mechanisms
Synchronous communication mechanisms
Important events and mechanisms
Weekly meeting
Project reviews
Online communication (discussion forum, , web)