Skip to content

Posts tagged ‘lessons learned’

Adventures in Offshoring

You never know what you are going to learn as you enter the world of outsourced software development. I’ve talked here in the past about the abuse of the traffic signal in status reports, picking a vendor, and a whole host of other considerations that need to be made. Nothing prepared me for this.

One key member (read: the only one who really knows how to get anything done) of our offshore team was in an accident the other day. Allegedly a bunch of guys were riding their motorcycles drunk, and ran into him. He was in a car. Apparently the rule is that the person in the bigger vehicle is the one at fault. So they started harassing him for money – to which he wanted to just handle it through insurance.

The story becomes strange when the drunk motorcyclists start having our guy arrested for non-payment. The police were there to arrest him when he showed up to work. Keep in mind – they hit him. So now the police have offered to take care of it, in exchange for a bribe. He doesn’t want to give them money either.

I think I would pay the bribe to the cops. What would you do?

Agile: The Most Overused Word in IT

A quick glance at the dictionary gives us a definition of the word agile – “marked by ready ability to move with quick easy grace.” The IT community has co-opted this word and extrapolated a meaning that is really beyond description. Of course, what else were we supposed to do?

Much comparison has been drawn between building software and physical construction (e.g. building a house). But this comparison really isn’t fair. While it’s true that it’s extremely costly to make changes to a building after it is erected, the same multipliers used in that industry cannot be applied to software. Seriously – have you ever had to bring a demolition crew in to remove a section of code? The delete key is our wrecking ball.

At some point, I’m sure a manager looked at this software construction like building construction parallel and said, “I need you guys to work in a more agile manner.” And there it began. Sure, there were puzzled looks in the conference room, but then they all went back to their war room or desks and started figuring out what the manager meant by agile. Today, we have a half dozen agile methodologies that address this perceived need to move fast. Each of them has their own caveats of “this may not be the best approach for you.” Unfortunately those sections seem to be often skipped.

The Software Development Life Cycle you choose for your project should not be dictated by whichever magazine article is sitting on your desk at the moment. It is a choice that needs to be carefully made based on your entire situation. What is the makeup of your team? Do they work best on well-defined tasks or are they better when left to find creative approaches? What is your relationship and level of involvement and commitment with your customer? What type of project is it – are you solving a well defined problem or is further research required?

My parting thought for today is a continuation of the last paragraph’s them – ask questions. If you are the team lead or project manager, your value comes from applying the experience you’ve gathered from past projects. When your customer or manager makes a broad statement, dive into it and understand what he is asking for. You will then have a much clearer shot at success, no matter what methodology you choose to deliver it.

Project Management – Abuse of the Traffic Signal


Red, yellow and green (unlit) LEDs used in a t...

Image via Wikipedia

If you have spent any time on a formally managed project, you have no doubt seen the status reports with the green / yellow / red codings. These symbols are taken from the traffic signal concept, a concept that is universally accepted. Green means go, red means stop, and yellow means SPEED UP!!! Just kidding – yellow means caution / clear the intersection. With such clear meanings while driving, and the generally anal nature of project managers, you would think that clear meanings would be established for green, yellow and red signals on project status reports.

You would be wrong.

My favorite current example is a project whose one-slider (one slide divided into four quadrants for accomplishments, issues, milestones and budget) is covered up in red on the milestone sections. It is clear that the milestones that have been set have been blown through, and the work necessary to complete that milestone is late. However, the project overall was still showing green on time. This is a project that has not met A SINGLE DELIVERABLE DEADLINE. How can you be green on overall time, but red on practically everything else (the milestones that were still in flight were showing yellow). This led to a somewhat heated debate – and I got my point across. The project is now at least showing its tracking yellow.

My point here is not to throw anyone under the bus, but rather to share a lesson learned. You need as a team to agree up front on how status will be reported and what the criteria for having a green, yellow or red color code is (or whatever system you are going to use to give high level status). That way, the status is not being re-negotiated when it really should be black & white (or in this case red).

Getting Your Ideas Off the Ground

A recent Harvard Business Review online article covered the “Five Powers that Get Ideas off the Ground.” This is an area that I find a lot of people, including myself, struggle with at times. Quite often an idea is vague or is complicated by a great deal of unknowns. As humans, we like to work off of certainties so that we know what direction we’re going. At work I try to get people moving by baking in step of “figure out where we’re going” into project plans. This gives the opportunity to further flesh out plan details while you go, while signalling to others reading the WBS that turn-by-turn directions will be spelled out once detailed planning is complete.

Kanter’s article points out a step that I overlooked above and one that is absolutely essential – showing up. She refines that as being physical presence, rather than the more nebulous approach of just being present in mind. She says:

There’s a well-known saying that 90% of success in life comes from just showing up. It’s a cliché because it’s true. Digital and other remote communications are efficient and helpful, but there’s much to be said for being there, face-to-face with other.

This is very true and something that I have personally experienced and subscribe to. Many people, myself included, enjoy working from home. But I do it sparingly. I don’t struggle with productivity, depression, or any of the other commonly cited reasons for not telecommuting; rather, I find that because I work on a team I get more done when with that team. It’s a true form of synergy. When people show up and speak up (two of the five powers), clarity begins to be added to the situation and actionable items begin to take shape. It may not be the whole road map, but at least next actions can be defined and worked on.

I highly recommend that you read the Five Powers that Get Ideas off the Ground to help you get your next idea off the ground.

Engaging Your New Hires

An article in the Wall Street Journal this week talked about a great technique for getting new hires excited about your company. It involves figuring out who the employee’s support system is behind the scenes, and then sending visible signs of appreciation for them to enjoy. I personally experienced this over a decade ago when I arrived home from my first day at Solarcom to find a flower basket had been delivered as a welcome gift. Of course, that is where it ended, but it was a good start nonetheless. Michalowicz says:

Here’s the key to winning over an employee’s family: Start from day one. The first thing your newly hired staff member will likely hear from a significant other when he gets home is, “How was your first day?” If he spent it mostly filling out a three-foot stack of forms, ordering his own business cards and eating lunch alone, he might rightfully answer: “Lousy.”

His solution is to get all of the paperwork out of the way before the new hire walks in the door, and instead have the employee spend the day with his new manager learning about the company, going out to lunch with co-workers, etc. While this probably works well for a small business, I couldn’t imagine spending an entire day with the new hire. And doing the paperwork before starting?? What a waste of my personal time Wink

However, I do believe that he’s on to something by appealing to the support system. If you win them over, then they will be much more supportive when you have to travel, work a late night, or some other event occurs that requires a change of plans back home. 

Read more -> Impressing Your Employee’s Better Half