Thanks for your comments and those of all the others. It’s time for me to continue my writing on Project Controls, but in a context of what some have called a humanistic approach. I prefer to call it a responsibility-based approach to project delivery.

A few of you have commented above about the concern of the fox watching over the chicken coop. While I acknowledge that there are foxes in the world, just as there are snakes, there are far more people ready to take responsibility for an outcome if given a chance. As Joe points out, ask people to produce a detailed plan for only the work that is needed and that they will be doing or they are responsible for directly managing the work of others. What we see happening every time is people step up. They become responsible. They end up taking actions that beforehand they would leave to others.

Where will this take us? Calculating progress, whether by done or not done for earned value sake or for simple coordination with each other becomes a simple matter that is addressed in daily stand-up meetings among the planner-doers. In essence, this is an approach for staying in control rather than being controlled by others. The last thing any of us wants is to be controlled by others.

I know my argument is incomplete. It also flies in the face of long-standing project management practices, particularly in DoD contracting. But, so what? Large design and construction projects are benefiting from this thinking. They are getting more of their jobs done on time and on budget with far fewer injuries. The construction industry might take a responsibility-based approach just for the sake of safety.

Note: Responsibility-based Project Delivery is a trademark of Lean Project Consulting, Inc.

I think you are really on to something here. People closest to the work have the best insight, and the truth about what is and isn’t working, is or isn’t getting done, etc. I have used this approach, successfully, with a few additional extensions to this basic idea. One: It is difficult to establish partial progress (percent complete) but relatively easy to establish done, or not done. Two: For activities (tasks) in succession, the next step validates the previous (can’t hang drywall if the studs aren’t there) so, the concept of self reporting isn’t as irresponsible as it might first appear (reference to other posts here). Last, if you allow automated reporting of done or not done, within a dynamic updating environment, the methodology will scale to a project of any size, and, allow for more detailed task assignments than would be practical if progress updating is by manual means. So, make the plan very detailed, assign each piece uniquely, allow self reporting with dynamic calculation of earned value and (time) estimate to complete. With only 100 tasks reporting, you will get live earned value measurement to a resolution of approximately 1% of total (Tasks are never identical and of equal effort). That’s better than you will ever get estimating, and, there is no cost or time delay in getting the data. I’ve done this on knowledge work projects of all types, 200-500 team members wide, and it has worked flawlessly. I’d be interested in your views on this approach. The traditional Project Controls paradigm has been perpetuated within engineering and construction for some time, but I believe there is an opportunity to rethink the approach, as outlined above.

I agree with your statement that both styles (humanistic and mechanistic) require accurate bookkeeping. The problem that I find from what Hal wrote is that on the smaller projects in an IT setting the bookkeeping is unwieldy and unmanageable as the communication is more instantaneous and collaborative. With this I find that the humanistic nature tends to become faulty when we collapse the execution and control on reporting back earned value and it turns out to be more along the lines of perceived value. The books become “baked”. Without a stand up meeting or measurable actions in a time-box setting employees tend to think they have done more or slide into doing less. EV works in large projects as stated but a microcosm will need to be refined in the years to come to manage what I dub agile “lite”.

“a task is 90% complete for 90% of its duration….ask anyone”

Same principle: without objective measures, who can tell. For a lot of construction tasks tho we can measure: count bricks, measure volume of concrete placed, mass of steel erected, length of wall completed, number of windows installed; and deviations from promises are also dead easy to spot on most occasions: just count the items.

What makes Last Planner work is perhaps the next trade contractor expecting to take up their work by a promised date, with the previous one possibly under financial incentive to meet the commitment (liquidated damages for non-completion).

In the NSW Govt. standard GC21 contract, there is an early completion bonus that can be provided which also creates an incentive for the head contractor to meet its ‘defect free’ completion ahead of time.

We have such a fixation with project controls being ‘only’ about cost, time and quality that we forget the 101 other things by which the progress and success of a project can be measured. But, in reality, while to a project manager the achievement of these might be a source of pride, to the customer these are simply “Cheap”, “Yesterday”, and “Best”, three legs of a stool which can never meet. But we keep on measuring a project manager and his/her projects by them.

Once we stop doing this the truth about what is reall going on will start to emerge from a project and we will be assured that regardless of whether or not the feedback is positive or negative, it will always be honest and capable of carrying us forward (even to a point where the project is cancelled altogether).

"The future of project controls is to place the responsibility for gauging where we are and how we are doing at every moment with the people who are executing the project. No separation of execution and control. "
Is the antithesis of how aerospace and defense operate. From my experience there and in ERP and Enterprise software, this is the literal kiss of death of a project. Those with the technical responsibility have very little if any incentive of reporting accurate and credible progress to plan. The very nature of planning and controls is to have an independent and credible assessment of the physical percent complete.

I’d be VERY interested to see how this notion has come about in your construction domain? This is not to say that the technical staff does not plan, concur with the measures of progress – percent complete, apportioned milestones, physical deliverables, or the myriad of other assessment of progress. But to have those performing the work to be responsible for reporting the “gauging” the progress is strictly forbidden in government contracting – for all the right reasons. Those responsible for delivery have a disincentive to report bad news.