May 29, 2007 – How to Ruin a Perfectly Good Team

One rotten apple can spoil the whole bushel. Imagine the speed with which it can happen if that apple is the project manager? It doesn’t take long before the rot starts to spread and any chance of success dwindles. So how do you keep from ruining your perfectly good team? Here are 5 sure fire ways to accomplish it.

Demotivate Them. I remember a specific meeting in which I got shot down and how small it made me feel. It was already a rough time for the team I was leading and I was having a passionate (read “heated”) discussion with our new manager. He said something to the effect of “How can I make changes to this group if I have to argue everything with you?” I remember apologizing and not saying anything else. Clearly what I had to offer wasn’t what he wanted to consider.

If you have blown it with one of your resources you will need to set things right. Unfortunately it is much easier to demotivate than to re-motivate. A nice poster with an inspiring saying probably isn’t going to cut it. Try these suggestions:

• Meet with them individually to start recreating a foundation. If you said something stupid, apologize and leave the “but you…” out.
• Catch them doing something right and praise them for it. It doesn’t have to be public, just let them know you appreciate what they do.
• Reset the vision of the project and their role in it.

Say Stupid Technical Things. It has been a while, but I used to program in C. One of the great aspects of the language is the ability to separate the common shared variables from the code and use them in multiple programs. My manager challenged me on why I didn’t use a single file for easier version control and storage. That statement failed to inspire confidence in her abilities to manage me.

Recently I have had to oversee the connectivity set up for our offshore team. When I started I suspected a NAT wasn’t the same as a URL but couldn’t have proven it. When I find myself short on technical knowledge I start a lot of questions with “help me understand something….” It frees me from pretending to know it all and allows them to show their expertise. If they can’t explain it either I start to get nervous.

Drop Your Support. Hanging your team out to die isn’t likely to win you manager of the year. I recall one instance in particular where I had to fall on my sword for the team. Action wasn’t being taken to finish off a couple of key tasks and the client wasn’t very happy. A large part of me wanted to blame the team and their ability to take ownership. In reality I was responsible for not driving it harder and the email I sent stated it that way.

Ignore Them. Sometimes it is easy to neglect you team, especially if they appear to be working together well. Things are moving smoothly when suddenly you start hearing complaints. Soon a couple of team members resign for positions elsewhere and the rest of the team is left floundering, trying to absorb the extra work. Even productive teams need cultivating. Remember to:

• Recognize their effort both individually and as a team. It doesn’t have to be big, but it should be real. Generic praise will fail. You won’t be able to get away with saying, “great job doing whatever it is you do.”
• Keep them informed. Connect them to the bigger project picture including business goals, discussions and decisions. Let them know how their piece fits in and how the overall project is progressing.
• Keep things positive. Address issues, but don’t resort to yelling. And certainly don’t make the business out as the bad guys.

Assume. Always assume your team members know what you are thinking. If no one is bothering you, assume everything is fine. No need to check up on anything. Your team would tell you if you needed to worry, right? This is one area I have to watch out for. As project managers we worked our way up because we work independently. We either figure out what we need or we ask questions until we get it right. Trouble starts when I assume that my team is making progress and I choose not to confirm it.

Even a great running machine needs to be oiled to keep the friction down and things working properly. You’re the one with the oil can so get busy.

May 21, 2007 – How to Meet Expectations

Some things are predictable. Love stories always end with the couple getting together. Tragedies end with someone dying. If you are watching a horror movie you know the phone won’t work and the lights will go out. You also know that instead of staying together where it is safe the characters will venture off on their own and become victims. Predictability is so ingrained in us that when things don’t turn out like you think they should you get upset.

Case in point: I once watched over an hour of a documentary about rebuilding a World War 2 plane. Evidently on the way back from Europe after the war, the plane ran out of fuel in far northern Canada and landed. The people were rescued but the plan remained there for over 40 years. A team of mechanics and a film crew spent several years refitting the plane. Because of the harsh winters and short summers there was only a short window to work on it each year. Upon completion they added fuel to it and were able to get it started.

The plane taxied down the frozen ground and wonder of wonders lifted off the ground. It flew in a wide circle and life was as it should be…until smoke started pouring out the back. By the time they landed the plane was engulfed in flames and everyone stood around watching it burn to the ground. I was mad. They had suckered me in to investing over an hour of my life to see all that effort go to ruin.

Then I started to imagine how my business team would feel if they invested their money and time helping my team refit their systems only to have the results miss their expectations. I’m pretty sure they wouldn’t be happy. How can you avoid this problem? Here are 5 ways to keep your project from going up in flames because of unmet expectations.

1. Understand the Business. Before you start gathering requirements, understand the group for whom you are doing the work. What is the problem they are trying to solve and how does it fit in with the rest of their business? You don’t need to be the expert but you need to comprehend the need.

2. Confirm expectations. Requirements are a good place to start but may not be the whole picture. Use modeling or prototyping to work through more of the details when possible. Walk through the requirements documentation and models with them to be sure everyone understands and is in agreement. If you don’t have a formal approval process, adopt one. It doesn’t have to be elaborate; it just needs to show that at a specific point in time everyone agreed on the direction to head.

3. Verify along the way. Your goal is to produce a useful product, not blindly follow the specifications. I was reminded of this on one of my projects. The test results showed that we successfully processed and loaded the data we received. They also showed the data was messed up. We had to add a mini project to correct the data at the source. If we had ignored it the system would have met the specs but would have been useless. The great part about working in an agile environment with graphical components is the ability to put pieces of the end product in front of the users on a regular basis. Seeing and touching along the way will bring corrections and improvements for consideration.

4. Horses…rein them in. A change management process is your lifeline. While #3 above may sounds like an open invitation to chaos, the project is still constrained by time, scope and budget. Use the process to confirm the necessity of a change and to allocate sufficient time and money to complete it. Where the approval process points you in the right direction, change management keeps you on the right path.

5. Abuse case testing. Much of our testing tends to focus on meeting the specifications. If I enter an amount and press button A then screen X appears and shows W. But can I bypass the security and grant myself access to view screen Y? Can I guess by the URL other areas I shouldn’t be able to get to and hack in? Trying to say you delivered a product that works to spec while the company burns to the ground isn’t going to cut it. Designate a resource for several days to try and break the system. Take off the gloves and just start abusing it.

In the end it is about delivering something of quality. Ensure it is something that doesn’t leave your business disappointed.

May 14, 2007 – Less Obvious ROI

When I was working with a system support group we had to scramble each month to determine the Return on Investment (ROI) for the system enhancements. Changes ranged from new reports to added functionality with other odd things in between. Needless to say, determining the ROI for adding a product color field to a report lacks a certain excitement and requires a lot of creativity. Technically it is the responsibility of the business group to assign ROI, but it generally falls on the technical team to make it happen.

I was particularly bothered by a formula one business group used to calculate the ROI. It was based on the number of hours expended to do the change and was calculated as follows:
Less than 40 hrs 100 * $105 = $10,500.
40 – 60 hrs 200 * $105 = $21,000.
Greater than 60 hrs Actual Hrs * 2.5 * $105
It had nothing to do with the value of the product, only the time expended to do it. With that logic we should have taken longer to do everything so we could save more money. Since ROI is the business’s responsibility whether it makes sense or not that is the calculation we use when ROI isn't obvious.

So are there any decent ideas for determining more realistic ROI values? Some are obvious like replacing inefficient hardware and decreasing the need for resources. Other times you need to dig for value. Three examples are time savings, employee satisfaction and client satisfaction.

Time Savings. Does the change allow people to do more in less time? One change we made allowed the users to copy and paste data from one system to another with a couple of key strokes. This simple change increased their productivity and save approximately 30 seconds to retype the name, address, phone numbers, etc. from one system to another. With 300 users processing 5 calls a day over the course of a year it would save $342,562 (2.5 minutes each day * 300 users / 60 seconds in a minute / 60 minutes in an hour * 261 days in a year * $105 an hour).

Employee Satisfaction. If turnover is a problem, changes like the one above can help with retention by impacting the way employees feel about the work they do. Each improvement can be ranked as low, medium and high based on how much it would contribute to retaining an employee. Assume it costs $5000 to replace an employee. If it is something slightly annoying the low value may be $1000. Medium might be $3000 and that thing everyone complains about would be $5000. Multiply that value by the number of employees impacted by the change. Ten employees using a high value change would have an ROI of $50,000.

Client Satisfaction. One company I worked for assigned a general value of $200 flat rate for client satisfaction. That seemed a little low to me and everyone had forgotten why $200 was chosen. For yours try basing the value of a modification on the likelihood of the client using your service or buying your product again. Dropping response time by customer service by 20 seconds may increase the loyalty in 1 out of 50 clients. What does an increase of 2% in repeat purchases do for your profit?

In the end the business owns ROI calculations and should have the final say in what is decided. It isn’t an exact science but together you can develop a meaningful way to attribute value to your changes.

May 7, 2007 – Confrontational Conversations

It was a rough game. During the week I spend my life as a mild mannered project manager, but on the weekends I turn into an AYSO Soccer Referee. Unfortunately this time there was trouble. The blue coach was the one that started pushing my buttons. It probably started right at the beginning when I informed him that his spectator’s dog had to leave the field. From then on he questioned everything and generally caused me grief. I ended up calling both coaches to the center of the field and loudly telling them to knock it off. It was my first such confrontational conversation as a ref.

Back in the “real world” of project management I had a similar situation. It was the week of implementation on a major project with an aggressive time line. We had completed testing and found there were pre-existing data issues requiring a work around that could cause a delay. During the go/no-go meeting the Sponsor appeared to be insinuating that we wouldn’t be in this mess if we had done our jobs right. Needless to say, the team was not happy and I had to confront her about it.

I don’t think I handled either situation well. Upon reflection I should have taken the following advice.

Plan ahead. If you are a project manager or even a referee you will eventually have conflicts. Decide how you are going to react in certain circumstances before they occur. It would even be helpful to role play with someone. There was a manager at one location I worked that yelled at project managers to the point of making some cry. Just for the record crying does little for a PM’s image. I decided that if he tried it with me I would calmly say, “I see that this has you quite upset. Perhaps it would be better if we rescheduled this meeting.” Then I would stand up and leave. I don’t know if I had the guts to do it, but I was ready. I should have had a plan for handling that coach, too.

Handle it immediately. Had I addressed the coach one-on-one the first or second time he hassled me I might have been able to put it to rest without any further issue. By not taking action it started to spread to the parents and then across the field to the other coach.

Think before you speak. After the go/no-go meeting I spoke with my team and realized they also felt trampled on by the Sponsor. Something had to be done so I trudged back to the meeting room. Rather heatedly I let her know we didn’t appreciate what she had said; how we felt that the scope of the project was complete; blah, blah, blah. It wasn’t my finest moment. Had I thought through what to say prior to confronting her things might have gone better. The wrong choice of words can leave lasting bad impressions.

Speak. After thinking it through you may rationalize yourself into not taking action. Don’t let the problem fester. By avoiding difficult conversations you build walls that get thicker over time and make it harder to deal with.

Confirm your feelings. After I was done spouting off to the Sponsor we started talking. It turned out she wasn’t attempting to put us down and she reiterated the good job we had done to that point. Had I started by confirming that my initial feelings were correct, the conversation would have been a bit more constructive.

Remain calm. When I called both coaches to the center of the field I started aggressively telling them that I was in charge. I nearly yelled, “Who is wearing the yellow shirt here!” Good old blue coach said, “Well, she is…and he is…and you are” pointing to the Assistant Refs and then to me. Things weren’t going well. I should have remained calm and allowed him to yell. It would have given me the moral high ground to regain control of the game. The whole field didn’t need to hear our conversation and it probably added to the problem.

Use humor. Humor is a wonderful creation. I’m glad God added it to life. With a quick, witty comment you can get people to step back from the situation and gain a different perspective. That may be all you need to stop a major incident.

Fortunately for me soccer games last less than two hour.