© 2003 Kathleen A. Demery, PMPhttp://www.pmboulevard.com/expert_column/archives/reg/Getting_Team_Buy-in_of_Processes_Demery.pdf

Tip 1: Obtain senior management support

Tip 2: Communicate expectations Project managers should demonstrate commitment and enthusiasm for the processes. Make sure that expectations are crystal clear. Provide the rationale. Explain how following the specific process will help them do their work, provide consistency, save time, save money, improve quality, contribute to the project objectives, etc.

Ensure each team member clearly understands: • their role in the process; • their responsibility; • their authority; • the interdependencies and how their piece fits in; • management expectations; and • the way their performance will be evaluated.

Tip 3: Involve the project team in implementing the processes Ask a small group to participate in a test of a new or updated process before moving it out to the entire team. Knowing that other team members previously tested the process will increase confidence in its use. Additionally, those in the pilot group will feel ownership of the process and become process advocates. Provide a mechanism by which the team members can make suggestions for improvement, either during the project or at the time of project closeout.

Tip 4: Provide training Before a process can be practiced, it needs to be trained. It can be a formal training class or an informal process orientation. It is best to conduct the sessions at the beginning of the project, but it is also effective at any time during the project. Follow-up coaching and mentoring can be used throughout the project to ensure the correct usage of forms and templates, for example. During these sessions, you can also identify where team members might be having problems and make sure those items get on the list as areas for improvement.

Tip 5: Ensure process compliance To be effective, processes need to be enforced, measured, and reviewed for effectiveness. Process audits should be included in the project's quality assurance plan. The audits can be done by your quality assurance organization or by your own project team. In either case, an audit can be done based on criteria from an audit checklist. The project team should be involved in the development of this checklist. There should be no surprises. The quality assurance group can audit for process compliance based on the checklist or your project team can review each other's process compliance based on the checklist. Peer reviews can encourage healthy competition that can challenge and motivate the project team to utilize the process. Processes should be measured so you know whether they are effective. Process compliance (conformity to the standard) should be tracked and reported to management. However, process compliance does not guarantee project success. Processes need to be tailored for the project, and reviewed for value and the capability they bring the project.

Tip 6: Reward for performance Give credit privately and publicly for positive contributions to process improvement as well as process compliance. Rewards can range from monetary (e.g., bonuses) to positive feedback or team recognition. For those still not on-board, you may have to escalate the non-compliance issue to the next highest authority.

Summary Teams will utilize project processes if senior management and the project manager are on board and visibly show their commitment; ensure that the processes are well documented, tested, communicated, and monitored for areas of improvement; and provide that the project team is sufficiently trained, clearly understands their role and responsibilities, and are audited and rewarded for process compliance. Motivating and encouraging your project team to follow project processes can have a significant positive impact on the success of your project.

 

Grassroots Acceptance   pages.cpsc.ucalgary.ca/~saul/681/1997/raly/GrassRoot.html

Grassroots acceptance, a.k.a., the bottom-up approach or team member buy in, entails getting the people working on the actual products themselves (product team members, such as programmers, designers, developers, engineers, tech. staff, etc.) to support and believe in human factors.  The rationale is that this is where the "real" work is done, and as such, it is at this level that you can most effectively implement human factors methodology. Similarly, if the grassroots personnel do not support human factors, nothing will get implemented.  The more acceptance you get from the design team, the more likely you'll be involved earlier in the design process which in turn affects the opportunities you have to affect the design process, the likelihood your ideas will be implemented/listened to, in short, how effectively you'll affect the design of the product/system.

As with most things, acceptance is not an overnight event.  It does, however, seem to follow a life cycle of its own.

Skepticism: Typically, team members are skeptical at first.  Human factors is new and its importance is doubted.

Curiosity:  As team members become more educated and start seeing results, they become curious as to how they can utilize and benefit from human factors.

Acceptance:  At this point, Human factors has proven itself and has come to be a full and equal member of the design process.

Ways to encourage grassroots acceptance:

The methods to garnering grassroots support can be categorized into two approaches.  The first involves techniques which enable team members to see and experience first hand the benefits of usability testing.  The second category discusses the interpersonal interactions between human factors people and team members - ways to interact which promote a good working relationship.

Involve team members in the testing process.

An equally important aspect of winning over grassroots personnel is the development of a mutual level of professional respect between yourself and other team members.  Because of the intrusive/new/unknown nature of human factors/usability, this relationship requires special attention.  Don't only identify problems, also provide design alternatives, make it clear that your not "judging" the work, but your working with them to improve the product, be open to compromise and show that you understand the bigger picture (i.e., you realize there are constraints that others also have to deal with).

People don't appreciate being constantly told that they're wrong.  If you gain the reputation of a user interface or design "cop", people will actively avoid you. Acknowledge their expertise - it's interesting that this is what we always want, yet it's very easy to forget that it goes both ways. Don't be afraid to ask for help.  When someone helps you, that person feels more powerful, gains recognition, and a sense of task ownership. Acknowledge successes, positive aspects, in fact, do it first.  Give them food - little things like having M&M's, or candy can become a catalyst for conversation, familiarity, regular visits, etc.  Make "friends" - you're more likely to listen to and respect, people you like. But don't just roll over, if you're compromising, make sure they understand that so they return the favour  Get in the trenches, become familiar with other issues that are critical, understand the hurdles, problems faced by developer and the effect of your recommendation on them