Estimating project work for individual tasks or groups of tasks can be difficult – and it’s important to rely on the project team to either help with estimates or produce the initial estimates that you, as the project manager, then review and document. Is there a sure fire rule of thumb to project estimating? No way. Everyone bases their estimates on guesses, past experiences, and the advice of others…but nothing is perfect and no estimation will ever be 100% dead on…unless it’s by luck.
I do, however, think some people are much better at it than others. I’m of the opinion that estimating is more of a gift – you either have it or you don’t. It’s that ability to think somewhat abstractly on given tasks and figure out with some degree of accuracy what the level of effort will be. Of course, there needs to be a certain level of experience and expertise – but that experience does not always ensure that you’ll give good estimates. Over time, one can learn to be a good estimator, but it helps to have that gift.
From my experience, there are some key weaknesses or traps we can fall into when trying to produce good estimates. Being aware of these in advance can help the PM and team to avoid them, but it still won’t guarantee that you’re producing an accurate estimate. I’ve come up with a list of five that I think are the most common…



Projects are important. If they weren’t they wouldn’t be ‘projects’ and you and I would not have jobs. But they are important, they are necessary, and someone experienced needs to lead them. But they are not and never will be an art form. Let me explain.
Can you really start a project without requirements? I know I certainly don’t feel comfortable – even for a short project – starting a project and trying to manage scope without detailed requirements in place for the project. Requirements are key – they are the lifeblood of the project. If you try to build an end solution with only high-level requirements, it won’t work. If you try to deliver something to the end user with knowing what they really need the system to perform – what they require of this solution you are providing them with – you may be delivering something they can’t even use. If you haven’t worked with the customer’s subject matter experts (SMEs) and end users to know what the problem is and what they need, then you have no scope to start from…everything is really just a best guess. And that’s a bad situation – for everyone – but mostly for the project manager and team who will be on the hook to deliver a workable end solution. And it just won’t happen.


I’ve always made it clear that communication is – in my opinion – the most important thing the project manager does on a daily basis. Everything they do is important, but without good communication skills the project has no real hope for success. Unfortunately, the project manager could be the best communicator in the world, but weak links in their network and with communication on the project overall could still cause problems for the project and key stakeholders.
In
Being a Project Management practitioner is a choice many of us have willingly made (and enjoy!). Others may have joined the ranks due to necessity from their previous role being eliminated, outsourced or some other form of extinction. Regardless of our past experiences we’ve all made our share of mistakes and all have a unique relationship with the term “Lessons Learned”. In this article I share some of the lessons I learned the hard way. We can read as many books as we want, interview everyone we’ve ever known and read every Google article that exists on the topic of how to be a strong, influential and creative type person so we can thrive in the Project Management environment but nothing can truly replace being in the hot seat. Here are a few things I hope make sense to those either in the role already or thinking about taking on the role.
