Project Mechanics

Project Estimate

Accurately estimating a project's effort, duration, and cost is one of the most challenging tasks for the Project Manager. At the project start, the Project Manager usually develops macro level estimates. As the project progresses, the Work Breakdown Structure (WBS) is refined. A macro level estimate is used for preliminary planning, creating a global view, and determining project feasibility.

I’ve seen people use a flat overhead rate (anywhere between 10-25% depending on what the project sponsor will tolerate) or trying to add PM tasks to the project plan to build in hours (meetings(client and team), status reports, issue management, and other activities).  My off the cuff answer is 20 percent of total effort will be related to managing the project and not doing the work. This varies widely depending on the skills of the team, definition of the work to be done, and effective change management system

Project Esitmating 'rules of thumb'

Minimum 25%

The minimum effort required for project management tasks is 25% (10 Hours per week).  That is the time required for a one-person software development effort.

7 requires 1

Current studies indicate that the maximum number of people that one manager can effectively lead is seven.  Therefore, if you are managing seven people, you should allocate 100% of your time for handling project management tasks.  Ignoring this requirement is one reason why so many software development efforts are so poorly managed.

Smaller Groups

If a project consists of more than seven people, consider breaking it up into smaller groups.  Assign a "lead" that has management responsibility and authority for the group.  Then, use your time to coordinate group efforts, build teams, work with the client, work with management, and plan ahead.


Some common Esimating Mistakes and how to avoid them:


Do not forget to include expenses in your estimates.  Use a successful project as a template to make sure that you list everything you will need.  Have someone audit your spreadsheets to ensure that all lines are totaled properly.  A good guide to ensure that you have included all relevant expenses is the Project Initiation Checklist.


Do not skimp on the contingency estimate.  If you estimate six months plus one month of contingency, quote seven months plus contingency.  The bottom line is nobody is perfect at estimating.  No matter how detailed the estimate, Mr. Murphy will come along to ensure that there are delays and things that were not considered.  The average contingency ranges from 10% on a small project to 30% on larger and riskier projects.

Management Hours/Staff Meetings

Management hours and staff meeting hours are often underestimated.  A weekly two-hour meeting by a five-person team constitutes 40 hours per month.  People tend to cut back on these hours because the estimates look high.  If you want a smaller number, break up the meetings into more discrete tasks performed in the meetings.  There is no way to avoid having the meeting if the project is to stay well managed, so be sure to include the time.       

Proficiency Assumptions

If you have a team of 15, you can assume that 5-7 of your consultants/associates will be inexperienced.  Estimate them to perform at a 50% proficiency level for the 1st three months.

Administrative Time        

Administrative time (i.e. preparing reports, attending meetings, conveying decisions, reviewing surveys, etc…) is often omitted from estimates, yet it is still required.  If a lump sum is inappropriate to show on the WBS, then show the time broken out into discrete tasks.

Supervision Requirements

The time required to supervise employees and monitor their development activities is often grossly underestimated.  This underestimation is particularly acute in the early stages of a project where new consultants/associates require a material amount of supervision to keep on track.

Managers Doing "Real Work"

As projects grow in size, the job of running a project soon takes nearly full time management commitment to managerial tasks.  Do not assume that a Manager can be expected to complete deliverables (creating detailed design documents, programming modules, executing test cases, etc.) while managing the project.  Consider the size and scope of the project along with the corresponding management tasks to determine whether a Project Manager will be able to undertake these “real” tasks.  In any case, the assigning of non-management tasks to the Project Manager should be seen a "red flag". 

Resource Sharing

Assumptions of sharing do not allow for odd numbers of staff.  Remember to round up to whole numbers.  For example, if there are three resources on an out of town project, and one car is allocated for every two staff, two cars will be needed.

Network Access

A common area of misestimating is the assumption that the client has the appropriate network in place for development.  Often the client has unreasonable expectations as to how quickly LAN/network hardware and installation can occur.  If the client's staff is supposed to perform the installation work, be sure to develop a contingency plan to account for delays in this area.

Wrong Development Tool

Often, the wrong tool is used for the basis of estimation (e.g., estimate was based upon Visual Basic, and Visual C++ is required).  This situation occurs whenever the requirements are not fully known at the start.  Be sure to include an assumption specifying the need to potentially re-estimate should there be a substantive change in the development tools.

No Tuning Time

Be sure to include time for tuning.  Often extensive tuning is required as programs are moved out of development and into testing.

No Transition Time

Often, development estimates only include time for personnel to be on site through testing.  However, it is frequently a requirement that some staff be available to assist the client in the transition to the new production system.  If your estimate does not include transition time, be sure make a specific exclusion of such assistance in the Job Arrangement Letter.


The creation of documentation and help text can be very time consuming.  Even if the actual creation of the documentation and help text is not part of the project deliverables, you will need to include time to assist whomever is responsible for its development.  The client will assume that this "assistance" will be minimal and, therefore, will not require specific time allocated to it.  If the client does have this sentiment, make sure to secure a separate time and materials agreement for all time spent "assisting" in the preparation of documentation for the system.


Be sure to document all estimating assumptions specifically listing all exclusions.  Also be sure to explicitly state those items for which the client is responsible.  









Amazon Picks


Find the resources you need to help develop your skills.
Explore The Store