So you think you can dance be a project manager?
Project Management is something I have always been passionate about. After working in project management for several years, I got my Project Management Professional (PMP) certification, thinking it would make me a better PM. Part of what attracted me to the discipline was that it was more of an art than a science (meaning no one could tell me I was doing it wrong!). Project management is something everyone applies everyday in all aspects of daily life. Whether it is a full-time stay-at-home soccer dad of three, juggling laundry, cooking, soccer practice, ballet recitals and a sliver of a social life, or the president’s chief-of-staff, project management is diverse yet universal.
Sidenote – I do find it interesting when I am on campus interviewing college students and an undergrad with a couple of internships under his or her belt tells me they want to be a project manager right out of school and how they are great at motivating teams and people. Hopefully this does not offend anyone, but that is not going to happen. You may come out of school and work as a task master or a project coordinator but you will not be a project manager (at least not on any project I have anything to do with!).
After working with many Project Managers throughout my career, I have noticed this: there are very few good ones. Most project managers are what I call task masters. Traditional PMs are very good at consolidating a list of things that need to be completed, sticking dates on that list (normally asking their team for what the dates should be), and then tracking percent completion. It’s no wonder PMs get a bad rap – most of them are telling developers what time it is with the watch on a developer’s hand!
Traditional project managers absolve themselves from the responsibility of ascertaining the tasks that need to be done, when the tasks need to be done, and removing road blocks along the way. This is because many project managers have no domain knowledge. What I mean is that they did not come up through the ranks of delivering the same solution that they are now responsible for PMing. For example, if you are a PM for a systems development project, you should have some experience being a developer in a past life and still know enough about current development methodologies to adapt your approach to new frameworks. There are a few exceptions to this rule but these exceptions are people that are extremely bright and extremely passionate about the solution they are delivering. These people that may not have development backgrounds, have spent the time to understand development frameworks and can build relationships / earn the respect of a development team.
A typical project at a typical company goes something like the following: a project manager is assigned from the project management group or the Project Management Office (PMO). The project manager is given a set of people to work on the project (in most matrix organizations none of these people report directly to the PM). Then the PM schedules lots of meetings. A meeting to kick-off the project, A meeting to create a project plan, a meeting to create dates, daily or weekly meetings to track progress, weekly team status meetings, bi-weekly steering committee meetings, and the list goes on and on. Keep in mind, the PM is probably not doing much in these meetings other than documenting minutes and asking for how far along Johnny is in creating a certain widget. The more meetings a PM schedules the more wary you should be if you are on their team. The PM will also start to “manage” a stack of documents. These may be on a SharePoint site or a series of Office documents. Things like requirements documents, status reports, project plans, issue trackers, risk registers, communication plans, and a number of other random documents you can find in the PMBOK (no disrespect to the PMBOK but like anything else it is a framework, use what works for you, not EVERYTHING!). Again, the more documents the PM decides the project needs, the more wary you should be.
I do think when a team hits a certain size (maybe 8 or so) the team needs a dedicated task master. However, all teams need a PM. So you might be thinking, “What is the difference between a PM and a task master on a large team?” The PM is not someone whose full time job is the glorious title of Project Manager. They must bring some other domain knowledge. Maybe they are technical enough to take on some architecture or construction responsibility. Maybe they are good at creating requirements the customer did not think of or at testing the end product. The PM must do more than just run meetings and manage project related artifacts. They must remove roadblocks and serve as a facilitator to get the project done. In our complex world, teams often get stuck. Not because they don’t have the technical know how to get something done but more often because someone in another division is stalling on a decision or because a certain DBA will not give the team access to a certain database. A taskmaster will simply log these on the issue register and escalate to people that can hopefully remove the roadblock. A true PM will get the roadblock removed and make a new DBA friend along the way.
The next time your organization interviews a PM for a role or consulting opportunity take the time to learn if the person is truly a PM or a taskmaster. But before you conduct the interview, think about what type of person you need. There are appropriate times when you will need each, but my guess is you will be able to use a true PM in both roles where a taskmaster will only be able to operate as a taskmaster.
At Solvegy, we believe traditional project management is dead. Gone are the days of running a project in a silo with little or no dependency / impact on other projects or the operations of the business. You can read more about our program and project integration practice here. Please do not hesitate to contact us with any questions or comments.
– Dipesh Patel
