"Planning By Consensus" by Dan Patterson
So much hinges on the project schedule, yet so few team members contribute to it. Whatsmore, they typically don’t care about critical paths, constraints and other building blocks; they just want to know “what, where and when.” We’re overdue for consensus-based planning tools that bridge execution and analytics.
Globally recognized project analytics thought leader and software entrep…
Developing a project schedule is a funny process. It reminds me of the game “pin the tail on the donkey” where the objective is to locate, as accurately as possible, a specific location when blindfolded while listening to your team guide you to the target. A lot gets lost in translation when you are blindfolded. Determining an accurate completion date on a multi-year project is in many ways analogous.
Project plans are, at the end of the day, a forecast and are typically built using Critical Path Methodology (CPM) tools such as MS Project and Primavera. One of the challenges of accurate CPM scheduling is that the person in charge of building the schedule needs to have a very in-depth understanding of the mechanics and building blocks behind CPM scheduling. Typically, this person or team is a very small subset of the larger project team. Ironically though, while developed by a very small number of individuals (often just one). The schedule or forecast established in these tools is then the blueprint agreed upon by the project at large (and even beyond this in the form of stakeholders, contractors and joint venture partners). So much hinges on this schedule forecast yet so few team members truly contribute to the plan.
I would suggest that the majority of the project team don’t actually care about the inner workings of CPM and constraints, logic links, float and so forth but instead simply care about applying their expertise and experience in getting the work done — on time and to budget.
As an industry, we’ve spent the past 30 years developing extremely powerful and comprehensive CPM planning tools but we¹ve arguably not done such a good job in providing tools that disseminate this information to the team in a format that they care about. Critical paths, constraints, leads, lags, total float, multi-calendars are all valid building blocks for establishing as realistic a forecast as possible. Yet once this forecast is established, those responsible for project execution don¹t need to know about such building blocks. Instead they need to know who, where and when in order to be successful.
On top of this, they need to be able to report back how there are progressing without getting into the depths of physical percent complete, earned value etc. Don’t get me wrong: those metrics are important for reporting the economics of a project but not overly meaningful for those actually on the shop floor or on the job site or those writing lines of code. There needs to be a translation mechanism between those reporting execution of work and those responsible for converting this into project management analytics information.
Perhaps as project management software vendors, we should start to think more about the project consumers and make the subscribing to “what needs to be done” and the reporting back of “what we have done” more relevant.
Perhaps too we should extend this thought process and do a better job of gaining true team consensus. If there is disagreement on how long a scope of work is going to take during the planning phase, we should know about that discrepancy and investigate further. Not only does this help drive accuracy of forecasting, it also acts as a barometer as to how bought into the plan is the team in the first place. Let’s call this consensus-based planning. Heck, let’s even provide a measure of buy-in based on say the variability of the team members’ views on costs and durations. A highly agreed upon set of estimates has a far higher chance of success than a set that ranges wildly.
I believe that we are at a crossroads with regards to new emerging planning tools and it¹s my hope that we will do a better job in providing tools that help us forecast and execute more efficiently. We’ve arguably some a long way with planning but let’s not confuse what’s needed to build a plan with what a team member needs in the field to be successful in execution.