Assumptions, that have not been validated, discussed or documented can seriously impact a project effort with respect to the schedule, the budget and the scope of the effort.
Recently I had a discussion with a company that was in the process of working with several vendors on a new process that would improve services to the community. When I asked how the responsibilities were divided between the companies, and who was responsible for which tasks, my question was met with silence. Then came the statement “Company X will be delivering the equipment.” Okay, great. My next question was “So you discussed this with Company X and they are in agreement that they will be delivering the equipment?”
More silence. Then I got the statement I had been waiting for “We just figured that they would be delivering the equipment.”
This is a dangerous spot to be in.
- You need equipment to complete this process/project for the community
- There are several companies that are working on this jointly but there has been no discussion on who will be responsible for which tasks
- You have made an assumption that Company X will be delivering the equipment. But you never asked them outright if they were going to deliver the equipment.
Now what will happen if that equipment is already being used on another project? What happens if they cannot afford to have the equipment dedicated to this process/project for any extended period of time? Are we also assuming that Company X will include the equipment operators to run the equipment?
All of these issues can track back to one critical element of project success: Communication. Communication activities can vary in format, delivery, timing and content. Let’s review how various forms of communication could have prevented some of the project issues noted above.
There were assumptions made that were not documented
Suggestion: Document all assumptions up front when completing the Project Charter. This will serve as a reminder to follow up on these assumptions and get additional information.
Details: There can be a lot of assumptions made with project work. I have personally witnessed Project Managers assume that a vendor will take care of several tasks, when in fact it was never discussed, and the vendor did not deliver on those tasks. By capturing the known assumptions in the Project Charter, they will be documented and discussed with the parties that are impacted by those assumptions. This discussion will also validate the responsible party for that particular task. Sometimes we assume that one person is responsible when, in fact, someone else might be more appropriate for that task due to their expertise or experience. After confirmation of the responsible party, these assumptions can become tasks, if appropriate, and included in the WBS for communication and tracking purposes.
Review and Discussion of the Work Breakdown Structure (WBS)
Suggestion: The assumptions will be discussed as part of the exercise to review and discuss the WBS with the project team.
Details: The WBS should be drafted with the entire team to ensure accuracy in tasks, dependencies and ownership. It is during this discussion that the assumptions can be fully identified with owners and timing. Once those decisions are made, the assumptions can now become tasks in the WBS.
Status Reporting and Regular Communication
Suggestion: By having an ongoing and thorough communication plan any new assumptions will be addressed immediately.
Details: By introducing the use of the tools mentioned above (Project Charter and WBS) you can establish a process for the identification, review, and determination of assumptions moving forward.
Don’t forget that an assumption can arise in the mind of anyone on the project team. As Project Leaders we need to ensure that these discussions are being held on a regular basis to address any ambiguity in tasks or ownership. This identification process should not be static because it can change throughout the life of the project.
The most important statistic to remember is that 90% of a Project Managers job is communication and yet communication continues to be in the Top 5 reasons for project failure. Let’s change these statistics! Today. Now.