View source for Stakeholder Agreement

{{EDBOK DSDL Infobox|EDBOKContributor=Kevin Lantaff, edp}}

=== {{FontColor|#25408F|What is Stakeholder Agreement?}} ===
Stakeholder agreement and management of that relationship<ref>Although project managers have many of the same goals as project owners with regard to overall project success, the duties of a project owner are more managerial in nature. This document focuses more on stakeholder agreement and management from this perspective. For information concerning project manager roles and responsibilities with regard to stakeholder management, see the '''Project Management Institute: A Guide to the Project Management Body of Knowledge'''. </ref> describes the methods and processes used to identify individuals or groups who may influence the project or who will be impacted by it. It includes the description of each role (contribution and importance) within the context of the project, identifies the requirements for managing the engagement, and specifies communication with and between stakeholders. The end goal is to achieve overall project goals and objectives that lead to project success. 

==== '''{{FontColor|#25408F|Key Success Factors}}''' ====
The value of stakeholder agreement cannot be overstated. All projects are made up of the sum of its stakeholder parts. If individuals or groups are not properly integrated  into the flow of the project at every key step and properly managed to encourage the success of each project phase, the result will be sub-par, if not disastrous. The success of the project hinges on how well the various stakeholders are managed so that the project progresses smoothly, on time, within budget, and most importantly, meets or exceed customer expectations. 

==== '''{{FontColor|#25408F|Voice of the Customer (VOC)}}''' ====
The success of a project depends on how well the customer has been identified. That includes how well all overt and covert needs are understood and documented, and how well the end product will meet or exceed the customer’s need. This is true regardless of whether the organization is in agreement, in word or in practice, with this philosophy. To misstep here and not adequately reflect customer needs with regard to the requirements for the project will result in an unsatisfied customer and damaged customer relationship, as well as time and cost overruns due to scope creep. 

The discovery of customer needs and customer advocacy with regard to that need can be the role of several groups within an organization. For transaction document projects managed internally by a corporation internal consultant, business planners or analysts usually take the lead. For communication service providers the responsibility usually lies with customer engagement or implementation managers. In technically-driven organizations the IT or programming department may be responsible. Some organizations employ a Customer Experience Officer for the purpose of adding extra emphasis and focus to customer requirements gathering. 

==== '''{{FontColor|#25408F|Assistance}}''' ====
Project owners are not always aware of who the stakeholders are, what influence they may have, how important they may be to the success of the project, and how to navigate the political mine field that may exist. For this reason, it is wise to seek assistance from those who understand the business structure and how decisions are made, where power centers lie, and the political landscape. 

==== '''{{FontColor|#25408F|Engagement and Communication}}''' ====
While everyone plays a role, some stakeholders are more critical than others to the success of the project. Putting formal management and communication processes in place that integrate each stakeholder’s involvement at the appropriate level is essential. The communication plan should ensure that every stakeholder has an opportunity for their voice to be heard in the appropriate venue, that they get the information they need in a timely manner, and using the method they prefer (the right message to the right person at the right time with the right content). 

For instance, executives usually want summary information delivered in a setting and format that makes it easy for them to quickly grasp and absorb the essentials. Project managers and technical leads prefer detail and backup material. Some prefer to have information pushed to them, while others prefer to pull it. Various tools should be employed to ensure all stakeholders are informed. One size does not fit all! 

==== '''{{FontColor|#25408F|Feedback and Responsiveness}}''' ====
Stakeholders should be given an opportunity to provide feedback at any time. Pro- active efforts should be taken to seek out feedback throughout the project so that issues can be addressed quickly. When issues are discovered with any part of the project, quick action needs to contain the problem and resolve it in the best way possible to ensure project success. 

==== '''{{FontColor|#25408F|Signoff and Agreement}}''' ====
Although most stakeholders are affected in some way by changes at every project phase, the ones who are impacted the most must have primary signoff authority. For instance, the customer should be responsible for signing off on the final requirements documentation and on the functions delivered at each phase. Service and support teams should have a great deal of influence when it comes to determining the level of product quality and reliability. They should also identify the tools provided in support of service levels. If product test is not measured against product quality as it pertains to customer expectations, then quality may suffer. 

=== {{FontColor|#25408F|Understanding Stakeholders}} ===

==== '''{{FontColor|#25408F|Navigating the Minefield}}''' ====
A successful project has as much to do with cultural and relational savvy as it does with a comprehensive set of customer requirements and great communication. Understanding how to work effectively within the corporate culture (hierarchy, chain  of command, centralized / decentralized power) and how to understand and manage the current political climate, will contribute greatly to the success of the project. Identifying a mentor or coach to assist in this area is crucial. 

Learning where the power lies is also a consideration. In general, those with a budget have the power. In financially driven companies the CFO has the power to make or break any project. So understanding how your project will be measured financially is important. 

In technology-driven companies, engineers, programmers, and other technologists might have a great deal of influence to the point where what is expedient or familiar to build could take precedence over the voice of the customer. Clear, crisp, thorough, and comprehensive customer requirements are needed to overcome this potential bias. 

For companies that have experienced a great deal of litigation, the legal department wields a lot of power. The management team may routinely practice risk avoidance rather than assertively going aftermarket opportunities. 

In some companies where mergers and downsizing have occurred or are occurring, HR may hold more power than expected. The point being made is to know where the power lies and prepare for it. 

=== {{FontColor|#25408F|It’s Not About You!}} ===
Project success not only hinges on your ability to navigate the corporate minefield or understand the balance of power, but also how well you understand the needs, pain points, and agendas of the stakeholders on your team. 

The IT department could be stretched very thin. Their lack of resources may have caused a greater number of defects in the past. Because they are measured on defects they may be unwilling to support your project. They will need a lot of help in the area of value and justification in order to secure more resources. Trying to do more with less in this situation will result in failure. 

Upper-level management may have close relationships with current vendors and might be resistant to change. Therefore, clear and quantifiable benefits and advantages need to be fully developed and understood. 

Manufacturing and Customer Service may have a hard enough time retaining and training high-quality personnel with their current workload, that the thought of taking on another project is overwhelming. A well-thought-out and conservative strategy, timeline, and project plan helps to overcome obstacles. 

And depending on how well (or not well) similar projects have rolled out in the past, executives and management in general want to see that your project will rise above and not only learn from past mistakes, but exceed expectations, and meet or come in under budget. Conforming to best practices and understanding lessons learned from the past will help grease the skids. 

==== '''{{FontColor|#25408F|Stakeholder Interest}}''' ====
One last area of consideration when understanding your stakeholders is their  level of interest. Are they supportive, neutral, resistant, detached, or motivated to lead. Understanding this, in conjunction with power, will help in how you manage, communicate, and resolve conflict amongst team members. A stakeholder could have all the power but be neutral in support. Worse, they could be resistant. Or they could  be extremely supportive, but lack any power to effect real change or influence others on your behalf. 

In general, you want to closely manage those stakeholders who have high levels of power and influence, and just monitor those with low levels of power and influence. Those in between should be kept informed and satisfied. 

===== '''''{{FontColor|#25408F|Transaction Document Stakeholders}}''''' =====
The transaction document production workflow has many stakeholders. Determining who they are depends primarily on the purpose of the project. Transaction documents include all correspondence created and produced due to the execution of a business transaction. These include statements, invoices, account opening packages, explanation of benefits, insurance policies (EOC’s), informational and collection letters, trade confirmations. 

Some business lines are involved in almost every. In addition, each document will be owned by a business area, so they must be involved. Marketing will want a presence with any change to customer correspondence. Some companies have departments or individuals who focus primarily on regulatory compliance or security, and they will need to be represented for regulated and sensitive documents. 

'''''Business Owner (planner, analyst, internal consultant):''''' Every document  produced is in support of a business function, and every business function has an owner who is responsible for the success of that segment of the business. This person is usually the primary customer who will be ultimately responsible for requirements signoff. The business owner is also responsible for business justification of the project, which drives funding and resource allocation within all departments involved. Examples of business owners are consumer and business credit card market segment managers for the credit card services industry, or HMO and PPO business segment managers for Health Insurance companies. 

'''''Executive Owner:''''' An executive is typically assigned to the project to represent senior management. Their role is to support the project at key transition and signoff points between phases or when assistance is needed to resolve conflict. There may be more than one executive assigned from the business and finance areas. 

* '''''Program and Project Managers:''''' Companies will assign someone to manage the overall implementation, tasks, and interactions between all of the internal and external stakeholders. Larger companies will split program management and project management responsibilities between two people. Program managers (also known as implementation managers or consultants), acting as an internal consultants and operational subject matter experts, work hand in hand with the business owners (customers) and other key stakeholders to ensure overall project success. Project managers take primary responsibility for task and schedule management, and provide the heavy lifting to ensure all stakeholders are involved at the appropriate levels per the engagement and communication plan. 
* '''''Customer Service and Call Center (sometimes known as account management):''''' As day to day support for current customers, customer service has a wealth of knowledge concerning how to build and roll out solutions that are easily supported and maximize customer satisfaction. For this reason it is very wise to have customer service involved as early as the business analysis phase. Automated ticketing and job management functions, job status and automated error management, online access to customer documents, and detailed reporting capabilities are just a few of the tools that will enhance customer service. 
* '''''Manufacturing:''''' Whether manufacturing is performed in-house or is outsourced, a representative must be present, especially during business and technical analysis phases, to ensure document production requirements can be handled by current manufacturing capabilities. If manufacturing cannot support the requirements, then program management and manufacturing must quickly determine a solution for the problem, including cost projections, so that a decision can be made to support the new function or modify the requirements. 

'''''Information Technology (IT):''''' As with manufacturing, IT is involved from the beginning to ensure requirements can be supported, and to recommend new technology if requirements cannot be met. Whether outsourcing or producing documents in house, both internal and vendor IT staff must be represented at all stages starting with business analysis. 

'''''Marketing:''''' If the new project involves marketing messages (TransPromo) then marketing plays the role of co-owner along with the business owner and is involved during the entire project. But since marketing owns the customer relationship along with sales, and transaction documents touch customers, marketing should always be involved in the lifecycle process of any project that changes the look, feel and content of transaction communications. Customer Experience Officers are usually part of the marketing department. 

'''''Chief Compliance and Chief Security Officers:''''' Adherence to security standards is normally controlled by IT and compliance is managed by the program manager or business owner. Some companies establish a special group or person that focuses specifically on these areas due to high risk exposure. Early involvement starting at the business analyze phase is required. 

'''''Finance, Accounting, and Procurement:''''' Finance plays a budgetary and cost analysis support role during the initial phases and when scope changes occur due to new requirements or adjustments to cost projections. Procurement is used to help with determining costs going forward for hardware, software and services. 

'''''Legal:''''' Projects may involve external vendor contracts and disclosure agreements, as well as intellectual property concerns, which must be settled before vendors can support the project. Document messaging may also require approval from the legal department. 

==== '''{{FontColor|#25408F|Identifying Stakeholders}}''' ====
Every stakeholder will be involved to some degree, but depending on the type of transaction document project, certain stakeholders play a more active or critical role. In this next section key stakeholders are identified by project type. 

===== '''''{{FontColor|#25408F|Stakeholders by Lifecycle Phase}}''''' =====
A project is made up of a series of phases as part of a larger product life-cycle. Each phase constitutes a separate work effort that requires work, rework, approvals and sign off. At any phase along the lifecycle project can also be killed. 

Certain stakeholders are more active at various phases or steps along the transaction document life-cycle. The following section covers the customers for each phase, what is accomplished in each phase, and who is involved from a stakeholder perspective.

'''Requirements Gathering:''' This is where the customer is identified and requirements are gathered and prioritized. In this phase the why is understood (problem or pain),  and the what should be determined (specific requirement or need). The how is addressed in later phases. The voice of the customer is of paramount importance and  is combined with market research, focus groups, interviews, surveys, JAD sessions, and compliance documentation to identify requirements germane to the project. Prioritized requirements with a description of high-level benefits are documented for future justification purposes. A document mock-up may be created at this point showing the new product or enhancement being considered. 

The line of business owner is usually the primary customer, especially for new projects. Program Managers may lead the effort in this phase working closely with the customer to artfully managing all inputs with respect to felt and hidden needs. Care must be taken not to try and solve the problems in this phase. Doing so will limit the brainstorming activity and overall creative process which is so important when determining customer need. 

'''Business and Technical Analysis:''' These are two separate phases that overlap significantly with regard to stakeholder involvement. Project scope and success factors, roles and responsibilities of stakeholders, and a complete cost benefits analysis occur at this phase. Due to business or technical limitations discovered in this phase, it is possible that customer requirements may require revision. 

Program management works with the business owner to create the categories and framework for the analysis. Finance and procurement, IT, and manufacturing support the team by providing current cost and resource information in order to come to a total cost of ownership for the current state. IT, manufacturing, and customer service assist with determining the technology required (gap) and costs associated with reaching the desired state. Other items such as revenue and profit impact, potential disruptions and risk (economic, security, compliance, etc.), and resource impact are managed by the business owner, program manager, finance representative, and executive management. A complete business case is the result. 

Marketing, Sales, and Customer Service, remain advocates for customer experience. Marketing also makes certain brand compliance is maintained and customer messaging is appropriate and correct. Legal creates vendor contracts protecting Intellectual Property and may sign off on proposed messaging. Compliance and Security inject critical requirements. Finance gets involved to ensure costs are fully known and understood. 

'''Stakeholder Adoption:''' This is the first gate where approval from all stakeholders is sought because the solution building begins. Changes made after this phase can be far more costly than usual unless Agile and Lean management methods are employed. All stakeholders receive a formal presentation along with the final requirements document and cost benefit analysis. A process for change management and final approval is defined and implemented. All legal issues regarding intellectual property, contract terms with vendors and confidentiality are put to rest. Any changes to scope beyond this point require approval from all stakeholders unless other arrangements are made. 

'''Architecture:''' IT assigns an architecture team and leads the effort, with manufacturing, of identifying and documenting all key processes, workflow steps, and components required from data through delivery, including exception processes and audit points. Project management leads the effort to create the project plan with tasks and timelines for all stakeholders to review and approve. If scope has not changed then key gatekeepers are the business owner, program management (implementation, consulting), IT, and manufacturing, ensuring the solution still meets customer need.  If the scope changes then finance, executive management, and the other stakeholders weigh in for approval. 

'''Design:''' The architectural document and plans are used as a base to create a formal functional / design specification for final review by all stakeholders. This document is usually written by the program manager assisted by IT and the business owner. Other documents such as a document design guide and data dictionary are produced at this phase. All stakeholders, excluding finance, legal, and marketing (if not a marketing project), are the gatekeepers for this phase. 

'''Development:''' During development there are periodic meetings to review project status and timelines which include internal and external resources and task owners. Several testing phases are implemented to test against customer requirements and provide ongoing feedback. Agile development processes and lean management methods create an iterative or incremental approach to development, testing, and requirements verification. The business owner, program manager, IT, and manufacturing teams are the key gatekeepers. Scope creep may bring other stakeholders back into the approval process. In Agile and Lean environments, gatekeeping responsibility may be given to a smaller group dedicated to ensuring the solution meets the needs of the customer, and bypassing the more formal process outlined in this section. 

'''Test and Quality Assurance:''' This process often runs in parallel to Development. The testing group is usually part of the current IT and manufacturing teams. In larger organizations this function is performed by a separate group which may serve to produce a higher quality product. All workflow and process inputs and outputs are tested against customer requirements using test cases and production regression tests. Stakeholders are the same as in the Development phase. 

'''Production:''' Before the solution is released for production, all materials must be purchased against specified stocking levels, resources hired and trained, and a launch date selected. Final approval from all stakeholders is required to exit this phase. 

'''Maintenance:''' In Lean or continuous improvement environments the maintenance phase is active and fluid. Customer requirements are always being gathered and refined, and the solution benchmarked against these requirements. Mini document lifecycles occur as enhancements are brought forward for consideration and implementation. A small team provides oversight and direction usually involving the business owner, program manager, IT and manufacturing, and others as required. 

==== '''{{FontColor|#25408F|Stakeholders by Project Type}}''' ====
'''Technology Refresh or Upgrade:''' Organizations consider a technology upgrade or refresh to increase productivity, quality, and the ability to better manage the customer relationship. The customer could be any group whose budget is negatively impacted by the current state, or those responsible for generating revenue (quality). 

Enhancements to technology require a comprehensive review of current functions supported in order to ensure the new technology or solution will at least meet current needs. If differences or shortcomings exist the stakeholders will need to approve these changes to function and operations. Even version upgrades to existing technology can cause major problems, so care must be taken to test and roll out these new technologies or versions out in a phased approach. The most common examples would be upgrades to, or replacement of, printers, inserters, finishing technology, or major software components (composition, archive, etc.). 

Program managers (consultants) play a key role as subject matter experts ensuring existing requirements are met. IT and manufacturing help to make sure existing functions will be supported, the new technology can be supported, and new processes are updated and documented accordingly. Customer Service may be involved if the technology upgrade is significant in scope (as with a move from cut sheet to continuous printing), and may cause customer service disruptions. 

'''Mergers and Acquisitions:''' This type of project is similar to a technology refresh in that new technology will be merged with old, but on a much larger scale. The customer is at a much higher level and expectations are usually that there will be no business interruptions or outages. For this reason a phased approach to integrating and obsoleting technologies is typically employed. 

Business owners will likely be involved as changes to functionality and support may be required (at least in the short-term) and new capabilities offer new opportunities to improve quality, efficiency, productivity and costs (cut sheet to continuous). Program management, IT, and Manufacturing are heavily involved. 

'''Statement Redesign:''' There are many reasons for  statement  redesign  projects, but most efforts are undertaken to simplify layout and messaging for the purpose of reducing customer calls, improving brand image, or adding marketing messages for cross selling purposes. The marketing department, business owners, and customer service are customers. 

An agency may be brought in to perform the redesign. They are usually managed  by marketing and the business owner. Customer service plays a very important role to make sure the redesign does not cause an increased number of support calls. IT  is involved to perform the actual document redesign within the composition system and make certain document construction and pagination is correct. Manufacturing is involved only if the redesigned statement changes print and fulfillment requirements, such as page and document size or envelope changes. 

'''Regulatory Reporting and Compliance Improvement:''' The customer in this case is the business owner and upper level management. These groups can delegate some responsibility to a risk and compliance group. Complying with industry regulations not only requires meeting specific requirements, but providing proof that you met the requirement. A detailed audit trail is required for this. For instance, if an Insurance business is required to have the transaction correspondence postmarked (mailed) within seven business days of receipt of data, then not only must the workflow be automated and streamlined to accomplish this, but the business must be able to track each mail piece as it travels through the transaction workflow. They need to be able  to act quickly if errors occur, and provide supporting data and reports in the proper format to prove compliance. 

Business owners, program managers, and compliance officers form the core team. IT and manufacturing provide technology support to craft the solution along the entire workflow. 

=== {{FontColor|#25408F|Stakeholder Management Process}} ===

==== '''{{FontColor|#25408F|Stakeholder Responsibility}}''' ====
Every stakeholder has a role to play during the entire project life-cycle. 

===== '''''{{FontColor|#25408F|Team Players}}''''' =====
As with any team, the project team is tasked with working together towards a set of common goals. These goals are set by the team and agreed upon early on so that there is no mistake as to what constitutes a successful project. 

Every stakeholder is required to meet mutually agreed upon requirements such as meeting attendance, responding to requests, following guidelines and rules set by the team, and communicating clearly, among other things. If at any time a stakeholder is not participating as expected and agreed, actions must be taken to rectify the situation. 

===== '''''{{FontColor|#25408F|Decision Makers and Influencers}}''''' =====
Some stakeholders influence decisions and others are tasked with making them for their area of responsibility. Influencers, who are usually subject matter experts, play a critical role in providing valuable input to the decision making process. Decision makers are usually those who have budget authority and whose budgets will be impacted by the project. At any phase all stakeholders can weigh in on issues and pose objections, but decision makers have final say. And, before moving to a new phase of the project life-cycle, key decision makers must sign off. 

===== '''''{{FontColor|#25408F|Final Signoff, Evaluation and Continuous Improvement}}''''' =====
Finally, stakeholders are tasked with final approval of the project and decommissioning of existing technologies that have been replaced. They also should participate in post project evaluation activities that seek to improve the quality of future projects by documenting lessons learned and best practices. Participation on an ongoing basis may also be required if continuous improvement is a goal set by the business. Improvements are identified which may kick off a new project life-cycle. 

==== '''{{FontColor|#25408F|Stakeholder Engagement}}''' ====
A process must be put in place so that stakeholder engagement is managed throughout the document development lifecycle. The purpose is to ensure needs, expectations, and issues are managed in a timely manner. The need to manage stakeholders is greater during the initial phases. Using appropriate commination and negotiation techniques helps to ensure that the effort has a high probability of success. 

Stakeholder engagement is managed primarily through status meetings supported  by other communication methods. Progress on the development process is discussed using the project schedule, change management document, action item log, and other documents mentioned in the next section. 

The key is to present the facts and let the stakeholders decide on the best course if corrective actions are needed. Focusing on facts helps to remove the emotional component of any bad news. The goal is not to find fault, but determine what the issues are, and finding the best approach to correct the issues.

===== '''''{{FontColor|#25408F|Stakeholder Communication and Documentation}}''''' =====
Part of good management is making sure everyone in the boat is rowing in the same direction, so ensuring they have what they need to foster buy in at every step is crucial. 

===== '''''{{FontColor|#25408F|Stakeholder Information}}''''' =====
Every stakeholder plays a different role and has different needs within the team. They also have varying levels of importance or contribution along the transaction document production lifecycle. A document called a Stakeholder Register documents all information and communication preferences concerning stakeholders on your team. This is a living document that changes frequently. Due to the sensitive nature of the information, it should be managed by the project owner and shared with program and project managers only. 

Information includes: 

* '''Identification information:''' name, title, department, location, contact information, preferred communication methods. 
* '''Involvement level information:''' major role and expectations, power, influence, importance, lifecycle phase involvement, Agile or Lean Management team participation. 
* '''Classification information:''' internal or vendor, and level of support you are likely to receive. 

===== '''''{{FontColor|#25408F|Document of Understanding (DOU)}}''''' =====
All stakeholders should approve and agree to support critical success factors for the project as documented in the DOU. This document may be one that is used across multiple projects. Examples of critical success areas in the DOU are: 

* '''Project charter:''' A high level description of the purpose for the project including the problem requiring resolution, high level goals and objectives, and the desired state. This description will be in harmony with the customer requirements section. 
* '''Customer requirements:''' The voice of the customer, reflected in customer requirements, is the foundation upon which the success of the project should be measured. If requirements are not right then nothing is right, and the solution would be very costly to repair afterwards. Most companies spend a third to half the time they should in this area, and a commitment from the team to acknowledge the importance of this step is critical. 
* '''Justification:''' Extracting and quantifying all the value possible is the fuel that drives allocation of budget and staff. Reasonable and solid evidence for project value will secure the resources needed, and all members of the team should contribute and agree. Past project examples of either high or low valuation may help find the right number. 
* '''Project plan:''' Everyone needs to help formulate and agree upon the project lifecycle phases, schedule, and overall scope, including the commitment required from each stakeholder. 

* '''Resource acquisition and allocation:''' All stakeholders should be on board with regard to how the budget is spent and if changes need to be made to project scope if there is a budget shortfall. 
* '''Ongoing support:''' All stakeholders commit to working as a team with regard to cooperation and conflict resolution, appropriate levels of engagement, bi- directional communication, and a commitment to see the project through to success. 

==== '''{{FontColor|#25408F|Continuous Buy In and Commitment}}''' ====
At all stages of the project lifecycle the owner must continually test the level of engagement and consensus of key stakeholders. Involvement and commitment is measured against roles and responsibilities documented in the Stakeholder Register and Document of Understanding. If stakeholder or organizational behavior requires adjustment, then action plans should be put in place immediately so that the project stays on track. A mentor or coach is helpful here. 

Part of continuous buy in is problem escalation or conflict resolution. A clear process needs to be documented so that all stakeholders know how the team will resolve issues. Response to issues should occur as they become known, and resolution sought in a timely manner. 

==== '''{{FontColor|#25408F|Communication Processes}}''' ====
Communication is the life blood of any project, and is used to make sure all stakeholders are adequately informed so that they can participate to a level that promotes success. Communication is used to develop a relationship connection between stakeholders so that a homogeneous team is formed. 

Stakeholders have communication preferences and needs with regard to method, frequency, and content received. Some require detail and others just a summary. Some prefer to pull the information and others prefer it pushed to them. Some wish to have access to all the information pertaining to the project, and others a particular subset. Determining how each stakeholder wishes to communicate and receive information should be logged in the Stakeholder Register, and tools put in place to accomplish this. 

* '''Communication toolbox:''' Communication is difficult under normal circumstance, but is truly a challenge during stressful times. The right balance of online versus face to face communication is different for every organization. 
** '''Project sandbox or forums:''' Interactive forums are used to share and log key conversations and track the communication string of activities and issue. This tool is usually used by technical staff and those who closely interact with them. 
** '''Email:''' This is still the preferred method of communication by many. The drawback is that the communication string or history does not reside in  a central place for all to see, and history or context is easily lost across collaborators. 
** '''Text:''' This method is used to quickly respond to requests for information which can greatly speed up the project. Text tools do not provide an adequate audit or history trail for the entire team to see. 
** '''Meetings:''' If it is true that 90% of communication is inflection, tone, and body language, then there is a 90% chance that your message will not be heard correctly if you are not in front of the audience. Sometimes organizations iterate electronically for hours or days on a subject or issue when a quick 5 to 10 minute conversation could solve the problem immediately. Face to face meetings are the most effective way to deliver your message to ensure understanding. Video conferencing and phone meetings are the next best thing and are usually more effective than electronic communication. 
** '''Online project management collaboration tools:''' These tools will allow for collaboration between stakeholders and project personnel by facilitating communication (locally and remotely), assigning tasks, allowing for file sharing, and coordinating schedules and calendars. Team members can  share information using electronic comments, forums, text and twitter like function, document repositories, and standard email. Although intended to save time and improve project management effectiveness, some tools can be time consuming and counter intuitive. Lean Management advocates call this phenomenon computer disease, where the use of technology actually hinders communication. Care must be taken to select the right tool that meets the needs of the entire team. 
* '''Documentation and reports:''' A central repository of documents or document sharing solution can be used to share files among team members. Document types are listed below. 
** '''Project schedule:''' If online tools are used then the schedule is accessed within the tool. Sometimes schedules are exported and posted online as a spread sheet. All tasks, owners, timelines and special comments are placed here, and the schedule is used as a guide to direct and manage team activity. 
** '''Change management log:''' When scope changes for the project then it should be recorded in this log and subsequently recorded in the customer requirements document. If the change management log is not incorporated into an online tool then the log is usually managed in a spread sheet. Change description, date opened, date closed, owner, stakeholders involved, approval criteria, and status are items tracked. 
** '''Action item or issue log:''' This log could be managed separately or as part of the change management log under a different category, and is populated with issues or action items discovered during the project management process. 
** '''Presentations and meeting notes:''' These are stored so that stakeholders and team members can review them at any time and to ensure there is an audit trail tracking action items created during meetings. 
** '''Key letters and records:''' Critical correspondence between stakeholders and team members may be stored in a document. 
** '''Other:''' Requirements documents, functional specifications, documents of understanding, data dictionaries, document design guides, legal contracts (internal use only), and document objects and templates. 

=== {{FontColor|#25408F|Legal Concerns}} ===
The role of the legal department is to limit or eliminate liability associated with the project. They are involved with any external communication and contract associated with the project. Most legal contracts have to do with outside resources or products used. 

* '''Confidentiality:''' When dealing with outside vendors, including current business partners, a non-disclosure agreement should be in place to protect confidential information and intellectual property. One agreement can be signed by both parties to protect information going both directions. 
* '''Software licensing:''' All software used for the project should be purchased and licensed properly. If a site or corporate-wide license is in place then you must check to see if licenses are available, and if not, ensure they are purchased for the project. 

==== '''{{FontColor|#25408F|Vendor Contracts}}''' ====
* '''Ownership:''' If an outside vendor is involved in the development of the solution then ownership of the resulting product must be addressed. Each party could ask for exclusive ownership, or they could mutually own it. Exclusive ownership usually demands a much higher price tag. 
* '''Acceptance Criteria:''' The customer requirements document is usually used as the basis for solution testing and acceptance criteria or a separate document is created for this purpose. Key performance indicators and metrics are also defined and measured before acceptance. These requirements need to be stated in the vendor contract, and is used to determine when the vendor’s work is complete. 
* '''Defects and Service Level Agreement:''' Defect levels per a certain number of lines of code, or mean time to fail repair criteria could be listed as requirements. If the vendor will remain involved in a service capacity then service expectations and requirements should be agreed to. This could include problem severity definition, support coverage times and contact methods, and response time commitment.

== {{FontColor|#25408F|References}} ==
__NOTOC__