1 / 26

3 – PROJECT COMMUNICATION

3 – PROJECT COMMUNICATION. INTRODUCTION Need for collaboration from different experts, background, experiences, agreement on changes, information sharing, participant interactivity, crises management, and global understanding Requires a number of tools, techniques, and modalities

calix
Download Presentation

3 – PROJECT COMMUNICATION

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 3 – PROJECT COMMUNICATION • INTRODUCTION • Need for collaboration from different experts, background, experiences, agreement on changes, information sharing, participant interactivity, crises management, and global understanding • Requires a number of tools, techniques, and modalities • EXAMPLE: The Ariane 4 navigational system failure due to lack of communication about the testing of the navigational ‘component’ system test and the overall system team.

  2. 3.2 OVERVIEW of PROJECT COMMUNICATION • Modes of Communication • Type of communication with defined objectives and scope, e.g., client review, problem reporting • Communication type: could be scheduled (a planned event) or event-driven (nondeterministically) • Mechanisms of Communication • Means, procedures, and tools for effecting communication (e.g., fax, email, phone, signals) • Types: synchronous (all party engagement) and asynchronous (not all party engagement) • Both types of mechanism can support scheduled communication, but event-driven communication can be supported by asynchronous mechanism • Example Scheduled Comm: client reviews, status reporting, system release • Example Event-Driven Comm: request for changes, clarifications, issue resolution • (See Fig. 3-1 and Fig 3-2)

  3. Communication Communication Mode Mechanism is supported by * * Scheduled Event-driven Synchronous Asynchronous Mode Mode Mechanism Mechanism Figure 3-1. Classification of communication modes and mechanisms (UML class diagram).

  4. Client Review Smoke Signals :Scheduled Mode :Synchronous Mechanism Problem Reporting Fax: Asynchronous :Event-driven Mode Mechanism is supported by is supported by is supported by Figure 3-2. Examples of modes and mechanisms (UML class diagram). Both scheduled modes and event-driven modes can be supported by asynchronous mechanisms. Event-driven modes, however, can only be supported by asynchronous mechanisms.

  5. 3.3 MODES OF COMMUNICATION • Scheduled: planned according to a periodic process, well-organized, focused, typically face-to-face on broader issues. (See Table 3-1) • Event-driven: spontaneous, caused by specific event, informal, focused on minor/single issues. (See Table 3-2) • Mode 1: Problem Definition – • Between client and project manager, resulting in problem definition which includes goals, constraints, and other non-functional requirements (e.g., platform selection and timing/performance issues) • It involves extracting requirements knowledge and domain knowledge from the client/user • The scope of the meeting includes application domain, both functional and non-functional requirements, and delivery schedules • E.g. The FRIEND Problem Statement (a shift from a paper-based system to fully automated, network of system components such as databases, communication systems, coordination systems, archival systems, and data sharing capabilities)

  6. MODES of COMMUNICATION - 2 • Mode 2: Client Reviews – • Involves a formal meeting/presentation between the client and developer. The meeting is typically on a finished by-product, where the discussion focuses on what goals and what constraints are important to the client. The developer modifies the product to respond to any recommended changes as a result of feedback from the client. • It involves ensuring that the system being constructed meets client’s specification, review of non-functional requirements, review of delivery schedule • The scope includes functional and non-functional requirements and delivery schedule • (See Fig 3-3 for an example Client Review agenda.)

  7. MODES OF COMMUNICATION - 3 • Mode 3: Project Review – • A formal presentation (of a finished document) between the project manager and subsystem developers. Focus is typically on subsystem interfaces, facilitating information sharing across teams. • Focus areas: • if system design document, it could involve system decomposition and interfaces • If object design document, it could involve object interfaces or signatures • If system testing, it could involve test cases, coverage, interface consistency • It involves ensuring that dependent subsystem can communication, assess possible late delivery and changes, disseminate operational knowledge across teams. • The scope includes system design, object design, and testing

  8. MODES OF COMMUNICATION - 4 • Mode 4: Inspection/Walkthroughs • Peer review of subsystems for quality evaluation, where a developer presents a line-by-line analysis of code for other team members to critique (walkthrough) OR the team members’ analysis of the entire code for compliance to client’s specification or criteria for the developer to respond to • The focus on the assurance of correct and quality of the implementation of subsystems, sharing operational knowledge across teams • It involves the code’s implementation and compliance

  9. MODES OF COMMUNICATION - 5 • Mode 5: Status Reviews – • Task-oriented meeting of team members on periodic basis - weekly for a team or monthly for a project-wide review. • Objectives include detecting deviation from planned schedule, ensuring timely completion of planned deliverables, and sharing of operational and potential issues through the minutes of the review process. Minutes are reviewed and feedback is quickly disseminated for effective changes. • It involves defined tasks, action items and timelines, and issues

  10. MODES OF COMMUNICATION - 6 • Mode 6: Brainstorming – • It allows the generation and evaluation of solutions proposed by all participants • Allows consensus building on proposed solutions. • It focuses on a single issue • Mode 7: Releases – • Used to make available large amount of info on new versions of artifacts, which could be simple or complex pieces of information. Releases typically precede or trigger other reviews. • (See Fig 3-4 – an example release announcement)

  11. MODES OF COMMUNICATION - 7 • Mode 8: Postmortem Review – • It could be done during brainstorming sessions, through a survey instrument, interviews, or individual reports aimed at extracting operational knowledge from the client/user shortly after system delivery • Focus areas include the assessment of tools, techniques, methods, organizational strategies, procedures, project planning strategy, and overall project management strategy used • Results of postmortem reviews – lessons learned - are disseminated formally via reports or informally by team members • (See Fig 3-5)

  12. MODES OF COMMUNICATION - 8 • Mode 9: Request for Clarification – • Event-driven, and occurs informally even during other review processes. Frequent request for clarification indicates a troubled system – least understood by most developers • (See Fig 3-6 – example) • Mode 10: Request for Change – • Event-driven, called for due a sudden problem or proposals (e.g., for solutions, ideas) • The scope could be small (thus, informal among few developers) or large (thus, formally reviewed by all developers) • Items in the request for change form include the problem, its description and context, rationale for the change, and proposed solutions • (See Fig 3-7)

  13. MODES OF COMMUNICATION - 9 • Mode 11: Issue Resolution – • It involves the documentation and communication of a final resolution on an issue (or issues), facilitating later references by developers and synchronization among developers • An issue based process: The resolution document includes 1) the messages exchanged, 2) message captions (denoted by an I for issue, P for proposed solutions, A+ for pro-arguments, and A- for cons-arguments) • (See Fig 3-8)

  14. Figure 3-8. An example of an issue base (Domino Lotus Notes database).

  15. 3.4 MECHANISMS OF COMMUNICATION • SYNCHRONOUS – same-place or different-place mechanism requiring all participants presence • Same-place: typically informal and low technical content, allows non-verbal communication (demonstrations and graphical/audio-visual presentations), consensus building, more flexible, costly to organize and implement • Different-place: groupware oriented, less costly, allows electronic-online reviews, editing, browsing of documents at the meeting, hence, requires high bandwidth (see Table 3-3) • ASYNCHRONOUS – groupware oriented, no formal face-to-face meeting, • allows a large number of participants thus facilitating quicker consensus building and releases, typically non-verbal with increased opportunities for misunderstanding (see Table 3-4)

  16. MECHANISMS OF COMMUNICATION(SYNC) - 2 • Hallways – • Ideal for single issue, simple problem resolution via informal meeting(s) in hallways by two or more (usually few) developers • Offers opportunities for exchanging operational knowledge or answering FAQs about tools, techniques, system malfunctions • The disadvantage is the loss of exchanged discussion and resolution (because it is informal and lack of history), but, when recorded and disseminated via, e.g., emails, hallway mechanisms could be effective in resolution ‘subtle’ issues. • Questionnaires and Structured Interviews – • Formal, structured survey instrument for eliciting information from user/client, experts, etc. from a given domain. It could be used at all levels of communication modes. • It is cost effective, unbiased, and allows subsequent structured reviews by developers for clarification or resolving ambiguities

  17. MECHANISMS OF COMMUNICATION (SYNC) - 3 • Meetings – Face-to-face, costly, difficult to organize and implement but facilitates consensus building, issue resolution. Meeting could also be done via video-conferencing or teleconferencing • Roles: • Primary facilitator (organizer and executor) writes agenda –detailing issues and scope/context, and calls for preparation by participants • Minute taker records proceedings of the meeting, organizes/edits the minutes and disseminates to all (including absentees) • Time keeper controls time and works towards keeping the discussion on course within the scheduled time frame • Meeting Agenda: • With a ‘header’ which describes the title, location, date, time and participants, issues/items of discussion and allocated time. Agenda should be specific and systematic. • Meeting Minutes: • Sections include: 1) Items/issues and actions taken on them, 2) header – as in Agenda, 3) Information-sharing on what info was shared, and 4) decision-section on what decisions was made or decided against • (See Fig 3-19, Fig 3-10, Fig 3-11) • Focus areas: client review, project review, inspection, status review, postmortem review, brainstorm, issue resolution

  18. MECHANISMS OF COMMUNICTION (SYNC) - 4 • Reviews – • involves evaluation by an external party, with formal presentation by developer and preceded by a release and followed by request/rationale for change; costly due to travel, requires flexible scheduling • The scope is at the client review level

  19. MECHANISMS FOR COMMUNICATION (ASYNC) - 5 • Same-Place, Different Place Groupware • Tools/mechanisms for distributed, asynchronous collaboration. Example tools: Teamware and Netmeeting (facilitated by the advances in Internet technology) • Difficult to coordinate participant (same) times, susceptible to network failures • Could be cost-effective when travel is minimized or eliminated, and can be greatly enhanced if audio-video capabilities are used • E-Mails • Transmission and sharing of multimedia data for various modalities of communication, supporting a broad range of artifacts and documents across different platforms • Ideal for event-driven type due to short latency, and effective for asynchronously resolving simple, single issues • Drawback includes the potential for information loss, multiple receptions or wrong recipients

  20. MECHANISMS FOR COMMUNICATION (ASYNC) - 6 • Newsgroups • Multicast (select group) emailing mechanism, which requires recipients to subscribe to the group to read shared information or discussion. There are support software tools and network servers, like the Email counterpart, for newsgroupware. • It allows subsetting or grouping recipients based on tasks/subsystems. • The scope includes requests for clarification, requests for change, releases, and brainstorming • (See Fig 3-12)

  21. MECHANISMS FOR COMMUNICATION (ASYNC) - 7 • WWW • Provides a hypertext metaphor, with a browser the participants can point-to (via URL), open, display and discuss multimedia artifacts • In terms of scope, it is Ideal for organizing and providing release info, code sharing or reviews, testing, providing list of references/links (without physical dissemination of such documents), and tool documentation • With integration of groupware tools in requisite browsers (e.g., the Netscape), the WWW could be an effective mechanism for team or subsystem-based discussions and same-time, different-place meetings • (See Fig 3-13) • Lotus Notes • A commercial tool, which is database-driven for user collaboration, sharing, and editing. It supports automatic tracking of change for request via filling-forms, revision logs, release notes. Access control in terms of users or groups at various levels granularity • Requires a purchase of both the client and server tools to use Lotus Notes (unlike the WWW) • Issues: Project Communication tools – • Completeness, complexity, reliability, maintenance, usability/ease of transition

  22. Figure 3-13. An example of a project home page for the OWL project.

  23. 3.5 PROJECT COMMUNICATION ACTIVITIES • Identifying Communication Needs – A case in point of a Greenfield Engineering Problem • Problem Definition – project manager meets with user/client, face-to-face meeting • Client accessibility is limited, and team walkthroughs/inspection are deferred until maturation of developer expertise • Project manager assigns subsystems to teams, with cross-functional teams (for documentation of interface and integration issues) and cross-team liaisons; and decoupling of subsystem to reduce dependencies. These requirements call for asynchronous mechanisms within teams and liaisons, and synchronous communication for project reviews and releases. • Modalities (across teams): • Client review (quarterly) • Project review (monthly) • Releases (quarterly) • Requests for clarification, requests for change, project issue resolution (as needed) • Modalities (within teams, using mostly groupware, asynchronous tools) • Status review (weekly) • Brainstorming (weekly) • Team issue resolution, request for clarification, request for change (as needed) • (See Fig 3-14)

  24. control userInterface :SubsystemTeam :SubsystemTeam database :SubsystemTeam architecture: documentation: CrossFunctionalTeam CrossFunctionalTeam communicates with communicates with communicates with communicates with Figure 3-14. An example of a project organization, used as the basis for the communication infrastructure (UML object diagram). Associations represent communication channels via liaisons.

  25. PROJECT COMMUNICATION ACTIVITIES - 2 • Setting up an Infrastructure – Two forums for project management • Project Forums: • Announcement (agenda reviews, releases) • Discussion (project-level requests for clarification, requests for change, discussions on issues, responses) • Issues (open issues and states) • Documents (versions of various documents – plans, RAD, SDD, SPMP) • Equipment List (descriptions of available equipment and status – availability, borrower, date, time, etc.) • Team Forums (similar to project forums) – strictly multicast-type (groupware discussion) • Team discussions • Team Issues • Team documents

  26. PROJECT COMMUNICATION ACTIVITIES - 3 • Organizing Client and Project Reviews – Project management schedules all reviews during planning phase of the project (see Table 3-5). Management assigns roles and responsibilities • Client Review (after release of RAD and the system) • System Design review (internal to developers, after release of SDD) • Object Design review (internal, after release of ODD) • Internal Review (unit and integration testing – to involve subgroups and liaisons) • Client acceptance test run (internal) on all project deliverables • Client acceptance test (deployment test – in client’s environment) on all project deliverables • Organizing Weekly Team Meetings • For status reviews, brainstorming, issue resolution • Management leads, encourages, rotates roles, suggest alternative approaches to discussions • For Greenfield Engineering system, management structures reviews as • See Fig 3-15

More Related