page 1 of 7 Whitepaper: Communication Paths and Roles (in distributed software development)

Transcription

1 page 1 of 7 Whitepaper: Communication Paths and Roles (in distributed software development)

2 page 2 of 7 Introduction Picture these situations: Three developers talking at lunch about a difficult bug that one of them had spent most of the night fixing. Nothing wrong with that. Just some colleagues talking informally about their work. The Product Manager meets with the User Experience (UX) Lead to decide about priorities for the next release. Again, perfectly appropriate. Part of the job of the Product Manager is to establish release priorities. Meeting with each engineering group is one of the ways this gets done. A Sales Account Manager asks a developer to make a change in the next release that a customer has asked for. Oops. We just crossed a line here. We would expect a client-side Account Manager to represent his customers interests, but going straight to a line-level engineer is not the way to do it. The client calls a developer at the vendor firm to ask how a particular feature in the application works. The line just got crossed again. The client should have a primary contact at the vendor firm, probably a Product Advocate or Project Manager, who can field this type of question so that it gets answered in the most productive way possible. These examples point clearly to the need for defining communication paths within project teams. But how can you define them in a way that encourages helpful informal communication and that also ensures the formal communication the project needs to move forward? Defining communication why bother? At one extreme you could view a project team as a network with potential connections from each member of the team to every other member of the team. But if everyone always talked to everyone else, the team would take a long time to achieve its goals. At the other end of the spectrum you could have tightly-controlled communication that defines exactly who can speak to whom. This approach allows for no flexibility in the system and is overly restrictive. The answer of course lies somewhere in the middle. What is that middle? Before answering the question, let s look at the difference between formal and informal communication. At Waverley we think of formal communication as any communication that causes a person to change work priorities, goals, or that affects productivity. Everything else is informal. So formal communication includes events like team meetings, client , and design reviews. It also includes non-essential and lengthy calls to engineers by the client. The solution is to define communication paths not to the degree that they eliminate informal communication but so that formal communication can proceed in a productive way. The communication paths in distributed teams are controllable, even across remote locations, if everyone on the team understands and plays by the basic rules. Early definition of communication paths will help avoid problems. As the project evolves, communication paths can evolve with it. So how does a team go about defining communication paths? It starts by defining roles.

3 page 3 of 7 Standard roles Every distributed team will have certain project roles and these roles tend to be the same from project to project. In small projects, several roles may be handled by a single person. Lacking an industry-standard lexicon we propose the following list: 1) Sponsor or Client The individual paying for the project (IT executive, manager, entrepreneur). The Sponsor is the final decision-maker but tends to be hands-off, relying on the Program Manager to flag issues. 2) Product Advocate May be filled by one person or several people. Responsible for ensuring that requirements and functional specifications are generated and that the Sponsor is happy with progress and results. 3) Program Manager The main coordinator for the project. Status reports, risk analyses, planning, action items and regular meetings are all handled by him/her. Also the keeper of task priorities and schedule. 4) Project Manager Each site must have one. Coordinates schedules, reporting and status for the groups at his/her site and manages the site s deliverables. On smaller projects, the Program Manager fills this role. 5) UX, Development, QA, and Technical Writing Managers Manage the personnel in his/her skill set (whether design, development, writing, etc) and are involved in issue resolution on the project as needed. May also function as skill set Leads. 6) System Architect Responsible for the software architecture and design, and for how the software fits into a larger infrastructure. Also involved in technology stack choices, approaches to system interfaces, data flow and database design. 7) UX, Development, QA, and Technical Writing Leads Manage the workload and direction of their skill set on a daily basis. May also function as the skill set Managers. On smaller projects the Development Lead is also the System Architect. 8) UX Designer, Developer, Quality Engineer, Technical Writer Line-level roles that actually design and create the product. UX Designers write specifications, draw wireframes and define visual elements. Developers write code and resolve bugs, Quality Engineers test code and flag bugs, and Technical Writers create written documentation for the product. Supporting roles In addition to the roles listed above, some projects will benefit from (or even require) input from Business Analysts, Subject Matter Experts (SME), and Technical Experts as well as representatives of areas (business, organizational or application-specific) that will use or have an interest in the end product. Individuals playing these supporting roles are typically called in when their expertise or approval is required for the project to progress.

4 page 4 of 7 Role-to-role communication: paths and responsibilities Now that we have our cast of players let s describe the play. Recalling the old adage All roads lead to Rome we propose All paths go through the Program Manager. By this we mean that any formal communication should include the Program Manager, whose responsibility is then to synthesize and distribute all important information to all project team Leads, as well as to the Sponsor and supporting roles, as appropriate. Specifically, in formal communication, here s who should (and shouldn t) be talking to whom: 1) Sponsor or Client Communicates primarily with the Program Manager and Product Advocate. May sit in on team meetings and status calls, and may request status updates outside of regular calls. The Sponsor should not communicate with anyone else on the team without the involvement of the Program Manager or Product Advocate. Most such direct communication between line-level or even Lead contributors and Sponsors results in unintended consequences and lost time. 2) Product Advocate Communicates with the Sponsor, Program Manager, Project Manager and supporting roles like Business Analysts or SMEs. Information requests or change orders for the larger team from the Product Advocate should be routed through the Program Manager (or at a minimum cc the PM). 3) Program Manager The primary contact for the entire team, delivering regular status updates, risk assessments, etc. The Program Manager consolidates and directs communication within the team and should be included in all inter-group communications, both within a single site and across sites. The Program Manager tracks action items, escalates issues for resolution, and ensures that communications involve all needed parties. 4) Project Manager The primary contact for a specific site (which on smaller projects may be the only site, in which case the Program and Project Manager are the same person). Tracks status and issues within his/her site and forwards these to the Program Manager. Alerts the Program Manager to cross-site issues and alerts the skill set Managers to any personnel issues within his/her site. 5) UX, Development, QA, and Technical Writing Managers Make staffing decisions regarding who from his/her skill set is on the project team, taking into account workload, skills, and budget. Managers may change project personnel according to project needs, notifying the appropriate Project Manager who in turn informs the Program Manager. Skill set Managers also help to resolve any personnel issues within their site s project team. 6) System Architect Communicates with the Sponsor, the Program Manager, the UX and Development Leads and the Product Advocate. Guides the development team in resolving technical issues as they arise. All communication to and from the System Architect should cc the Program Manager. 7) UX, Development, QA, and Technical Writing Leads Manage communication within their own team, reporting personnel issues to the skill set Manager and team Project Manager. The Leads communicate work status and schedules to their site s Project Manager. Communication by Leads across sites or with other Leads should include each site s Project Manager and the Program Manager. UX Leads often communicate directly with the Product

5 page 5 of 7 Advocate and supporting roles (Business Analyst, SME) but here again should include the Program Manager in their communications. 8) UX Designer, Developer, Quality Engineer, Technical Writer These line-level roles communicate primarily within their own team. Communications with other teams and/or skill sets typically involves the Leads (for questions of larger importance), although informal communication like casual questions or confirmation can flow directly between teams without the involvement of a Lead. 9) Subject Matter Experts (SME), Business Analyst and other supporting roles Communicate primarily with each other and with the Product Advocate and skill set Leads, especially the UX Lead, copying the Program Manager. It s then the Program Manager s responsibility to involve the Sponsor or System Architect when and where appropriate. Meetings Meetings provide a crucial means and mode, besides role-to-role, for receiving and disseminating information in a project team. Project status meetings, for example, often bring many members of a project team together. These meetings, whether face-to-face or using VoIP services such as Skype or Sococo, provide opportunities to review requirements, UX designs, code, bugs, and so on. The dynamics of face-to-face encounters are also crucial for maintaining good working relationships, especially for geographically dispersed teams.

6 page 6 of 7 Example 1: small project team Small projects usually consist of a few developers with one or two UX designers and QA staff as optional. Typically, the Project Manager (who doubles as the Program Manager) and Lead Developer handle all communication to other interested parties. In small projects especially the participation of the Sponsor is crucial to success. Core Team: Sponsor Project Manager Lead Developer Developer(s) Lead QA Optional adds: UX Designer(s) Additional QEs (Quality Engineers) Example 2: mid-size project team Mid-size projects often engage a couple of UX designers (one of whom also functions as a Product Advocate) as well as a System Architect, a larger group of developers and at least one Quality Engineer. There is often the involvement of a supporting role such as Business Analyst, SME or other expert. Mid-size projects are usually broader in scope and cost and interface heavily with multiple functions in the Sponsor s organization. Core Team: Sponsor Project Manager System Architect Lead UX Designer/Product Advocate UX Designer(s) Lead Developer and Developer(s) Lead QA and QE(s) Optional adds: Business Analyst SME/Technical Expert IT staff from Sponsor s organization

7 page 7 of 7 Example 3: large project team Large projects see a distinct separation of Architect, Lead and line-level roles in each skill set and engage development teams of 20 or more and QA teams of five or more, often working across multiple geographic locations with multiple Project Managers reporting to one Program Manager. As with mid-sized projects there is often the continued involvement of supporting roles such as Business Analysts, SMEs and other experts. In large projects the Sponsor as an individual is rarely involved in detailed decisions, making the roles of Product Advocate and Program Manager particularly crucial to the project s success. Core Team: Sponsor Program Manager Product Advocate Project Manager(s) System Architect Business Analyst Lead UXs and UX Designers Lead Developers and Developers Lead QAs and QEs IT staff from Sponsor s organization Optional adds: SME/Technical Expert(s) Application-specific Expert(s) Technical Writer(s) Conclusions In distributed teams the definition of formal communication paths is critical. A clear understanding of roles and how information flows amongst them helps ensure that all team members have the data they need to get their work done and are adequately informed about project status, direction, issues and problems. In these communication paths there are key figures or directors, primarily the Program and Project Managers, who ensure that the correct team members are involved in or apprised of any important news or initiative. Other than limiting Sponsor (and other client-side executive) access to individual team members the communications paths suggested above are not intended to limit information exchange. These paths are proposed to direct information flows in such a way as to ensure that every team member is fully informed and that all team members are working as efficiently as possible towards the same goal: project and product success.