Project Organization and Communication

1
Project Organization and Communication

• Roadmap for todays class
• Project organization
• organization
• roles
• tasks and work products
• schedule Gantt chart, PERT chart
• Communication
• Finish last lecture on SE Introduction
• A note on Microsoft Visio CS MSDNAA download on
  web page help.cs.gsu.edu

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 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
5
A Simple Project Organization
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
• Clearly defined career path

9
Hierarchical Project Organization
Chief Executive
First Level Manager (Front-Line Manager)
Project Members
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
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
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 members 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 teams 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

Object-Oriented Project Management with UML by
Murray Cantor
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 memberss 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
• The Task Role Table (shown below)

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 projects
  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.

19
Project Management Tools PERT Chart

• PERT stands for Program Evaluation Review
  Technique, a methodology developed by the U.S.
  Navy in the 1950s to manage the Polaris submarine
  missile program.
• A PERT chart is a project management tool used to
  schedule, organize, and coordinate tasks within a
  project.
• PERT charts contain detailed information relating
  to the activities necessary to produce the
  required products.
• The PERT chart also clearly identifies the
  critical path, which is an invaluable concept in
  project planning - as it defines that sequence of
  activities that should take the longest time.

20
Project Management Tools PERT Chart
Dependency Critical path
Source http//www.softwareprojects.org/project_pr
ogress_ganttpert56.htm
21
Example a schedule for system integration testing
22
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.
• While the PERT chart is one of the most useful
  aids to effective project management, senior
  managers will not usually want to see this level
  of detail. When project management staff need to
  communicate information to senior management,
  Gantt charts, histograms and other graphical
  techniques are the preferred presentation format.

23
Gantt Chart
Activity 1


Activity 2
Activity 3


Activity 4
Activity 5

1
2
3
4
5
6
7
0
Time (in weeks after start)
Easy to read
24
Gantt Chart
with milestones
Activity 1


Activity 2
Activity 3


Activity 4
Activity 5

1
2
3
4
5
6
7
0
Time (in weeks after start)
Good for reviews.
25
Two Types of Gantt Charts

• Person-Centered View
• To determine peoples load

• Activity-Centered View
• To identify teams working together on the same
  tasks

Joe
A1
A3
A2
A1
Joe, Toby
Mary
Joe
A2
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
26
Review All These Concepts
Work on an Example Together Class Project of CSC
4350/6350

• Organization Chart
• Tasks and roles table
• Schedule Chart Pert chart, Gantt chart

27
(No Transcript)
28
A Communication Example

• "Two missile electrical boxes manufactured by
  different contractors were joined together by a
  pair of wires.

Box 1
Box 2
Pair of Wires
29
A Communication Example (continued)

• Thanks to a particular thorough preflight check,
  it was discovered that the wires had been
  reversed."

Box 1
Box 2
30
After the Crash...

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

31

• In fact, both of them had.

Box 1
Box 2
32
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 your
  project 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 your project

33
Definitions

• Communication event
• Type of information exchange that has defined
  objectives and scope
• Scheduled Planned communication (e.g., review,
  meeting)
• UnscheduledEvent-driven communication (e.g.,
  request for change, issue clarification, problem
  report)
• Communication mechanism
• Synchronous Sender and receiver are available at
  the same time
• Asynchronous Sender and Receiver are not
  communicating at the same time.

34
Classification of Communication
is supported by


35
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

36
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

37
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
• Scheduled every week

38
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

39
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

40
Example of Request for Clarification

• From Alice
• Newsgroups cs413.architecture.discuss
• Subject SDD
• Date Thu, 10 Oct 231248 -0400
• Message-ID lt325DBB30.4380_at_andrew.cmu.edugt
• MimeVersion 1.0
• Content-Type text/plain charsetus-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

41
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 ltltDescription of the problemgtgt
• Rationale ltltWhy the change should be donegtgt
• Proposed solution ltltDescription of desired
  changegtgt

42
Example of Issue Base
43
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

44
Meeting Roles

• Primary facilitator
• 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

45
Structure of a Meeting Agenda
46
Asynchronous Communication Mechanisms

• E-Mail
• Supports Release, change request, brainstorming
• Pro Ideal for planned communication events and
  announcements.
• Con E-mail taken out of context can be easily
  misunderstood, sent to the wrong person, lost or
  not read by the receiver.
• Newsgroups
• Supports Release, change request, brainstorming
• 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

47
Summary

• Communication Events
• 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, email,
  web)

48
After this class

• Group formed and project topic selected
• UML