Improving the morale of a project

So a few months ago I started as a project manager on a huge, $100 million, 300+ person, multi-phased, complicated IT project. You know the type.

Last week, the program manager quit and while they are looking for someone to replace them, I’m defacto in charge of the project. Oh my.

One of the feedbacks we’ve been getting is that the project is not “fun” and while we are not heavy handed per se, morale is suffereing because it’s all deadlines, tracking and accountability, and no fun.

I’m trying to come up with ways to make the environment more “fun” for lack of a better word. When I was in the position of doing the actual work (ahem), I always hated the bullshit things upper management did to try and make the project more “fun”. I always throught that these efforts kind of treated the professionals we were like middle school children. But there is a real push to make things more fun around here.

So anyone with project management experience, or anyone who has been managed on a project, what was the most morale lifting thing that was doen on your project that made it better?

My ideas kind of center less around “get a popcorn machine” and more around “let’s all converge as a well oiled machine and know we can all rely on each other” type of approaches. One of the tihngs I am noticing is that there is a real reluctance to speak out during meetings, stand-up, etc. if there are issues or problems or confusion about processes, how things work, etc.

So how do you improve morale on a project? I’ve used various devices in the past but most center around “let’s get this shit done effectively so you can have a life outside work and don’t have to spend 80 hours a week the two months before go live”. That’s my idea of fun. But your ideas may be diffferent.

Thoughts?

As a bonus, if I end up using some ideas, I will totally give you the scoop on how they worked.

I think your main problem is identifying the complaint-- what the hell do your people mean by “fun”? Your comment on middle school children is apt: if they’re looking for actual entertainment, then you do have to treat them like children, because child-like rewards are what they’re looking for (e.g., popcorn machines).

I don’t manage projects in IT, but I do manage projects staffed by professionals (mainly attorneys and paralegals). There, I think morale is best raised by acknowledging measureable accomplishment. Tracking and accountability can be a dreaded thing, but it’s also a way to clearly measure success. Acknowledging people for success should hopefully raise morale. You can, assuming you have the budget, tie that into more social activities like a nice lunch or dinner, though your team size may make that challenging. Heck, even a 10 Starbucks giftcard might help to acknowledge success.

So, what are your people looking for? Entertainment or accolades?

Floggings.

Actually, I’ve never seen anything particularly positive, though I’ve seen lots of negative practices.

As for the “speaking up during meetings” issue, I suggest encouraging speaking up outside of meetings. Meetings by their very nature tend to be huge time-wasters. They’re efficient if everyone in the room needs to know what a particular person is saying, but they waste the time of anyone who does not need to know. If, for example, they’re about getting status reports, it’s a lot more efficient for the person who needs the status (the lead) to get the status from each person individually. If it’s a brainstorming session, you want only the people who will actually be effective talking through the problem. Often that’s just 3-4 people.

Forget popcorn and other gimmicks.

If you want to get people’s attention, cancel any ongoing meetings that aren’t truly necessary. Most people consider them a waste of time. If their only purpose is for one person to distribute information to other people, it is a waste of time and can easily be replaced by an emailed report.

Go find opinion leaders, regardless of job title, and sit down with them one-on-one and ask their opinion. Not on what’s ‘fun,’ but on whether the project is properly resourced, scheduled and executed.

Ask people what parts of the project cause them problems, then work of fixing some of those things.

Anyway, good luck!

I’ve been in a similar situation. Sometimes as a dev you get bogged down with details and you forget what the big picture is. This is where some user-centered design work can really come in handy. If you’ve lost the big picture, have a user-centered designer sit down with you, do some research, and present a fresh perspective on what you’re building. If you already know the big picture, it may help to have a fresh perspective anyway.

Some things to address:

– What are you building?
– Who is it for?
– How will they use it?
– What makes it unique / interesting?
– And, for each dev team, what is my role in making this project awesome?

This would also help, but I would caution you against doing this personally. Again, this is where you should find a user-centered design expert and use some existing methodology to get to the root of the problems.

Have to agree with the above - engaging with the people who are struggling is really the best way to get rid of “unfun” aspects. However, fire is correct in that you probably want a filter between yourself and the opinion leaders.

I got out of the IT rat race about 18 months ago, but I remember well situations just like what you’re describing. My role was never the overall leader, but I did have some leadership responsibility in smaller groups.

I think Gus is right on about people speaking up outside of meetings…or at least in meetings in smaller groups, not giant “all-hands” type meetings. I found that I could usually get pretty decent feedback with my own small team of 4-5 people, but no one would ever talk when in a bigger group. Get your line managers/technical leads/etc to pull feedback from their people and bubble it up to you, and address those concerns as points in your agenda in the larger groups. It’s still a good idea to allow time for feedback in those big meetings, but don’t rely on it as the primary mechanism for addressing issues.

On the “fun” front, I enjoyed a couple of things that can probably translate to most environments. One was a hot dog day…once or twice a month, we’d get a grill out (or use one of those roller machines in winter) and cook up a few dozen hot dogs (including veggie dogs as needed) for the whole office. Actually we’d make the interns cook, which just added to the fun. No embarrassment like with most “team building”, no special planning ahead needed, just a chance for people to hang out around the hot dog machine, talk a bit, then return to work. The other was yearly organized whole-day team outings like tubing down a river or going to a baseball game. Those obviously cost more and take more planning.

One thing you do not want to do, at least in the opinion of the vast majority of IT professionals I worked with, is “team building” events. I attended several, including sand-castle-building, the traditional out-in-the-woods-for-rope-bridges-and-such, and a session I have a hard time describing other than to say the guy was way too cheerful for his own good and utterly failed to encourage audience participation. None of them were as effective as even one hot dog day at getting people to enjoy themselves.

Also, if anyone on your team is doing basic group-building…happy hours, organizing groups to go out to lunch, a project softball team…encourage it. Showing up yourself is one way, of course, although depending on the culture of your organization that may not be your best bet. You can have an impact in other ways, too, like minimizing the number of lunch meetings to allow folks the opportunity to go out, or asking that meetings end no later than 4:30 on the day that happy hour is scheduled.

Edit: And another thing I should have added in the first place…make sure people understand that pointing out problems is not a career-limiting move. A lot of managers beat the drum for hitting deadlines and budgets, but never pay more than occasional lip service to the idea that getting a problem fixed with a delay is better than putting out a bad product on time. Having been in the whistleblower position myself, when my immediate superiors kept promising the impossible to upper management until I had to go around them, I know that it’s a stressful thing for anyone to have to do. Hopefully your organization is healthy enough that you won’t have that particular situation, but you should be prepared and provide a method for folks to point out problems (anonymously, if necessary) and a process for following up on those concerns so you don’t end up blindsided by manager(s) sugar-coating issues in their little fiefdoms. Having this in place and making it work will go a long way toward improving morale, because nothing hits your team’s morale harder than having to scramble to solve issues that they knew were coming but never got addressed by leadership.

Thanks so much for the thoughts so far, everyone. Interesting reading these over lunch…

Beer and food goes a long, long way for me. Especially with no dumb “team building” garbage strings attached. Every time I’ve done team building the beer and food at the end have been the best part.

My guess is that it’s more about “satisfaction” than is it about “fun.” It isn’t so much that people want to feel entertained as it is that they want to feel like they have agency over the work. Basically, that means giving them some modicum of control, which can obviously be a risk if the person isn’t actually up to the task, but that’s what your role as a manager is for (delegating responsibility according to ability).

I’m still refining ways to do this personally, but the other idea around the idea of “fun” is to balance challenge and reward. As mentioned above, the trick is to find a way to incorporate those concepts without it coming off as gimmicky (well, unless that’s what your team needs).

Normally I would avoid scheduling lots of meeting, but actually, I’ve seen very short daily update meetings work well in some contexts where it helps individuals wrap their heads around the bigger picture.

IMO the superficial stuff has minimal impact. Making the team realize their project is important and valued as are their own individual contributions is infinitely more important than providing free bagels or a ping pong table or some such damn thing. And that’s not done just with words, but with real concrete things like bonuses as well as with increased participation in decision making.

Lots of good advice here. My small contribution would be to recommend one-on-ones. The first few (especially in IT) may not go very well with some individuals, but most people will open up and you will get a good composite picture of what people are really thinking.

I agree on the corporate team building event thing. I recall being sent to one of those. It was a 3 day retreat in the woods managed through some company. We did the falling back trust exercise and similar nonsense. Didn’t build any team spirit in the least, and to top it all off, a good chunk of the team wound up out of commission with suspected food poisoning. (Pretty sure it was the tuna sandwiches for lunch on the last day).

On the other hand, a more impromptu one in a different project worked out well. I caught wind that the poduct development and marketing folks were planning on laser tag. I butted in and asked that engineering and IT be included. We ended up with enough people to rent for ourselves one of the laser tag arenas for 3 games. A good time was had by all, and really did help to bring the marketing, product development folks closer with the technical teams.

One-on-ones with a trained professional whose job it is to uncover process challenges and recommend solutions. Not with you, their new boss. Results should be anonymized and presented to you in aggregate. Otherwise it’s hard to convince folks to be honest, and it’s nearly impossible to wade through the weeds and find the way out.

I have a bit of non IT management experience and what worked for me is leading by example. So this means you have to do your job the way you expect them to do their job, in terms of attitude/collaboration/team work/etc. Next, identify who needs to do what and by when, then notify that person of his/her responsibilities, then make sure they have what they need to do their job, then set them to it. If there are roadblocks in their way, it’s your job to clear those roadblocks. You’re the puppetmaster, you have to make those puppets dance, they won’t dance on their own.

Btw, my experience is that when people say it’s no fun what they are really saying is “I’m bored”. Proceed accordingly.

Yeah, this is probably a good idea if you are talking about rooting out a specific problems or challenges that exist within a specific project or program in a limited time frame.

I was speaking a bit more generally (which may not be applicable in ElGuapos case as this sounds like a short term gig) but I’ve found that routine one-on-ones with direct managers does help quite a bit with base morale. It helps build good working relationships and gives people a voice, which is especially important if no one wants to speak up in a meeting with their peers.

Of course, YMMV and again this might not be a great suggestion for a new PM on a 300+ person project.

The first question I’d be looking to get answered is how the team views management. Both as a whole and individually. Do they see them as part of the team with different roles to play? Or is it more adversarial? If the latter, why is that? Is it a resolvable issue? The heart of the question is simple: Do they trust you? If not, how can you build that trust, at least to the point that they’ll work with you (directly or indirectly as others have suggested) to identify and fix the problems.

Full disclosure: I’m in management, but not of a team anywhere near that large. Just a lowly first level manager here.

Maybe a hot tub that can fit 100 people for a feel-good meeting, because after all you are El Guapo? I have no idea. I was part of about a 40 person IT project once and it gets a bit comical because there are so many moving parts that affect the other moving parts. You get your goals and slog towards them and every week, if not twice a week or more, the goals get redefined. You shrug and continue on.

The more bodies you throw at software development the more inefficient it becomes, even if it does shorten the development time, is my experience. As to the fun part, that’s mystifying to me. If you like what you do it’s at least sort of fun. If you don’t like it, how can it ever be fun? Maybe schedule a paintball excursion so the devs can symbolically slay all the managers, followed by beer and pizza?

19 posts and it’s left to me? Obviously, the answer is that the beatings will continue until morale improves.