Tongue Fu!

What is sharper than a knife? What can hurt more than a punch in the gut? What can sting and hurt longer than a hive a bee stings?

Words. The old phase is right … words cut at you; words hurt. Words can cause emotional pain which can last longer and hurt stronger than physical pain.

We don’t normally intend to hurt others. Yet, there are some nuances that can hurt which we might not realize. Subtle word choices can cause resentment vs building rapport. Can build relationships vs create conflict. Can make people comfortable vs making people defensive.

In his book What Got You Here Won’t get You There, executive coach Marshall Goldsmith devotes two chapters to this topic. One of his best practices focuses on limiting destructive comments – eliminating those needless sarcasms and cutting remarks that we think make us sound sharp and witty. Another is more specific and subtle – don’t start with “no”, “but”, or “however.” These small words can put people on the defensive. Goldsmith believes that the overuse of these qualifiers secretly say to everyone, “I’m right. You’re wrong.”

In his book, Tongue Fu!, Sam Horn shares his thoughts on martial arts for the mind and mouth; words to lose and words to use. Like Goldsmith, Horn suggests subtle word choices that promote positive, constructive conversations. Horn’s goal is to “create light, not heat.” Here are some examples.

• AND instead of BUT – Allows you to connect instead of cancel
• NEXT TIME instead of SHOULD – Coach instead of criticize
• PLEASE instead of YOU HAVE TO – Request instead of order
• CAN instead of CAN’T – Devise instead of deprive
• DO instead of DON’T – Specific what you do want instead of what you don’t want
• SPECIFICS instead of EXTREMES – Specify and request what you do want

While it is a little word here or there, it does make a difference. Learning to respond positively takes practice. Our habits of reacting with the BUT and SHOULD words have been ingrained. Start practicing today. Over time, new habits will emerge.

TAKE-AWAYS: Sometimes it’s not the big changes that make the most impact. It can be the smaller ones. Subtle word choices can create light in an otherwise dark conversation.

Career Planning

Recently, I got an invitation to meet someone via LinkedIn, a networking website. It was an HR person (recruiter) from a local insurance company. To date, I used LinkedIn to keep up with friends and totally forgot about the job opportunities and other career pieces of it. While I was not interested in the position, it did remind me that my resume was out of date. Not just in content but style too.

Reading online and some recent Business Week articles showed me a good direction. My old resume talked about what I specifically did at those jobs. Not good. A prospective employer doesn’t want to know what you did at other jobs and what you did at 4:30p each day. A prospective employer wants to understand how you can add value to their company. I revised the content of my resume, taking this into account. I also tried to remove industry specific contexts to highlight transferable skills and results. I focused on successes/accomplishments and the complexity involved. I gave these as examples of what I could accomplish at their company. I also showcased areas where I am the leader or champion for my organization.

Prospective employers want to understand transferable skills. How are you at negotiating, collaboration, and other competencies. I took notes of these so I can promote them in the resume or cover letter for the specific position. Don’t under-estimate the cover letter. You can use the cover letter to elaborate and highlight pieces on the resume – use the cover letter strategically. This can help provide that traditional 1 page resume while still emphasizing what you want.

Now I have a generic resume ready. I’m not looking for a new position. I like my current position and employer. However if an opportunity arise inside or outside the organization, I want to be ready.

TAKE-AWAYS: You never know when a career opportunity might arise. Be prepared. Keep your resume up-to-date, reviewing it at least twice a year. Focus your resume on how you can add value for a prospective employer. And don’t under-estimate the power of the cover letter.

Credibility

As I move up the organization, my word and name alone do not have the power that it did at lower levels of the organization. That’s understandable. My credibility will increase as I prove myself at higher levels of the org. Until then, I need alliances and associated credibility/power.

I’m a person who does not complain alone – I complain and try to do something about it. I took a Gallup strengths test several years back where the results showed that 2 of my inherit talents (without trying) are development of people and processes. While I don’t have HR responsibility for my current project team and other coworkers (who could a future team), I still want to help them grow. Earlier this year, I presenting a mentor program idea to my VP and he said that I could pursue it further. Recently, he approved proposing it to the CIO.

As I was building the mentoring strategy, I reviewed it with our HR department who gave me good ideas and helped me link it to the HR mgmt directives to which people are accountable. When I reviewed the strategy with my VP, I told him that I worked with the HR dept and explained the feedback. The strategy and my personal credibility got the strategy approved to propose to the CIO. My VP gave me some good advice … take my HR Director with me as I present to the CIO. I will gain associated power and credibility. If there are questions from an HR standpoint my HR person can answer them, showing support from multiple sides.

Over time, I’m learning better when I should speak and when I should just shut up (and let others speak). While a PM has some good credibility, others hold credibility too (and we want to let them shine and be heard). Do we feel the code is ready for implementation … the user or QA Tester could have more credibility to answer. Sometimes a title has more power so you might need a VP to address a topic in a meeting.

You might notice that I started interchanging credibility with power. Credibility is a type of power. Power can be abused though. It’s taking me time to understand and navigate these waters. I hope you can learn from my travels.

TAKE-AWAYS: Know when to leverage other’s credibility. The PM alone is not the most powerful player on the team. The most powerful player is the team as a whole (team members, stakeholders, and sponsors) and you should leverage your team and individual credibility when needed.

2 cents

As I moved to larger and larger projects, I noticed that I needed to be in the details less. It was hard. I’m a details guy at heart. However, I worked long hours, couldn’t balance meetings with doing work too, was personally always on critical path, and generally stressed.

This is the point where I started leading by guiding principles. I cannot be available 24x7 to the team – meetings, different time zones, vacation, and more. At the beginning of the project, I establish project guiding principles to help guide the team when they have questions.

I also noticed that to support guiding principles, I also needed to enable confidence in the team so they could be self-sufficient. The team needed to be confident in their own knowledge and less dependent on me. I started answering questions less and asking the team to answer each other’s questions or directing them to the guiding principles. It can be hard. Again, I’m a details guy at heart.

A Businessweek article showcased a book that helped, What Got You Hear Won’t Get You There. It highlighted that past practices that make you successful might be less useful as you continue up the organization. One that spoke to me was “Don’t add too much value.” By being the answer man, people were less self-sufficient. I don’t need to give my thoughts on everything. In addition, as you get higher in the organization, simple brainstormed ideas can be interpreted as edicts that the team should follow. Need to be careful of the power you have.

When I catch myself giving too many answers, I literally pull out two pennies. You see it coming … I can only give my 2 cents worth. For questions directed to me, it reminds me to try to get the team to answer first before I give my thoughts. Sometimes I can be very passionate about a topic where I need to constrain myself from dominating the discussion – I literally can only give my 2 cents worth. I think … if I can only give 2 responses in this meeting, am I willing to give up one of my cents. It helps me evaluate the value that the comment will have.

TAKE-AWAYS: Watch adding too much value. If you keep answering all the questions and have to be involved everything, the team will be dependent on you; you will be on critical path. To build a self-sufficient team, you need to manage how much value you add – don’t add too much value.

Managing your stress

I learned a few years back that if I don’t manage my stress, I am less effective manager and leader. The first step was to understand what causes me stress. My topic 3 stresses were: overwhelmed by email, surprises, and feeling like I didn’t accomplish anything today. Once I identified these, then I could attack them.

Overwhelmed by email. I applied a “focus” approach. I use Outlook as my email client. I setup email rules to send email to specific folders. I have folders for each project, general work announcements, industry news, and a I-can-get-to-this-when-I-can folder. To help with this, I put a prefix on my emails to help the routing. When things appear in my inbox, I move it the appropriate folder. Then I can be focused when I read my email. I can go to project-A’s folder and be focused on that project. Then I can go to project-B and so forth.

With Outlook 2003, it has multiple colored flags. I flag emails for follow-up. I have my own system which denotes priority and allows me to priority/focus my time on the more important follow-ups first. I put a blue flag on emails that should be documented and shared more broadly. To help with that, I publish bi/weekly project team notes. I encapsulate the project team meeting and other decisions (and emails) for the time period. It provides an easy recap of events and decisions. From a historic perspective, the notes are handy to show previous decisions that could now take change control to overrule.

Surprises. It’s easier to address an issue if you’ve thought about it before. I do heavy risk brainstorming. I’ve mentioned in some previous blogs that I have a recurring Outlook task that appears every 3 weeks – “brainstorm risks.” I go to a quiet, few distractions place. I bring the project plan, last status report, project binder, and more. Then I brainstorm what can wrong from now to the end of the project. More importantly, I brainstorm varying mitigations to reduce the impact or eliminate the risk. Now when team members come to me with an issue, I might have already brainstormed it or something close to it. I can be calm (and help calm the team) on how to deal with the issue.

Feeling of non-accomplishment. It’s anal, but I print my Outlook calendar every day and set daily goals and prioritize them. I use a highlighter because colors can help give relevance to me. (Yes I can be anal, otherwise known as a strong J in MBTI). Orange is a must do today. Red is urgent. Yellow is important. Green is done. At the end of the day, I can see how many of each category I was able to do. It gives me a sense of accomplishment. One more piece … I identify 2 main categories – goals and opportunities. Goals are things that I want to accomplish today. Opportunities are items that I would like to do if I have time. Today’s opportunities could turn into tomorrow’s goals.

TAKE-AWAYS: Know what causes you stress and manage it.

Time to Lead

In my past (today too), I can be a hands-on project manager. If needed, I can throw my hands and head to help. For development, it’s as a pair programmer. For QA Testing (an earlier career), I can write the test plan, test cases, and execute.

As I started leading larger projects, I noticed that I got stressed more. I read once that stress is caused by 2 primary things – (1) feeling that you did not do your best and (2) trying to control things that I cannot control. If it’s QA, it’s their responsibility to deliver (not my direct responsibility). It was too late to control the risks that were realized or the circumstances dictated to us.

One of the best decisions I made was to focus on things that I can control. I also started to move toward being more of a leader than a manager. Several books note that there are different characteristics and goals between the 2 roles.

For me, this journey (I’m not done yet) takes 2 forms – guiding principles and risk mgmt. I cannot be available 24x7 to the team – meetings, different time zones, vacation, and more. At the beginning of the project, I establish project guiding principles to help guide the team when they have questions. Some are generic such as “How does this support the Operations? Maybe there are multiple solutions available. Think about which solution best supports the operations (which may not be the easiest solution).” While others are more specific to the project.

For risk management, I’ve gone a little overboard but it works for me. In Outlook, I have a recurring task that appears every 3 weeks – “brainstorm risks.” I go to a quiet, few distractions place. I bring the project plan, last status report, project binder, and more. I brainstorm what can go wrong in our current situations and continue through implementation. I also think of mitigations for each so I can try to reduce the impact or eliminate the risk. Then I prioritize the risks and best mitigations. I tend to have 2-4 pages of risks and mitigations. Some are simpler such as what if the environment is not ready next week (mitigation – check progress and apply additional milestones if necessary). Others are more profound or larger impact and are added to the risk register – more visibility.

Last year, I led a 13-month project where my entire development and QA Test teams were located in India (9½ ahead time difference). At first, we didn’t have guiding principles. Some decisions were delayed until I could reply to an email or had a meeting the next day. Sometimes that was a day delay. Add those up and your schedule can be shot. Then we applied the guiding principles. The offshore team felt more empowered and had some direction. (One of the guiding principles was also to be more self-sufficient.) While there were some corrective actions, it mostly went well. From a risk standpoint, I was unable to manage-by-walking-around; I couldn’t just walk over to the developer’s desk to see how things were going. There was a lot of risk planning here – milestone setting, concrete/physical deliverables that could be reviewed or demos, and more. My stress was reduced so I was able to lead and manage better.

TAKE-AWAYS: Know what causes you stress and manage it. For me, it was planning for risk (so there were less surprises) and limiting how often I got into the nitty-gritty details.

Google Account

Why does a new Google account require so much access? I can create new accounts on all these other websites but NOT Google. Their website says that they want more cookie and other access. Why Why Why. I cannot get it to work on my work or home PC. I also tried Firefox on both too.

I started blogging (2 entries) a 1½ years back and got so busy I didn’t get back to it. Google has upgraded their blogspot application and now require me to convert my account to a new Google account. When I try to do this, I’m caught in an endless loop where the id won’t create.
I could host a website myself, but don’t want to get into that. I don’t know many more free blog sites, so I guess I’m stuck. Since I’m writing this post, I overcame the problem. I created my Google account from my local library’s computer.

TAKE-AWAYS: Thanks for letting me vent – it’s therapeutic.

SO NOW YOU’RE A PROJECT MANAGER

SO NOW YOU’RE A PROJECT MANAGER

Abstract
Changing project roles from developer to project manager may be more involved than you think. It’s time to broaden your view from emphasis on the tasks to viewing the whole project. The 3-word project manager job description is “to manage risk.” A good project manager makes the process look simple. Risks are varied and sometimes hard to identify. They include such items as managing requirements, schedule, and cost. This article shares a few items to ponder as you start your travels down the project management road.

I know what a project manager does
Yesterday Tom was a developer, now he’s been asked to take the lead on the project – be the project manager. It sounded like a good opportunity, but Tom wondered what’s expected of me now? Tom’s transition can be similar to building a house. Tom installed drywall yesterday, focusing mostly on cutting and installing the drywall. Occasionally he would help in other areas like painting or wallpapering. Now Tom is the general contractor who is responsible for building the entire house.

Tom has been coding for years, so he thinks he knows what a project manager does. Yet, things might not always be as they appear. As a developer, Tom might not see how the activity fits into the big picture; Tom’s observations can be seen differently from a project manager’s (PM) point of view.

So what is Tom in for? What specifically is involved in doing this PM job? The most concise job description is “to manage risk.” Risk is a 4-letter work with a lot of power behind it. Webster’s dictionary defines risk as “(1) possibility of loss or injury: peril; (2) someone or something that creates or suggests a hazard.” Risk comes in many forms. Tom is used to managing coding risk – error handling and exception processing; you don’t want those “out of memory” and “run time” errors popping up in testing or production. As a PM, the view is broader and so are the skills employed – communication, negotiation, organizational, leadership, and more. As a developer, just leave Tom alone and he’ll code it. As a PM, Tom will coordinate more activities, relying on others to complete them on time, on budget, and with quality intact.

Managing this risk thing
A PM manages 3 main risks – requirements, schedule, and cost. You must meet the users’ needs – stated and unstated elements of the requirements. If you don’t meet the need, it’s not worth doing. The product could work perfectly and be some “sweet code,” but if it doesn’t meet what the customer wants then it’s shelf-ware. As you deliver the product, you need to meet the implementation target with an acceptable level of quality and within the budget. The users don’t want those “out of memory” and “run time” errors popping up either. Think about Tom building a house. He might insist on certain things when the contractor is building his house. It must meet his living needs and quality expectations – floors must be level, no foundation leaks, walls must be properly painted, etc (requirements). Tom wants the contractor to work against his target date so he can move from his current residence to this new one (schedule). And the house must fit within his pocketbook (cost).

Managing requirement risk
Let’s start with requirement risk. When you drive, you usually have a clear destination in mind. Requirement risks are the detours and road construction that may slow down the journey. There are a few tools in the PM’s tool belt that can help.

• Make sure you understand the requirements. Do a process walk-though during requirements gathering (use cases, business scenarios). This could uncover unexpected requirements or different interpretations. Your definition of gray could be different than the customer’s (shades of gray).
• Document the requirements in a formal document or tool.
• Review requirements with sponsors and receive “signoff.” Any future requirements (new, new interpretations) should follow a project change control process to explain the cost and schedule impact. New interpretations can be a little trickier when it comes to budgeting and schedule considerations – Who pays any additional cost and is schedule impact allowable? While change requests may add a little more work and analysis, they will improve the final product being delivered. Project Management consultant Bill Duncan (2003) calls change requests a cause for celebration. The author explains that change requests mean that the customer is engaged and noticed something missing.

You hope that the requirements will easily describe what the user desires and needs. However, sometimes the requirements open themselves to a different interpretations of the end product, leading to missed quality expectations. When this happens, grab your PM tool belt.

• Users must be included on the project team and in team meetings. They can identify mistakes earlier in the process, instead of post-implementation. In her article “Ten Ways to Guarantee Project Failure” (2003), Naomi Karten explains that minimizing customer/user involvement is one way to guarantee project failure. She emphasizes that users help clarity project direction, scope, and expectations.
• Hold demo-and-discussion sessions to evolve concepts into reality. Talking about something is great, but seeing it brings a new reality and tests the model more visually.

Managing schedule risk
Schedule risk focuses on meeting the implementation date. The main tool involves using milestones to check progress. You can uncover a few more tools in the PM’s tool belt to help.

• Break larger tasks into smaller milestones (max 1-2 weeks) to understand progress/checkpoints/lag times. In his article “A Calculated Gamble” (2003), Payson Hall stresses the importance for risk management. He agrees that decomposing complex tasks into smaller tasks helps detect progress slippage better.
• Understand the critical path – the tasks that will delay the schedule if they miss their target end dates.
• Use newer technology, tools, and techniques earlier. Since they are new, there could be a few detours along the road. In the articles “Risky Beginnings” (2000) and “A Calculated Gamble” (2003), the authors agree that new technology can be a risk. The authors suggest including exploration time in the schedule and shifting tasks that use new techniques or tools to occur earlier in the project for earlier detection of problems and refinement of processes.
• Plan some catch-up time in the schedule, also called lag points. Normally, some tasks will take longer than others so this lag time can absorb unexpected downtimes and act as a shock absorber. When building a house, the contractor needs some shock absorbers for things like weather delays.
  

Managing cost risk
Anticipating and controlling requirements and schedule risks well can help manage the cost risk. Cost is the byproduct of all activity. There is even a cost associated with adding resources to meet unanticipated or off-schedule problems. It’s a good thing that the PM tool belt is not empty.

• With the sponsors, agree on a variance threshold that allows some overruns without having to run to the sponsors for approval each time
• Understand cost run (how much cost is forecasted each week vs actuals)
• Share cost overrun projections with the sponsors early in the project to help set expectations about the final cost

Delivering results
There’s a saying, “it’s not what you said, but how you said it.” This article has suggested some methods to manage risks, but the delivery is also important. Skills such as active listening, use of power, and conflict management are needed in order to deliver results. These are skills that are useful for developers, project managers, and others alike.

The author of the article “What it takes to be a good project manager” (1987) shares a study noting that communication skills were the most important project management skill. In one study, 84% of project managers surveyed believed that communication skills such as listening and persuading were at the forefront of project manager needed skills. The core of active listening focuses on listening and ensuring understanding. Once we have “really listened,” then we can look towards responding. Active listening can be helpful in mitigating requirement risk. Users typically explain the result they desire. Active listening allows us to ensure that we understand the requirement, reducing the shades of gray.

You want your response to achieve a desired result. As a project manager, your power to achieve that result can be somewhat limited. While Tom has a team of analysts, developers, and testers for his project, none of them report directly to him; there is a matrix reporting relationship. This reduces the power at his disposal. However, Tom still has influence over this team, sponsors, and others. Influence can be viewed as producing a desired effect without force or exercise of command (or power). In his article “Power, Dependence, and Effective Management” (1977), John Kotter explains several methods of influence including obligation, perceived power, perceived dependence, persuasion, and others. The proper method of influence should be tailored to the specific persons involved and situation. There are advantages and disadvantages with each method. For instance, persuasion can influence a very wide range of attitudes and behaviors requiring no power. Yet, it can be very time-consuming and requires the other person(s) to listen.

Within a project, there will be opportunities to exercise active listening and influence, especially during conflicts. Over time, one learns that conflict is healthy. It suggests that people are engaged and asking the “why” questions. In the white paper, “Communication Breakdown and Conflict within Teams” (2004), another author explains that conflict is essential for healthy teams to challenge old ways and sponsor creativity. The project manager needs to understand how to encourage the good conflict and minimize the bad. The article “Lessons for an Accidental Profession” (1995) explains that conflict should not be covered up because it festers if not addressed. The later eruption will have stronger effect than if confronted originally. There are several effective conflict management methods. In the article “Methods of Resolving Interpersonal Conflict” (1969), Burke shared a study showing that confrontation-problem solving was the most effective. Confrontation-problem solving focuses on using active listening to work through the differences towards a win-win solution. It defines the problem relative to the total needs while confronting differences and being open and fair. The book Getting To Yes (1991) reinforces this idea while acknowledging that sometimes a win-win is not possible. The BANTA approach (Best Alternative To a Negotiated Agreement) provides a structure to understand the perspectives and alternatives. The process exhausts the alternatives to the “best” alternative for each party. If a BANTA is not agreeable, then the process has healthily discovered that a win-win agreement is not possible.

Give it to me straight
Project Management is more than another development task that will take a few hours for a limited period of time. A PM’s time is spent each week for the duration of the project. It requires an extended skill set than that of the developer. You may be like Tom who still enjoys coding. While managing a project, you should not be a critical path developer too. If you will hold PM and developer roles in a project, you will need to balance your development and PM duties. A nice rule of thumb is 30% for development and the other 70% for project management. Last, take time weekly to write down what could go wrong – risk brainstorming and mitigation planning. It’s easier to miss potholes if you can see them coming.

I hope you have a better understanding of the road ahead. Good Luck.

If you are interested in more information on these topics, these references might be useful.

Burke, R.J. “Methods of Resolving Interpersonal Conflict.” Personnel Administration. Jul-Aug 1969.

“Communication Breakdown and Conflict within Teams.” Global Knowledge. July 2004. http://itresearch.forbes.com/detail/RES/1088099513_537.html.

Derby, Ester. “Risky Beginnings.” STQE Magazine (now called Better Software). http://www.stickyminds.com/BetterSoftware/magazine.asp. November/December 2000. Ms. Derby has a website supporting her project management consulting company and her many articles at http://www.estherderby.com/articles.htm.

Duncan, Bill. “Ignorance Is Risk.” Projects@Work. July/August 2003. At the time, Mr. Duncan was director of standards for the American Society for the Advancement of Project Management and a principal of consulting firm Project Management Partners (www.pmpartners.com).

Ensworth, Patricia. The Accidental Project Manager: Surviving the Transition from Techie to Manager. Wiley. 2001. This book can be found on many websites, including Amazon at
http://www.amazon.com/exec/obidos/ASIN/047141011X/qid=1112473736/sr=2-1/ref=pd_bbs_b_2_1/102-9708073-3841706.

Fisher, Fry, Patton. Getting To Yes. Penguin. 1991.

Hall, Payson. “A Calculated Gamble.” www.stickyminds.com. January/February 2003.

Karten, Naomi. “Ten Ways to Guarantee Project Failure.” www.stickyminds.com. April 2003. More of Ms. Karten articles can be found at http://nkarten.com/indepth.html.

Kotter, John P. “Power, Dependence, and Effective Management.” Harvard Business School Press. July 1977.

Pozner, BZ. “What it takes to be a good project manager.” Project Management Journal. March 1987.

Name game

The Bitter Project Manager ...

I wasn't born that way, but it progressed over time. Well, I was born Bitter - it's my last name.

I like to say that I "evolved" into a project manager. Over the years, I was a developer, tester, test lead, development lead, and more which lead me to be a project manager. I consider it an evolution, learning along the journey. And I'm still learning today. I hope you enjoy my thoughts and insights about my journeys.