12 Basic Principles of Project Management

XXXLast week I attended a two-day training session on the fundamentals of project management. I had been looking forward to the opportunity as a chance to help me be more effective at my current alt-ac job, where I work in a team environment on several very cool projects (a THATCamp, a digital scholarship commons, some library games). Working in a team has been a relatively new experience for me. After all, graduate school—at least in the humanities—doesn’t often teach that skill set. For this reason, I thought it could be useful to share some of my training, in the same way that I did when I learned how to speak to the news media at the most recent MLA. Here, then, are twelve basic things that I learned about working with and leading a team:

  • Projects are temporary. You can’t consider a project to be that thing that you’re going to do every day for the rest of your career. Instead, it’s something that creates a particular product or service, and it has a clear end point. You might compare it to the creation of a syllabus or teaching a course. It has a finite beginning and end.
  • Decide whether or not the project should happen. Not every project should be begun started. When you are beginning work on something, you want to determine if it’s a good use of your resources, what problem the project is trying to solve, and whether or not the project is the best way to fix it. I think that this is particularly hard in universities because we tend to originate our own projects rather than having them brought to us (more on this below). It can be very difficult to admit that what you’ve been wanting to do isn’t worth the time, money, and/or effort. But we have to be willing to call a spade a spade.
  • Consider risks. If you’re going to tackle the project after all, you should analyze your potential risks. What events might derail the project? What are the likelihood of them happening? Working together to brainstorm what these things will help you plan for the events that seem most likely or severe. For example, your entire digital humanities project could be derailed by a server failure. For this reason, you should probably be obsessive about backup.
  • Cost, time, and quality are co-dependent. In other words, once a project has been started, you can’t change its timeline without directly affecting its cost or quality. You can’t expect to get something done faster without either paying more or sacrificing some quality. This is why getting a plumber to your house at 10pm costs more than waiting for the next day. The same thing applies to any project you undertake with a team.
  • Know what’s out of bounds. Determining what your project will not do is just as important as determining what it will since that can help prevent mission creep in the future.
  • Develop a project plan with clear activities. At the beginning of a project, the size or scope of the task might seem overwhelming. (Ask anyone who’s ever tried writing a book!) However, breaking things into small and manageable chunks can help you eat that proverbial elephant. When working on a team, you should have these chunks start with a verb so your team members clearly know what you’re asking them to do.
  • When making assignments, consider people’s interest as much as their skills and experience. Just because someone has a ton of experience designing websites doesn’t mean that it’s the only thing that he wants to do. Letting people choose how they want to be involved in the project allows them to develop personally as well as helping the project.
  • Let the person taking an assignment set the due date. It can be hard to manage a project and not come off as an ogre at times. But one way to shed the Shrek this is to let those who are getting the assignments decide when they can complete them. Their estimates won’t always be 100% accurate, but they will not have the excuse of it being a deadline that is imposed on them. Moreover, getting a team member’s input helps them feel more connected to the project.
  • There are lots of project management tools; just use what works for you. This is pretty self-explanatory and is the subject of this great thread at DHAnswers (see previous ProfHacker coverage here, here, and here). If post-its and emails work for your team, then go for it. If you need to use Basecamp and can get others to do so, that’s fine too. In the end, it’s not the tool so much as the relationships that count for being successful at a project. As our instructor said, “A fool with a tool is still a fool.”
  • There can only be one. In a progressive, neo-liberal environment (read, university), we tend to want to let everyone get involved in decision making. In the end, however, you can’t really share project management duties. One person needs to be chief. But it also doesn’t have to be you all the time.
  • Set meeting ground rules. It’s true that bad meetings are your fault—especially if you’re the project manager. Getting your team to agree collectively to how meetings will work will help things run smoothly in the future. And be sure to only hold meetings when they are necessary.
  • Celebrate success. Since projects are finite, they will have an end…no matter how far off that might seem at present. When you get to this point, make sure that you figure out some way to celebrate the accomplishment. A celebration doesn’t have to cost a lot of money—or any—but recognizing others’ contributions and the completion of the goal is important.

That’s certainly not everything that I learned in 2 days, but I think it’s the key points that I’ll be taking forward with me. A lot of it is common sense, but I’ll be the first to admit that PhDs aren’t always gifted with common sense (otherwise they might not begin the degree in the first place!).

It’s worth mentioning that not everything we covered seemed germane to working in a university. The most important of these is that the concepts of project management (insofar as they were introduced to me) appear linked to doing something for someone else. What I mean by this is that project management is designed to help you meet the needs of a client who comes and asks you for something and who will be judging whether or not you have succeeded. In many ways, then, it’s a form of consulting within a top-down structure.

But in universities, I think, ideas and projects tend to percolate up from individuals. It’s normally a faculty member, graduate student, librarian, or someone else who has an idea, gets working on it, and eventually pulls in a team to help. In this case, the initiator of the project is both the client and the project manager. The distinction between these two types of clients isn’t just academic. (Ahem.) It can be hard, for instance, to create a budget for a project when you are working to put together funding from, say, different campus departments, as I did when I began a lecture series. You create a budget, of course, to show people; but it’s not the same thing as being told by a client that her company can spend $25,000 on project X. So some of the steps and considerations that a project manager working for IBM might make simply don’t translate to the university.

This disjunction between “regular” businesses and universities certainly does not make project management useless. In fact, I’ve got some great ideas. But it is also true that we must adapt these principles so we can better manage team members in our own specific contexts.

To get more particularly at that context, then, what’s the single most important lesson you’ve learned about working in a team or on a project? Please let us know in the comments.

Lead image: Meeting nieuwe leden / Voka Kamer van Koophandel Limburg / CC BY 2.0

Return to Top