Things I Learned From Managing My First Project

A very long time ago I was an account manager for a very tiny web development firm. We managed about 100 accounts, although at any given time there were only a dozen or so active projects. I enjoyed the juggling and the coordination of the tasks, but I grew impatient with our developer, and taught myself more and more coding skills so that I could take on more and more of the tasks myself. Since then I've worn many hats, and coordinated many projects, but this year was the first time I officially wore the hat of "Project Manager" in my new position at Drupalize.Me. I learned a lot along the way about how to work with an internal project team. Most of it was obvious, but it took the school of hard knocks to bring me back to basics. Here are a few of the truisms I wish I'd remembered sooner rather than later.

Moods are infectious

Every day everyone brings themselves to work and in a distributed team you rely on voice and typed words. Sales folks train themselves to smile when talking on the phone. They say it changes the tone of the voice. If you feel the team is trending towards frustration take the time to check your own attitude. Smile. You might be able to pull the team into your good mood.

To track a trend, use empirical data

Much like watching your weight, daily fluctuations are typical, and it's the trends you want to watch. To monitor your team's health over time, you need to track everyone's attitude on a daily basis. Daily mood logs are used by many therapists to help a person track their well-being over time. Track your team's mood with empirical data instead of hoping you'll be able to see the trends evolve from week-to-week.

Language matters

We had been referring to our launchable site as a "Minimum Viable Product". It didn't resonate with the team, who wanted to create something better than something which was just barely good enough. We changed our language to remove the loaded phrase. In our ticketing system, we updated the backlog title to be "Launch Blocker Backlog" instead of "MVP Backlog" and pride emerged from the team for the product they were working on.

Closure is important

Originally we worked on two week sprints. At the end of a sprint, any ticket that wasn't completed lingered in an old sprint. Based on a comment from James Sansbury about one of his projects we changed how sprints were loaded and completed. Each sprint is now only a week long. At the end of the week, the old sprint is closed. Outstanding tickets are moved to the current sprint. Anyone is allowed to put an unfinished ticket into the backlog. No shame; no blame. We begin fresh today and move constantly forward.

Sort for yourself; format for others

I love spreadsheets. I assumed everyone else did too. They don't. Who knew? Instead of creating spreadsheets to share with others, I now create summaries with markdown within our ticketing system. Now that the team receives the content in their preferred format, I find them more likely to engage in conversation about it.

Adrenaline is finite

When I first started on the project, we kept making optimistic, arbitrary launch dates. Being our own client, we could make whatever deadlines we wanted. "In time for DrupalCon." "At the end of July." We had no empirical data to suggest these deadlines were possible. Shifting deadlines are exhausting and we were burning ourselves out. As soon as we removed the arbitrary dates, people were able to enjoy their tasks a little more instead of constantly feeling a time pressure. This made people happier.

Minor choice makes a major difference

When I was first given the job of "loading sprints", I assumed I was supposed to pick tasks for people. No one told me otherwise. I'd load up the sprints and send out assignments and would be met with the abyss. When we changed to everyone choosing their own tickets from a prioritized list, sprint loading became more dynamic and people had only themselves to blame if they didn't enjoy their tasks. It still takes me about 1.5 days to close a sprint and prepare the next one, but people seem to enjoy their work more during the sprint.

Acknowledgement kindles effort

In software, a job well done is often invisible. If I no longer see error messages, it's as if the solution had always been there. Ensure the effort of your teammates is visible. The more you acknowledge their work, the more they will want to work for you. Even if you are not grateful, or wanting to give thanks, you can still acknowledge the effort someone has invested in their tasks.

Moderate what you change, including your moderation

At first I found the lack of feedback on my processes really difficult. I didn't know how to evaluate if I was implementing good changes or bad changes. So I'd change my approach. Frequently. This made it very difficult for people to track what a week's process was supposed to be. Finally we threw it all out and started again. Consciously. Any changes we make are now immediately documented in a centralized guide. The guide is a trusted document, but also not so holy that it cannot be changed if the documented procedures are not helping the team accomplish their tasks.

 

I was prompted to write down my truisms after watching this presentation on prezi which had a diagram from The Five Dysfunctions of a Team (I highly recommend you read this book too). It's true that my list doesn't come with a neat little diagram and a cast of characters, but it made me feel better to remind myself of where I'd been and where I was today. Perhaps you have your own basic rules of life that you wish you could go back and share with your past self? "Future me" would love to hear about the lessons "past you" has learned about project management and working with an internal team.

Related Topics: 

Comments

First of all, thank you for this great post. And I identified with your experiences and agree on all of them!
I would love to see more of this kind of material, because managing a team of exceptional people is not an easy task.

Moods are infectious, yes! and something like a smile, can change the climate can't agree more, but! any day, someone of the team its going to argue about something, and more than ever is an important moment to remember that, check your own attitude (like you said), your tone of voice is loud? are you being aggressive? listening the other person first, try to understand him first.

Here at Taller we discover that in a 2 weeks sprint, the team productivity increases with each passing day to the deadline, so we change to a 1 week sprint, so monday is planning and architecture day, then four days of pure production with less things to deliver at the end of the week. This way the results in a really engaged team with better estimates. But! in other projects we prefer kanban and not scrum, taking out the sprints things, and focus in each feature(client value) and not in a bunch of them.

Changes like this, are a big deal when you have an on going project with a go-live deadline, but at the end it worth it. Nothing like a change to have different (...better?) results. And, like you said, a good guide or documentation keeps everyone tuned about this changes.

Something I would like to add here, the teams in order to deliver a real value (non-waste) to our clients, everyone must understand WHY the hell they are delivering X feature, and most important than all, participate in that decision. So now, they are not just doing things because they must, but because they believe is the best thing to do, and they are a part of that great result.

Sorry for the long comment! but I love to talk(even more!!) about this topic!!

Cheers!!

Thanks so much for your reply! I get excited about this stuff too. :) I completely agree about the "why" bit. We've started adding quartely goal planning to part of what the team does...and which get broken down into actionable tickets. It's really exciting for us to see the progress and know what we're reaching for.

When I was first learning about Project Management, and thrown into my first PM role at work, I remember desperately asking for some samples of project plans before diving in and creating my first attempt. All I was told is that I could create my plan in Microsoft Excel or Microsoft Project, and that I should just get started. It was one of the more frustrating parts of shifting towards my role as a PM. A few years later, I watched as a budding PM was asking the same questions I had asked, and getting the exact same answers. He was just as frustrated as I was!I got all the trainning on handling a project from scrumstudy. I would suggest you to take a look at them. looks pretty different and their methodology is really interesting and effective. I personally felt it stands out for the quality of the materials provided..

Wonderful article! This provided detailed information about project management and how to make use of it. Moreover, I have seen a growing demand for Project management certified professionals. With the help of training providers, I was able to prepare for my PMP exam in an efficient manner.

All projects need a schedule. If we have a small project then excel spreadsheet is enough to schedule everything. As projects are larger then we need more formal scheduling templates and tools like Replicon's roster software - http://www.replicon.com/olp/rostering-software.aspx .

It helps to review the schedule on a weekly basis and can identify activities that have been completed during the previous week and update the schedule to show they are finished.

Add new comment