Project & PMO Manager | Research & Enterprise Mentor| GFB HoldingSouth America, Brazil
Despite their importance, Project Charters and Work Breakdown Structures are often overlooked or hastily prepared in many projects. What are the primary reasons for this neglect, and how do time constraints, lack of understanding, or organizational culture contribute to this issue? Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Francisco, how did you conclude that PC and WBC are often overlooked? Was there a global survey done on this? The reason I am asking is because we never overlook those items on any of our projects. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I do not agree about they are important. Talking it in this context. All that matters is the defined process to create the solution and to governance it. So, if in the defined process they exists then they are important. If not, forget about it. For example, if you use an agile based method, usually WBS are not included then they do not add value and must not be created. Saving Changes...
As Sergio has stated, the context of a project drives the tailoring of a team's approach. However, in cases where the tools you mention should be used and aren't, it does usually come down to a lack of organizational PM maturity (e.g. limited standards, lack of training, ineffective selection of PMs).
In the case of the WBS, I find that often people do not understand the function and how it affects other parts of the value stream (or don't care), so they only think about how it affects their own work, not an integrated work statement.
It tends to happen when people work in functional silos and when their part is done, they "dump it over the fence" to another group without coordination and let the down stream customers deal with what they get. If for example engineering doesn't know or care how their designs are manufactured then they don't group things by type of parts, manufacturing methods, make vs. buy, etc.
Sometimes that is due to using the wrong metrics. If Team A is only measured based on their time to complete their part of the job, then they may sub-optimize how they organize their work such as one big bucket containing everything, even though that creates much more time for groups B-Z to develop build plans, tests, schedules, cost estimates etc. If they don't understand the impact, or have no incentive to support the higher goals, then why do more work than necessary? Saving Changes...