How much time does a project manager spend on the "red tape" of project management?
May 16, 2008 9:54 AM Subscribe
How much time does a project manager spend on the "red tape" of project management, rather than on the work of the project itself?
Are there studies out there that show that a project manager spends x percent of his/her time on the administrative management of the project (scheduling, risks and issue management etc) versus sitting in on design meetings etc. I'm talking about IT project management here, and realise that the figures will vary depending on complexity/size of project and experience of the PM concerned.
Are there studies out there that show that a project manager spends x percent of his/her time on the administrative management of the project (scheduling, risks and issue management etc) versus sitting in on design meetings etc. I'm talking about IT project management here, and realise that the figures will vary depending on complexity/size of project and experience of the PM concerned.
Depends on the company. I've never been a PM, but I have worked with many.
Good project managers, imho, spend their time doing whatever it takes to keep the engineers on task. Which means intercepting randomizing questions and input from managment, playing the political game, running interference and making sure the engineers have the resources they need to do what they need to do.
If, after all that, there is time left PMs can help design and architect things.
posted by jeffamaphone at 10:12 AM on May 16, 2008
Good project managers, imho, spend their time doing whatever it takes to keep the engineers on task. Which means intercepting randomizing questions and input from managment, playing the political game, running interference and making sure the engineers have the resources they need to do what they need to do.
If, after all that, there is time left PMs can help design and architect things.
posted by jeffamaphone at 10:12 AM on May 16, 2008
It varies strongly by industry, project type, etc... some projects involve craploads of meetings and some involve craploads of cat herding (yes, I've been a PM)...
Are you looking for some sort of average figures? Or are you looking because you're curious about a job or project you're going to take on?
posted by twiggy at 11:12 AM on May 16, 2008
Are you looking for some sort of average figures? Or are you looking because you're curious about a job or project you're going to take on?
posted by twiggy at 11:12 AM on May 16, 2008
IAAPM! Wooo!
The duties of a PM vary quite a bit from company to company and even from project to project. While my particular position is much more heavily weighted towards the administrative management side of things in general, often projects come along where it's closer to a 50/50 split, or even slightly favors the design end of things.
I can't point you towards any definitive studies on this sort of thing, and I'd be inclined to assume that none exist, so varied is the landscape. If it's any help, the PMBOK (Project Manager Body of Knowledge, essentially the PM Bible) is unapologetically 100% about the administrative side of things. To that end, I think the role of the PM, on paper, is concentrated on these tasks.
Luckily, at least in my experience, nobody silos their departments this badly. Our website (Internet Retailer Top 100) is essentially driven by three departments: Graphics, MIS, and Direct Marketing. We all work very, very closely together, and the lines of who does what are often rather blurred. As such, when we have kickoff meetings for new projects, anybody in the room is allowed and encouraged to speak on any aspect of things where they believe they can be of assistance. I would never present myself as an authority on the detail work that MIS and Graphics does, but it's important that I'm familiar enough with what goes on so that I can answer questions for anyone else in the company.
And that, truly, is the part of the job they don't advertise much. You end up becoming the spokesperson for all internal inquiries and requests. I spend the vast majority of my time on the phone and on email answering questions, politely explaining why requested features can't appear instantly on the site if at all, and organizing and presenting information for higher level meetings.
It might sound like hell, but I really enjoy it. It allows me to get a taste of every department within the company, and I know how much easier it makes life for the Graphics and MIS people. It took me some time to accept the limits of my position (Example: MIS is bogged down to hell, we have new product copy, they don't have time to do it right now, I do, and I have the skills, but it's not in my job description, so I can't do it.) and it's not at all what I expected it to be, but if you're got a large body of general knowledge for the technologies that drive the projects of the company you work for, you're well organized, and you don't mind schmoozing a bit with the suits, PMing is awesome.
If you're looking for a written account of what a PM position is really like, I'd highly recommend Scott Berkun's "The Art of Project Management." It's out of print, but shouldn't be too hard to find. If it is, it has been retitled "Making Things Happen: Mastering Project Management" I haven't read the new edition, but I imagine it's quite good.
Anyway, I realize this was much broader than the scope of your question, but I hope it helped. Feel free to MeFiMail me if you want to ask a follow-up.
posted by SpiffyRob at 11:50 AM on May 16, 2008 [2 favorites]
The duties of a PM vary quite a bit from company to company and even from project to project. While my particular position is much more heavily weighted towards the administrative management side of things in general, often projects come along where it's closer to a 50/50 split, or even slightly favors the design end of things.
I can't point you towards any definitive studies on this sort of thing, and I'd be inclined to assume that none exist, so varied is the landscape. If it's any help, the PMBOK (Project Manager Body of Knowledge, essentially the PM Bible) is unapologetically 100% about the administrative side of things. To that end, I think the role of the PM, on paper, is concentrated on these tasks.
Luckily, at least in my experience, nobody silos their departments this badly. Our website (Internet Retailer Top 100) is essentially driven by three departments: Graphics, MIS, and Direct Marketing. We all work very, very closely together, and the lines of who does what are often rather blurred. As such, when we have kickoff meetings for new projects, anybody in the room is allowed and encouraged to speak on any aspect of things where they believe they can be of assistance. I would never present myself as an authority on the detail work that MIS and Graphics does, but it's important that I'm familiar enough with what goes on so that I can answer questions for anyone else in the company.
And that, truly, is the part of the job they don't advertise much. You end up becoming the spokesperson for all internal inquiries and requests. I spend the vast majority of my time on the phone and on email answering questions, politely explaining why requested features can't appear instantly on the site if at all, and organizing and presenting information for higher level meetings.
It might sound like hell, but I really enjoy it. It allows me to get a taste of every department within the company, and I know how much easier it makes life for the Graphics and MIS people. It took me some time to accept the limits of my position (Example: MIS is bogged down to hell, we have new product copy, they don't have time to do it right now, I do, and I have the skills, but it's not in my job description, so I can't do it.) and it's not at all what I expected it to be, but if you're got a large body of general knowledge for the technologies that drive the projects of the company you work for, you're well organized, and you don't mind schmoozing a bit with the suits, PMing is awesome.
If you're looking for a written account of what a PM position is really like, I'd highly recommend Scott Berkun's "The Art of Project Management." It's out of print, but shouldn't be too hard to find. If it is, it has been retitled "Making Things Happen: Mastering Project Management" I haven't read the new edition, but I imagine it's quite good.
Anyway, I realize this was much broader than the scope of your question, but I hope it helped. Feel free to MeFiMail me if you want to ask a follow-up.
posted by SpiffyRob at 11:50 AM on May 16, 2008 [2 favorites]
Response by poster: Thanks for the answers so far.
Twiggy "Are you looking for some sort of average figures?"
That exactly captures what I was looking for.
Also, I should have prefaced by saying I am an experienced PM (certified and all - woo!) and have looked in some of the obvious places for the answer to this. But - as I suspected - the variables of industry/experience/complexity of project may mean that there is no hard and fast baseline for this.
Keep 'em coming, thanks.
posted by Nick Verstayne at 12:27 PM on May 16, 2008
Twiggy "Are you looking for some sort of average figures?"
That exactly captures what I was looking for.
Also, I should have prefaced by saying I am an experienced PM (certified and all - woo!) and have looked in some of the obvious places for the answer to this. But - as I suspected - the variables of industry/experience/complexity of project may mean that there is no hard and fast baseline for this.
Keep 'em coming, thanks.
posted by Nick Verstayne at 12:27 PM on May 16, 2008
It really depends on the size and complexity of the project, the degree to which the system develops leading-edge technology applications -- and on the culture of the company. If by "the work of the project itself" you mean software design and development, then in small projects (fewer than 8-10 people), you could easily spend 80% of your time on this. The real deal is that what we typically call "project management" (estimation, scheduling, resource allocation, and activity tracking) is only a small part of the work of a project manager.
As an ex-PM, one of my major jobs was to get the developers together regularly, so that we could walk through design assumptions and make sure that we were all interpreting the spec. in the same way. Another job was to make sure that individual team members were using appropriate design methods and actually writing things down occasionally(!). I have worked in a lot of different companies. Even though most have accepted methods and modeling techniques that they use, systems development tends to be (barely) controlled anarchy. As SpiffyRob says, liaison with other departments takes up a lot of time: clients, senior managers, and IT support groups all want to discuss stuff frequently. I'd agree with him and say about 50%/50% on admin/development activities where the spec. is less clear.
I worked on real-time networking or engineering systems, rather than more standardized environments like web development, so this affected the management/control activities a lot. There were days (and projects) when I would spend all of my time on the phone, trying to sort out problems (the hardware platform was redesigned without anyone telling us so the testbed did not work to spec., we needed to debug the cross-compiler that we were using, the 'multi-user' software library wasn't ... that sort of thing). Then there was the client call, two weeks before we went live: "Oh, by the way, we just realized that we were a factor of 10 out, in our calculation of the required response time." So if you count those as "the work of the project itself," then 80/20. If you count those as management activities (someone has to sort things out and occasionally kick a$$ to make life tolerable for the development team), then 50/50 - at least.
If you want some figures, you could try combing around USC's COCOMO II website. Barry Boehm has written a lot of discussion papers on this type of topic.
posted by Susurration at 12:48 PM on May 16, 2008
As an ex-PM, one of my major jobs was to get the developers together regularly, so that we could walk through design assumptions and make sure that we were all interpreting the spec. in the same way. Another job was to make sure that individual team members were using appropriate design methods and actually writing things down occasionally(!). I have worked in a lot of different companies. Even though most have accepted methods and modeling techniques that they use, systems development tends to be (barely) controlled anarchy. As SpiffyRob says, liaison with other departments takes up a lot of time: clients, senior managers, and IT support groups all want to discuss stuff frequently. I'd agree with him and say about 50%/50% on admin/development activities where the spec. is less clear.
I worked on real-time networking or engineering systems, rather than more standardized environments like web development, so this affected the management/control activities a lot. There were days (and projects) when I would spend all of my time on the phone, trying to sort out problems (the hardware platform was redesigned without anyone telling us so the testbed did not work to spec., we needed to debug the cross-compiler that we were using, the 'multi-user' software library wasn't ... that sort of thing). Then there was the client call, two weeks before we went live: "Oh, by the way, we just realized that we were a factor of 10 out, in our calculation of the required response time." So if you count those as "the work of the project itself," then 80/20. If you count those as management activities (someone has to sort things out and occasionally kick a$$ to make life tolerable for the development team), then 50/50 - at least.
If you want some figures, you could try combing around USC's COCOMO II website. Barry Boehm has written a lot of discussion papers on this type of topic.
posted by Susurration at 12:48 PM on May 16, 2008
I too am a PM. I strongly doubt that you're going to find hard and fast numbers around this, because every project is different - depends on the type of project, how you've staffed it, client considerations, management policies / strategies / tactics, technical complexity, and a myriad of other complications.
On my projects - typically systems designs for Supply Chain Management implementations, I've found that I typically doing at least 50% of my time on actual PM activities.
Also, by way of note, you should be careful not to lump project management tasks with program management. Most of the projects I've worked on have been part of larger and more comprehensive programs, and those typically have at least someone, hopefully a whole office, dedicated to Program Management (we call them the PMO). Project Management, while closely related, is a completely separate entity.
posted by allkindsoftime at 1:01 PM on May 16, 2008
On my projects - typically systems designs for Supply Chain Management implementations, I've found that I typically doing at least 50% of my time on actual PM activities.
Also, by way of note, you should be careful not to lump project management tasks with program management. Most of the projects I've worked on have been part of larger and more comprehensive programs, and those typically have at least someone, hopefully a whole office, dedicated to Program Management (we call them the PMO). Project Management, while closely related, is a completely separate entity.
posted by allkindsoftime at 1:01 PM on May 16, 2008
Another PM chiming in here - I work in the IT Consulting field. I have to estimate these kinds of percentages every time I do a proposal and submit an initial project timeframe to the client (since the PM billable rate is higher than the developer's, DB admin's, designer's, etc.).
Totally agree that the percentages will change depending on how many unknowns there are. Many of my previous projects required a lot of PM involvement - the more people/departments involved, the more likely things will start going off track and require that I step in and re-align the project scope and priorities. On those kinds of projects, the PM time can be around 60-70% of the project billing. However, some of my recent stuff has been web development on theRoR platform, and the reduced amount of unknowns and relative simplicity of the project makes it much easier to structure. So I'm not sure if this will help you at all, but here's an example time breakdown for a typical RoR development project:
5% Requirements Analysis (All PM time)
10% PM Administrative Tasks (incl. meetings, status reports, getting client sign-off, etc.)
25% Design
45% Development
3% Launch (PM and developer time to coordinate project launch)
2% Training and cutover
posted by krippledkonscious at 4:23 PM on May 16, 2008
Totally agree that the percentages will change depending on how many unknowns there are. Many of my previous projects required a lot of PM involvement - the more people/departments involved, the more likely things will start going off track and require that I step in and re-align the project scope and priorities. On those kinds of projects, the PM time can be around 60-70% of the project billing. However, some of my recent stuff has been web development on the
5% Requirements Analysis (All PM time)
10% PM Administrative Tasks (incl. meetings, status reports, getting client sign-off, etc.)
25% Design
45% Development
3% Launch (PM and developer time to coordinate project launch)
2% Training and cutover
posted by krippledkonscious at 4:23 PM on May 16, 2008
Response by poster: Again - Thanks to all for the responses. I've found them all helpful, but as I suspected, there are no hard facts to be garnered in this field due to all the variables. Cheers.
posted by Nick Verstayne at 6:41 PM on May 17, 2008
posted by Nick Verstayne at 6:41 PM on May 17, 2008
This thread is closed to new comments.
posted by Nick Verstayne at 9:56 AM on May 16, 2008