Minding the Plan

When I told a few friends recently that I was discussing a partnership with the founder of a top-notch offshore software development house in Romania, I was generally greeted with disgust and/or glib patriotic remarks. Their statements generally went like this, “I hate offshoring because it takes away American jobs. There are so many people who need jobs now, and I think it is unfair to send them overseas … “

WYP BLOG ID:8116

What’s frustrating about this blanket statement, aside from the fact that it doesn’t consider the fact that there are certain job sectors (like nursing and software development) that currently do not meet the demand for qualified applicants, is that it completely ignores what it means to run efficient, effective teams.

The purpose of running teams and projects is to be involved with the best; with high-quality people who you respect to not only help accomplish your goal, but to push the bar forward. Yes, of course there are advantages with cheaper labor, but it’s not wise to conclude that just because a person lives in another country, they should be excluded from your team. And, since technology has advanced to a point where communication is seamless, it’s really only time-differences that make it difficult to converse overseas.

Take the guy I met in Romania, for example. He is a great guy – a guy that, if he lived in the US, I’d be excited to work with on a day-to-day basis. If I didn’t accept the fact that it’s okay to work with outsourcing companies, I’d never have had the chance to meet him, or be able to work with him in the future.

If you look at the whole picture, it’s really about working with great people. Don’t penalize potential top-notch team members just because they don’t live in the US.  If you really want to tackle the US job issue look at creating the best educational system possible.  This will ensure that our children have the tools and leadership capabilities to create the industries and markets that will create the jobs of the future.  Also, it will enable us to easily retrain existing workers to new roles and functions.  Having a protectionist attitude will not keep us on the forefront of innovation.

Think otherwise? I would love to hear your comments.

Best,

Josh

Thanks to the good graces of the creator, evolution or due to the fact that some of our ancestors decided to snack on a Golden Delicious or two (whatever explanation of our origin floats your boat), humans tend to have their own beliefs and opinions about what is the correct thing do in a given situation. Given all those years of non-conformity, how is it possible to accomplish even the simplest notion of a collection of discrete tasks known as a project?

In a previous post I talked about Bruce Tuckman’s “Forming, Storming, Norming, Performing” model, and for the most part, the mentioned phases typically occur as noted. However, there is an interesting case that I have experienced which is never good for a project manager and must be corrected immediately. I call this Forming, Storming, Ignoring, Non-Performing.

The first stage usually plays out as outlined by Tuckman: teams meeting for the first time are on their best behavior, but the second stage is where things start taking a twist. People on the team raise objections to the new format I try to introduce. I hear that this company is different and my new format won’t work here. Or that it has failed here in the past. For a period of time, we talk about the pros and cons and make compromises along the way. Finally, there comes a time when I think we have all come to a consensus and are ready to move to the norming stages.

Unfortunately, this is where the dreaded Ignoring stage starts. The team begins to work on the planned activities, and they even understand the format I want use, but they ignore the direction I am trying to establish and substitute in tasks where they want to spend the effort instead. It is always interesting to come into standups and listen to team members start taking about how they are off shaving yaks somewhere. FYI, I typically run software projects, and got out of the wool business years ago.

If this continues long enough, then this where the team really becomes non-performing. If the team doesn’t agree on a direction for how features should be delivered, schedules slip. When this happens, no one on the team benefits: the developers feel terrible because of missed deliverables; I am in the hot seat because I didn’t deliver and can’t control the team; and the client has wasted time and money.

Pretty scary, huh? Okay let’s talk about the tonic (think ounce of prevention is better than a pound of medicine).

There are two reasons, in my experience, for why this happens. 90% of the time, that reason is me. The team starts to ignore me when I ignore them. Don’t get me wrong – I don’t do this intentionally, and it is usually directly proportional to my workload. If I try to take on too many projects at one time, I can’t focus on them all adequately enough, and therefore don’t give the tasks or the team members the attention they need. Then what ends up happening is that co-workers are too polite to tell me that I am dropping the ball. They each decide to go in a direction they think is right, but not necessarily the same direction.

The solution to this very easy to understand, but hard even for me to act on since it relies on being honest and addressing my limitations. At this point it is crucial to talk to my bosses and the team and be up-front that I need help figuring out how my work can be restructured so I can be attentive again. One thing I always make sure to do is bring solutions to the problem and not just spend an hour bitching. I am always surprised at how understanding people are when you bring issues and solutions to the table, and for the most part the necessary adjustments get made.

The other 10% of the time, the Ignoring stage happens when I can give adequate attention, but there is no clear direction from upper management and there are very smart people on the team.

In my experience, it’s also not the entire team that ignores me, but rather a select individual who has a negative disposition toward project management. The problem is compounded even more when upper management discounts project management and deliverable tracking, thereby giving further vindication that these are okay to ignore. Since this individual is very smart and respected by the other teammates it sets a standard that propagates through the team. This individual is not being vindictive it is just that he/she is very smart and is operating on a different plane where there isn’t much room to think about project administrivia – like reporting on a task. By no means am I saying that I hate working with these types of people. In fact, they are some of my favorite, and are very critical team members if you want a prayer of solving the most difficult problems. But what I find helpful is to sit down with them privately and chat about the project, their values, and what they think are the right leadership strategies. Usually by doing this we can establish a mutual respect and an understanding that my pestering about statuses and tasks tracking is not an affront to their intelligence, but rather a way in which I can keep the team in sync and communicating. The key point though is that this one-on-one has to be held as soon as possible (ideally in the forming or storming phase) and shouldn’t be unaddressed.

Well, I hope this post wasn’t too long winded, and it would great to hear anyone’s thoughts on the matter.

Best,

Josh

For this post I would like to talk about a concept that I think explains effective teams quite well. I will reference this post in future posts to help explain some of the more interesting experiences I have had managing projects.

In 1965 Bruce Tuckman developed a model of team development now commonly known as “Forming, Storming, Norming, Performing”. In short, it is prescient observation of how individuals within a team come together and attempt to complete a project. In the projects I manage, I make it a point to periodically step back and reflect on Tuckman’s principles, and then assess if the ship’s course needs to be corrected. As you will see in later posts, sometimes that assessment can produce a freakin’ scary realization, but first let’s talk a bit more about the Forming, Storming, Norming, Performing phases.

Forming Stage

The first stage is where the team members are introduced to each other and to the project as a whole. Here are some points about what occurs during the phase:

• They meet and learn about one another and the opportunities and challenges they face
• They agree on and begin to deal with goals
• Typically they are on their best behavior and polite within the group

Storming Stage

This stage is where competing ideas are thrown around for consideration. Some teams leave this stage quickly, while others never leave it. Team members:

• Figure out what problems they’re really supposed to solve and how they’ll interact to do so
• Are more open with each other and more likely to confront one another
• Act out – if their maturity level is fairly low – trying to convince others that their ideas are the right ones
• Avoid real issues – if they don’t like conflict – and focus on finer details

In my experience, I notice this stage most clearly when I introduce the methodologies and strategies on how the project will be run, tracked and reported.

Norming Stage

This is the stage where the team finally starts to click. Team members:

• Modify their behavior toward each other and even begin to trust one another
• Agree on rules, regulations, workplace values, appropriate behavior, tools, and more
• Increase their motivation as they get more comfortable with the project
• Take on more responsibility

This is usually when I start to rejoice in a project. I am very clear not to interfere as much and let the team start running.

Performing Stage

As the team has been running for a while, this is where the real performance occurs. The project becomes fluid and second nature. Team members:

• Function as a team without a lot of conflict
• Become interdependent
• Are motivated, proficient, experienced, and self-directed
• Expect to have a difference of opinion and welcome it as long as it follows the rules from the previous stage
• Revert to earlier stages when necessary, and typically when outside influences disrupt the flow

I hope this post has been informative and makes it clear which stages a performing team can undergo during a project. Please feel free to write a comment and stay tuned for future posts that build on this one.

Best,

Josh

That was the first thing my mother commented on when I showed her the picture above. It just so happens that I was not wearing pajama tops, but a very formal piece of attire, called Batik, commonly worn for special occasions.

I had just started a new project with a large telecom provider in Kuala Lumpur, Malaysia, and was very new to the Malaysian city and culture. I wanted to explore the city a bit, so at the end of one of our last meetings, I asked if anyone wanted to join me for the weekend. Check that, I basically begged someone to take me around the city. A co-worker graciously agreed to show me around and we hit a night market (where I bought the Batik) and a night club. What was even better that was that my colleagues and I had such a good time that they invited me to attend a wedding in a remote village outside of KL (where I wore the Batik). The weekend was a blast and I saw some incredible things; and since I had an expense budget to use, it was all that more sweet.

Right about now, I’m sure you are thinking, “that’s great, but what does this have to do with managing projects?” Well, the one thing that I learned is that for each new project I become involved with, I will always make a point to let people know that I am human, and that I have a life outside of work. It would be a terrible start to the project if the client thought I was a Gantt-chart-creating, budget-hawking stiff. Even if it’s asking, ahem, begging co-workers to go out after work, I make sure that it is one time where I am not bashful.

I found if I make that connection outside of work, then I can quickly establish a trust with co-workers; they can relate to me on a personal level and therefore have a better understanding about decisions I make. They’ll see that I do look out for the needs of others – especially people on my projects. And once they’ve seen my moral structure and my values outside of a work setting, it makes it easier for them to go along with controversial ideas that I may have to make in the future.

Since we now have a rapport, and can joke around together, it makes it easier for co-workers to feel more open and to vent around me when a project gets stressful. For instance, at the wedding I was forced to eat with my hands (which was quite a comical sight), and I would always remind my co-workers of that imagery whenever I needed to cut the tension.

One thing that I would like to warn of is that while the project is still in progress, I am always very careful to maintain an air of professionalism and not end up as buddies; it’s harder to make business decisions if personal matters get in the way. Thus, I recommend inviting a large group of co-workers, and not to single out one (or worse yet the one you are most attracted to).

As a new project manager, one of the toughest things to do is to prove that you’re a leader who should be listened to. Inviting your co-workers out after work creates ample opportunities to show that you are capable of making great decisions, and allows people to be comfortable around you. So, go out there, don’t be bashful and ask your co-workers to hang out after work. I guarantee you will create memories that you won’t forget.

Best,

Josh

P.S. – Have any good examples of how you approach new projects? Add a comment below.

After a little delay in getting things organized, “Minding the Plan” is open for postings. At this point in my life I have never been more excited about where I am and the opportunities that await, and the purpose of this blog is to express some of my thoughts and experiences. Not only will I talk about my career as a project manager and how I have transitioned into the world of consulting, but I will also attempt to explain interesting situations of human behavior that I have been involved with. More importantly my main goal (albeit probably the most difficult) is to create a community where people freely post comments and engage in discussions. I will do my best to facilitate that.

Now on to a few disclaimers. All of the opinions expressed in this blog are my own, and any references to people in my articles are personas that I have created. While past acquaintances and situations may have helped shaped that creation there is not a direct relationship to specific people. In the cases where I have specific consent to reference real people then I will make sure that it is clearly stated.  Lastly, I do encourage people to post and email me comments, but I do reserve the write to delete posts as I see fit.  While I will always err on the side of freedom of speech, if a comment is obscene, spam or infringes on the rights of others it will be removed.

Lastly, before I wrap up this first post I have yet to finalize a design and layout for this site, and as such things may change. I felt it was more important to start posting and getting in the flow then have an catchy site established. Thus, please forgive me if it looks a bit bland.

Best,

Josh