Leam HallPM Apprentice| Smartronix/DoDPulaski, Va, United States
So I'm in a software project that needs a Proof of concept fairly soon. As my formal PM skills are growing it takes me longer to write the documents, make the decisions, etc. I'm willing to bill fewer hours since I'm gaining great experience along the way, but I don't know what is a "reasonable" percentage of hours for the project management overhead. Thoughts?
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
What's your approach to the project? Is it a waterfall SDLC or are you going with more of a lean and/or agile approach? Saving Changes...
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
If you want to throw out any specifics I'll be happy to comment and share my thoughts. I'm sure many more will too. Saving Changes...
Leam HallPM Apprentice| Smartronix/DoDPulaski, Va, United States
Hey Josh, thanks! A lot of the details don't belong to me but the basics are to build a database to store federal required data, build/configure reporting tool, write software interfaces to at least two proprietary node types, and provide long term support, maintenance, and upgrades/changes.
Does that give enough information to provide feedback?
Thanks! Saving Changes...
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
I see. I think there are two things to start with and get very, very clear about before proceeding further.
1. Identify your end users and sponsor (one sponsor) very, very clearly. In my experience shifting priorities and requirements has a lot to do with a revolving door of 'who's my sponsor this week' and the like. At the PM sometimes you have to push for this, make it clear to management that unless you have a consistent sponsor and end user to work with, it's like herding cats. Many times there are categories of end user too, if they interact with the system differently be sure to identify these separate roles.
2. Only after you know exactly who your customer is, make the requirements clear. Personally, I like visuals whenever possible. Use Case diagrams have been very useful to me, both for understanding how systems need to interface and how the users need to interface with the system. You don't need to get crazy with proper UML, just sit down with your end users and make pictures that clearly describe the desired functionality! (You'll probably be able to put block diagrams or whatever that describes the internal workings of the system without an end user once you've understood their needs).
Limit the documentation as much as possible. I see many project managers that fall into the trap of believing (or acting as if they believe) documentation IS the project. It's not of course. If I were in your shoes, I would only focus on documentation that very clearly adds value (a list of key stakeholders, the use case diagrams / requirements, one-page or less weekly status reports) and those I would make as short as possible.
I think a PM Plan in the way I do it (it's really a PM approach doc that can be applied to many projects, doesn't contain schedule, cost, etc) is a good idea too, but that's something you may want to do on your own time because the customer may not see the value in it. The PM Plan to me would include a description of what I've said above if that's what you adopt. The PM Plan describes HOW the project will run, the ground rules and standard practices.
You can organize the PM Plan using the PMBOK knowledge areas if you like. Just note that when you are in the schedule section for instance, you don't plop your schedule into the document. You describe HOW schedule is handled on your project. If you will use waterfall or agile, say so and how. When you start a new project, you can simply make revisions to the prior version to customize it to the new project. If the PM Plan is more than 5 pages on a small project, you are probably adding fluff to it. Clear and direct, to the point. A sentence which doesn't add direct value should be removed.
WIth documentation (and everything else) always ask yourself "Does this add value? How and to whom?"
Wayne MackRetired| RetiredSouth Riding, Va, United States
You bill 100% of the time you spend. This is reality. If you work on a US Federal government contract, it is required by law. Bill the hours you work. Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
Leam,
Some good informaiton here but they do not seem so answer the question I think you are asking. " what is a "reasonable" percentage of hours"
Base you PM effort on the other activities total project estimate (without PM).
If you have an efficient PM process as Josh is suggesting you should have, then anything around the 12-15% of the delivery effort.
If you are in a company/business that has "over" implemented...let's say Prince 2 then you are likely to need to build in 15-20%.
You could calculate the effort you need to PM on known activities you may have like writing reports, doing presentations, holding customer project status meetings as these can be set values (e.g. 1hour long) and you can multiply this with the duration of the project to give you more accurate figures for those elements.
You could also calculate the documentation depending on the method (e.g. Prince 2) and how you have it implemented. A page of A4 can take approx 10-20 minutes if you have the data to transfer in easily, but if you have to keep going off/searching for informaiton then estimate 30-40 minutes per page of A4 (full page - so if you have a 2 page PID and page 1 has headers/footrers etc then you are looking at 1-1.5 pages of writing max.)
This then leaves you with the unknown size of the remaining elements - Risk management, Issue Management. If you are able to calculate a lot of the above then use the lower % value.
I think that Peter Wright gave you the most direct advice when he told you to base your time estimates on delivery effort of your team plus allowance for the rigor of your own processes.
Perhaps, more simply, your real work comes in managing people, not reporting on what they accomplished. Most armed forces have learned that the span of control for a leader is 8 to 10 people. I lean toward the lower end, so if you directly manage the efforts of 8 people, you will have found a full time job.
Norm Saving Changes...
Andrew CotterellTransformation Manager| World Intellectual Property OrganisationGeneva, Switzerland
I agree with Norman - I normally calculate PM effort as a percentage of the people actively engaged on the project. For pure software development you can base it on a percentage of development effort, but if you are building and delivering something that includes business change you have to include key stakeholders in your count of people to manage.
This calculation of effort, however, only relates to the running of the project when it is fully mobilised. As a PM you often have to perform the bulk of the mobilisation tasks (PID preparation etc.) so more of your time is needed at the start of the project.
Andy Saving Changes...
Leam HallPM Apprentice| Smartronix/DoDPulaski, Va, United States
All, you have provided some great ideas and thinking material. The client seems to want project management but not be used to it in an established sense. While waterfall might provide a smooth transition I think agile would provide more responsiveness to their short and long term needs.
What I amplanning on doing at the moment is to bring as much clarity into the project as I can. That suggests my hours will primarily be used up front. As this is a fairly small project with 2-4 week targets I think my own work will be minimal but key to keep things clear.
I think the real answer here is none - zero - zilch. I refer you back to your original question where you want to know about a reasonable % of PM >>>overhead<<<. Doesn't matter if it's large or small, in the ideal world they wouldn't need us to manage their projects. Unfortunately the world is far from ideal, and so we will have a job for some time to come. But in this wacky world we need to move away from being overhead, and towards being enablers for our teams to deliver value!
If/when you believe in this viewpoint ... work it backwards to figure out what in our PM toolkit is going to help those who deliver value to the customer succeed at what they do.
Now I know you and others may bash me for giving such a vague answer. However, that is exactly what my point is ... there is no answer anyone is going to be able to give you ... that will provide the right answer with any certainty. Look at your organization, project, etc and figure out the right answer for yourself. I've seen too many PMs fill the time available to them with non-valuable work. Don't fall into this trap! Saving Changes...
