Ryan Sloan

January 11th, I will begin my next adventure at Georgia Tech. I’m not really talking about Spring Semester 2010, which should be another chapter of Georgia Tech life. I’m referring to the fact that I will be embarking on my first adventure in project management. As the Information Technology chair for Georgia Tech’s Student Government Association I have a variety of responsibilities. Until this time, most of those responsibilities involved adding/modifying content on SGA’s website (and sitting in a lot of meetings, of course.) Next semester my committee is going to undertake a comprehensive rewrite of Course Critique. Course Critique provides grade distributions and survey information for every course offered at Georgia Tech. Unfortunately, the current incarnation is prone to outages (particularly during registration periods) and several portions of it are not functional at all (namely the mechanism that uploads and processes grade distribution and survey info — a critical component.) After assessing the code base, I decided it was best to begin a complete rewrite. But this time we are going to do it right.

Even though this project doesn’t officially begin until January 11th, I am using what little spare time I have had over the winter holiday to begin what is arguably the most boring phase: requirements gathering and specification. While this may not be the most interesting phase, I really believe that it is one of the most critical (if not the most critical.) Proper design and documentation will (hopefully) prevent this project from going the way of its predecessor.

I titled this post “An Unlikely Project Manager” because until recently (like, really really recently) I saw myself as a software developer. I figured I’d be a developer forever, which I was sort of ok with. It was in the past year when people started suggesting that I could combine my technical skills with my skills as a communicator and bring balance to the force (Hopefully it goes better for me than it did for the Jedi.) This is my first opportunity to get my feet wet and see how good I really am at this whole “management” thing.

In an effort to avoid becoming a pointy-haired boss, I am going to be doing as little managing of people as possible. I’m going into this experience with three key ideas/quotes:

1. Management is taking out the trash.
2. “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” — George S. Patton
3. “In preparing for battle, I have always found that plans are useless but planning is indispensable.” — Dwight D. Eisenhower

Management is taking out the trash

I wish I could remember where I heard this quote, but I searched for a long time and couldn’t find it anywhere. (Maybe I invented it? Unlikely.) Regardless of its origin, this statement captures what I believe (and remember, I’m a college student who hasn’t done any professional managing) is a key idea in project management. I will be doing little-to-no coding on this project. Instead I’m relying on the ingenuity of my team. My primary purpose will be to remove obstacles from their paths. I’ll be doing most of the preliminary planning, communicating with third parties, initially setting up their environment (issue tracking, source control, etc.) and all the other boring stuff. I guess what I’m getting at is that you should let them do what they’re good at, and don’t bother them with the other stuff. Sometimes that means taking the can out to the curb.

“Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”

Patton was dead on here. As I mentioned before, I will be doing almost no programming. I’m ok with that, but it’s important that I avoid the micromanagement trap. This project will be fairly large, and there is no way for me to have my hands in everything. I picked this team because I felt they were capable, and I think they can put together some great software without being pestered. This isn’t a promise that I won’t offer my opinion, of course, I just want them to argue with me when they disagree. I’ll probably cave.

“In preparing for battle, I have always found that plans are useless but planning is indispensable.”

Well, people liked Ike. I thought if I included a quote from him people would like me, too.

In all seriousness, I think this is one of my favorite quotes. Not just as it relates to software engineering or project management, but in general I think it’s a pretty solid guideline. I am going to make sure that my team is given a complete and clear requirements document as well as functional specification. We’ll be laying out a schedule of milestones with target dates. And in spite of all this, approximately one week into the project we’ll realize we’re behind/the requirements have changed/there is no spoon. But that’s ok. It happens. Things will almost certainly not go according to plan, but thorough planning will give us a deeper understanding of the problem, making it easier for us to adapt to change. We can’t realistically count on meeting all our deadlines, or the server setup working just the way we would like it to. People will get sick, or become overwhelmed with school. There’s really no way to know what’s going to happen when we embark on our first sprint. Adaptation is the key to a successful operation. So we’ll adapt.

Here we go…

So I’ll be keeping those three things in mind as I start this adventure. I’m planning to use this blog to chronicle the progress of the project (partially as a personal record, and partially because it seems like a good way to generate some content and discussion.) Wish me luck!