Leadership

Make time for these four hidden areas in your project estimate

Some areas you need to consider in a project estimate stay hidden until the project actually starts. Here's how to uncover them at the outset.

Most people understand they have to try to uncover all the executable work in a project estimate. The problem is, some areas are hidden at first. It is only after you start the project that you begin to see their impact. These areas include:

Project meetings. Meetings that are project-related should be included in the workplan and should be added to the estimated effort of the project. This is because meetings of this type are within the control of the project team. You should allocate time every week for a project status meeting, and in some cases you will have multiple meetings. If you have eight people on your team, you need to account for eight effort hours in your estimate for each team meeting you schedule.

Team collaboration. Try to account for the total time required for all participants in any collaborative project-related meetings. For instance, if you're planning deliverable walkthroughs, you might allocate one hour for the meeting. However, remember that if there are three people at the review meeting, you should allocate three hours to each occurrence. Likewise, when you're circulating documents for approval, include some review time for each person you think will be involved. Many project managers include an hour for a document review. They forget that a document might be circulated to five people for their review and feedback. You must make sure that you allocate the full time for all the team members that are involved.

Project management. This refers to the effort required to successfully and proactively manage a project. This time includes planning the work, managing the schedule, managing scope, communicating effectively, etc. A good rule of thumb is to add 15% of the effort hours for project management. For instance, if a project estimate is 10,000 hours, the project management time is 1,500 hours. If the project estimate is 1,000 hours, the project management time would be 150 hours.

Client time. Client effort includes the time to review and approve deliverables, provide requirements, attend meetings, participate in training, etc. Some companies want to understand the total effort and cost of a project, including both the direct project team and the client resource requirements. In other companies, the project costs only include the direct project team. Whether you include client hours and cost in your estimate is an area you should discuss with your manager and your sponsor. If your project estimate includes client hours and cost, the hours need to be kept separately. You might be surprised how many projects would get delayed if your sponsor better understood the effort and costs required from the client side in addition to the time and cost associated with the direct project team.

12 comments
meryllogue
meryllogue

I do two things: 1) During our working sessions (whether they be meetings or email), I ask for the most realistic timeframe in which they can deliver. I confirm with the others that it will also work for them, given their piece of the project. Once we have agreed, I ask everyone to be sure to email asap (EARLY) if anything comes up to impact that. If it is important enough (hard stops in the schedule) I also set ticklers in my task manager (Outlook) to remind me to check up on it several days in advance. 2) I imnmediately follow up every meeting with notes of that meeting, with a section labeled "Action items/owners" (bolded subhead, of course) which spells out all the action items, their owners, and the agreed-upon date for delivery. I also ask for feedback on any misinterpretations. I have found this to work extremely well in our environment. Only occassionally have I had a consistent problem with delivery, and with this sort of documentation in hand, after the third missed deliverable it is easy to go to their superior and get them replaced. My approach is, "He/She is obviously over-taxed in daily activities. Can we have someone with a little more time available to us?" It (mostly) works beautifully.

chriskfau
chriskfau

The stakeholders or clients will most likely find the project team as 'calculative' or 'petty', if these hidden areas were taken into account. In addition, it doesn't really help in a situation when you have to cut cost and time to deliver a project.

cln
cln

It is best not to have hidden areas. Hidden areas add cost/time and are more likely to upset clients and stakeholders.

tom.krajnc
tom.krajnc

In our projects, we have always considered these areas. However, we have always inserted another area; communication protocols, where we have specified time frames for responses for different documents or products (meeting minutes, demands verification, quality checkups ...). It has proven to be highly effective while all participants were obliged to follow rules which they have confirmed

cln
cln

Thanks everyone for the added info.

simeon.paraschakis
simeon.paraschakis

It is nice to discuss the problems. But what about the solution? According my own experience the use of forms makes the hole work much easier. But do anybody esp.Tom has any useful forms or other tools we could also use in our daily work? For ex. can you Tom write about your timeframes etc? With kind regards/Simeon P.

artful
artful

I agree 100%. I have wasted lots of time in my career, waiting for people to read documents and sign off, waiting for people to test software, waiting for people to point out inaccuracies or awkward UI sequences. Eventually I learned that the only good way to get the stakeholders to do their part was to give them deadlines, beyond which everything I did was assumed correct and every fix was extra-billed. This might sound cruel, but I have not yet come up with a better motivator to get the stakeholders to do their half of the job. Arthur

guillenkma
guillenkma

TOTALLY concur, this method works!!! Eventually I learned that the only good way to get the stakeholders to do their part was to give them deadlines, beyond which everything I did was assumed correct and every fix was extra-billed. This might sound cruel, but I have not yet come up with a better motivator to get the stakeholders to do their half of the job.

johnolson
johnolson

A very good point. I would like to highlight and expand upone the importance of giving deadlines to stakeholders. Sometimes the selection of the deadline date is just as important as giving a deadline. Even when we give deadlines, we can still have issues with people waiting until the last minute to meet the deadline. Many times this has to do with the selection of the deadline date. For Example: Lets say we are asking the stakeholder to test and approve software before it's implimentation. If the scheduled time for the implimentation is Saturday morning, to many people give deadlines that the stakeholder's testing and approval should be completed by the end of Friday. Then we have the nerve to get angry when the stakeholder has not started testing until Friday afternoon because the team will not have enough time to fix any issues they find before implimentation. In this scenario, we have the nerve to say we were delayed by the stakeholder. In reality they were doing exactly what we asked for. Instead, we should be looking to select deadlines that give enough time for follow up work. This should help to better communicate when we need the stakeholder to complete thier work in a manner that will keep the project on schedule. -John Olson

artful
artful

You have hit the nail squarely on the head, Ernie. Clients and stakeholders all too often have the habit of assuming they must do nothing until the software is perfect. A clause such as the one you suggest may nudge them into a closer relationship with reality, and if not, then at least it CYA. Arthur

ernie.burgess
ernie.burgess

Where feedback/comment is requested from stakeholders who are notoriously slow to reply, make sure the deadline is clearly described in the e-mail, then just before your signature, add a statement something like: ?Lack of response by the due date signifies agreement with the contents of this e-mail and its attachments.? Works a treat. Just make sure they aren?t out-of-office for the period! (in which case they should have set up an auto-response anyway) The first time you do this, some eyebrows will jiggle up & down a bit ? usually the worst offenders ? but they soon get the hang of it.

pmaina2000
pmaina2000

Deadlines with buffers. A different version would be stagepoint deadlines. If you need them to test the app, ask for test results at each stage (e.g. as each module is stested). If you want a document reviewed and approved, set a deadline for "feedback / comments" followed by a signoff meeting "deadline" immediately after. The signoff meeting will probably become the "feedback / review" meeting (which is what you really wanted) during which you can agree on the real signoff date.

Editor's Picks