Projects with involved stakeholders are far more likely to be successful. But many projects suffer from low engagement from executives, users, and key stakeholders.
The PMI’s Pulse of the Professionsurvey found that projects with high executive support were 40% more likely to be successful than those with low engagement. However only 60% of executives were actively engaged.
GAO IS WRONG:
Activities have hundreds of fields and many might still be active if you only change a few.
GAO Schedule Assessment Guide Best Practices for Project Schedules suggests keeping deleted activities and logic while setting duration to 0. See page 140 of 240.
Why so many poor schedules?
Schedule logic is not the issue, what makes our schedule models so poor is how we deal with resources. Without resources nothing is done. Schedules that do not take into account all resource constraints are incomplete and most probably wrong.
We favor simplicity over substance and give the project manager very poor schedules he must manually adjust as soon as he realized the plan is no good.
Changes to the Baseline must be accommodated so that the baseline accurately represents the current plan.
Recently there was a tremendous opportunity to learn from one of today’s premier project-control advocates and thought leaders on a topic most project professionals may very well be occupied with on a daily basis.
As-Built schedules are very important project records as they can be used in Delay Claims disputes, generating Norms or Production Rates and benchmarking future project activities hence why a lot of emphasis is placed on activities having accurate actual dates and actual duration. But Primavera P6 users need to pay attention to their User Preferences, else they will be recording wrong actual duration for activities.
Adopting a product mindset is critical when transforming to an Agile development methodology, like Scrum. Shifting our thinking from project to product expands our view beyond the confines of the triple constraint—scope, cost, and time. The product mindset forces us to consider the larger, strategic roadmap and the value we want create.
Product vs. Project
Edit; ScheduleReader™ (previously PrimaveraReader™) has been rebranded, please see http://www.planningplanet.com/advertisers/schedulereader
When teaching classes on Agile and DevOps, I am always presented with the comment, "We've been Agile for years, but..." The student then continues to describe an organization rife with Agile ant-patterns.
Agile and DevOps are primarily cultural transformations. To "be Agile," we need to unlearn many of our existing management and software development beliefs. We need to shift from a process-based to values-based mindset and belief system.
