Categories: Project Management
We've all heard the old maxim about what happens to you and me when assumptions are made. Sometimes it's true, and the point is always valid - check your assumptions. If you have even a few years work experience, however, you probably know that checking all your assumptions, before you are expected to act, isn't always feasible.
Assumptions are made all the time, in business. They range from how someone will perform or act, to pricing and demand for a product, to what people know and need to know, to how processes are performed, and lots of places in between. Even when best efforts are made to turn assumptions into inferences into something closely resembling facts, we still get it wrong, sometimes. No matter how good our research is, we are still predicting outcomes and have the potential to have missed or misinterpreted one or more variables; we are still at risk of failure.
How does this apply to projects? Have you ever assumed that requirements were complete and accurate, or that somebody's work was finished and bug-free? I hope not, but assumptions can plague projects, if not dealt with appropriately, which is why requirements and risk management are such an important part of project management. Even if your requirements are exact and you have mitigated or transferred all identified risk, a project can still have setbacks or fail. Some of these sources of failure are due to assumptions made before the project has even started.
- Is this the right product for the company portfolio?
- Will there be demand for the product?
- Is the company prepared to sustainably deliver the product?
- Do you have, or can you get, the right people for the project?
I'm sure there's more. Since this is a blog about project management, I'm going to let smarter people than me deal with the first three items. The last item, however, touches on a topic I mentioned in a previous post. The assumptions we, as project managers, make about the people on the project directly affect the success of our project. We often assume:
- They know how to do their job
- They provide honest and accurate estimates for what it will take to complete the work
- They understand how to effectively participate in a project
…and the list goes on. So what can you do?
You probably can't teach them how to do their job. You're a project manager and may not know how to do their job. You can help them with estimating their work, but you're limited if you don't understand their work. You aren't likely to be able to teach one person the PMBOK, let alone the entire team, before you start a project. But you can walk the entire team through the project approach at the beginning of a project, without causing significant delays. By making this part of the project plan, you get everyone somewhere close to being on the same page, and give the team the opportunity to ask questions about what is expected of them.
I describe the (waterfall) project approach as follows:
- The definition of Done - how the user/customer experience will be different when the project is complete - include project deliverables, but the user/customer experience is the focus
- The phases of the project
- Phase gates for the project - how we will know we are ready to progress from one phase to the next
- The types of testing that will be needed/performed
- Stakeholders and project roles (RACI charts as needed)
- Meetings, communication, and status reporting - include frequency and owners
- Tools & Processes - requirements elicitation & management, task tracking, test automation, communication, change management, etc…
It would be great if you can have all of this put together in the beginning of the project, but that is not always possible. You rarely have complete details at the beginning of the project, even if your projects are rolling out the same products to different customers. When explaining the project approach, you may also have to explain how the missing pieces will be identified and who needs to help fill in the gaps. You won't have all of the answers, yourself; knowing who can get you the information you need is one of the keys to success as a project manager.
All of the things that I describe in the project approach are things that we, as project managers, do. What I am saying is that we need to share this information with others, and not assume that they know how the project will be run, which will help to reduce assumptions that they make about the project and what is expected of them.
There, you have my thoughts on project assumptions. What assumptions do you make about your projects?
Free PDUs - The People and Projects Podcast:




