Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it.  He called it the too-common cycle of apathy.

The post hit a nerve with me. At my previous engagement, the Engineering Department was used to being railroaded by management. Promises were always made on their behalf and they found themselves working long hours and weekends. If they didn’t make the goals, those who made the promises would never take ownership. If goals were miraculously accomplished, the same person(s) would jump into the spotlight. After I was brought on board, I didn’t have a problem looking a Director or CIO right in the eye and telling them I disagreed with them. Sometimes they backed down and sometimes they didn’t. But everyone at that company knew I was honest and would speak up if I didn’t agree with something. Everyone knew I was looking out for my people, my department, and my company. I believe positive change rolls up hill, just as sh*t rolls down.  Though I’m no longer with that team, I have no regrets for backing them up and providing support when they needed it most. Those who bullied so many are no longer there either.  Though there was an attempt to silence my voice by decapitating my team, others in the organization saw through the ruse.

I think sticking your neck out is worth the risk. If I think you’re right, I’ll support you.  By doing that, I build trust with my teams. With trust, my teams will do anything for me. With that, anything is possible. What can I say, everyone is happy but the party you had to confront in the first place. Yep, it’s certainly worth it.

Thank you Geoff for getting me fired up.  Now go check out his site!

image courtesy of Papercut Edge

Mitigated speech is a linguistic term describing deferential or indirect speech inherent in communication between individuals of perceived High Power Distance.

The term was recently popularized by Malcolm Gladwell in his book, Outliers, where he defines mitigated speech as “any attempt to downplay or sugarcoat the meaning of what is being said”. He described 6 degrees of mitigation with which we make suggestions to authority:

1. Command – “Implement this”

2. Team Obligation Statement – “We need to try this”

3. Team Suggestion – “Why don’t we try this?”

4. Query – “Do you think this would help us in this situation?”

5. Preference – “Perhaps we should take a look at this an an alternative”

6. Hint – “I wonder if we will run into any issues by following our current process”

As I observe the command and communication structure between a PMO and its members and contractors, I have the opportunity to witness mitigated speech every day.  Being direct (command) doesn’t always work.  People need to learn to be flexible in their requests and negotiations if they have the hope those in power will implement new strategies.  Additionally, learn to read those around you to know what degree of mitigation you will use IF you intend to use it.

As I read Outliers, I started to think of the relationship between mitigated speech and Appendix G.8 (negotiation) of the PMBoK.

Negotiation is a strategy of conferring with parties of shared or opposed interests with a view of compromise or reach an agreement.  Negotiation is an integral part of project management and when done well, increases the probability of project success.

The following skills and behaviors are useful in negotiating successfully:

• Analyze the situation.
• Differentiate between wants and needs – both yours and theirs.
• Focus on interests and issues rather that on positions.
• Ask high and offer low, but be realistic.
• When you make a concession, act as if you are yielding something of value, don’t just give in.
• Always make sure both parties feel as if they have won.  This is a win-win negotiation.  Never let the other party leave feeling as if he or she has been taken advantage of.
• Do a good job of listening and articulating.

To summarize, stride to be a win-win negotiator and be aware of the mitigated speech you are using to conduct your negotiations.

There are probably two primary reasons you would go with an offshore team.

(1) Your customers are also offshore, or (2) you’re hoping to save money on development costs.

I’m going to assume your reason is number (2).  Though this post is brief for such a complicated topic, it should give you some things to think about.  Yes, you can certainly save a lot on development expenses. Then again, it can come back to bite you in rework expenses if there are communication issues.

How do you bridge the language barrier?
(1) You need a go-to guy or gal who speaks the same language as your developers but will be working at your location. This is a must. Your probability for success is going to go way up by ensuring there is no breakdown in communications.

How do you receive the quality of code you need?
(1) Use continuous integration
(2) Use test scripts to understand requirements
(3) Use short iterations
(4) Have regular builds
(5) Separate teams by functionality (not activity)

How do you communicate?
(1) If you can afford to send/bring someone (an ambassador) over to work with the other team at the beginning of the project, do it.
(2) It is critical that your “go-to” has a daily meeting with the team. Select a method that allows each side to see one another. (webcam/Skype)
(3) Have everyone use Skype (VoIP) and/or a chat client for one-on-one communications.
(4) Keep a Skype connection open between the offices.
(5) Use wikis or other collaborative solutions for common project information.
(6) Stay away from email, unless it is for formal communication. Information is going to get lost along the way and it will take longer to clarify.

Remember to use parallel communication methods, not serial.

Today I’m going to write about (and provide) a free Project Team Organization worksheet to complement the Project Charter Template so many have downloaded. Both files are free for download, modification, and distribution. [Team Organization Worksheet] [Project Charter Template]

When using the Project Team Organization worksheet, note that there are 4 sections:  Structure, Roles and Responsibilities, and a Responsibility Matrix, Project Facilities and Resources.  I’m going to focus on the first three.

Step 1: Describe the organizational structure of the project team and stakeholders, preferably providing a graphical depiction (organization chart).

Step 2: Summarize roles and responsibilities for the project team and stakeholders identified in the project structure above.

Step 3: Complete the responsibility matrix for each of the project roles. As a graphical depiction of a more detailed perspective of responsibilities, the matrix should reflect by functional role the assigned responsibility for key milestones and activities.

Step 4: Describe the project’s requirements for facilities and resources, such as office space, special facilities, computer equipment, office equipment, and support tools. Identify responsibilities for provisioning the specific items needed to support the project development environment.  Hey, you’re people need places to sit and equipment to get their work done.

With preliminary approval, copy these values into Section 3 of our free Project Charter Template. Upon Project Charter approval, apply the identified team members to activities in Microsoft Project or your selected Project Management application.

Another thing I would recommend is leverage the data from this worksheet in your Communications Management Plan.  You’ve already identified people and their roles or responsibilities.  The most important thing to remember is do what makes sense.  This planning worksheet isn’t required to do a Charter.  It’s supposed to make things easier for you and lower the risk of not knowing who is on your team and what they are responsible for.

[Team Organization Worksheet] [Project Charter Template]