The possibilities are endless! We could even get the team involved by picking someone out of a hat to have the honor of rolling the die or spinning the wheel in a team meeting to determine which excuses we will use. Talk about teamwork!

1 Comments Continue reading

This point consists of two elements as I see it. (1) Walk the talk, and (2) hold systems accountable.

Walk the Talk

Slogans are phony. The word slogan has a connotation of something that is not real. It sounds like an advertisement, and not something you can really trust in. In a project management organization, it is much better to have published guidelines and a vision that defines your philosophy and practice. Train your project managers and teams on the methodology. Then, let them execute within that framework, and put a system in place so that the practitioners can revise the process and make it better.

Additionally, if you say you are going to deliver the product by a specified date, budget, and quality, then do it. Consistently. Estimating a launch and then consistently missing the deadline is a sure way to make upper management believe you are full of it. Sometimes this goes with Point #9; the project manager points the finger at the stakeholders and says “well, it wouldn’t be so late if they wouldn’t have changed their requirements.” It’s your job to fully understand the requirements early on, so step up to that responsibility and stop the finger pointing. If you took the effort to better understand what they wanted, perhaps you could have provided more reasonable estimates. No excuses.

Hold Systems Accountable

If you do not have a common and well-defined company methodology for project management, you must be expecting every project manager to be perfect. The lessons learned from other projects and project managers must be transmitted through osmosis or psychically, I suppose. That project manager “should have known” how to do proper risk planning. If you lecture the project managers, they should automatically be motivate to do a better job right? After all, it was their fault for not being omnipotent in the first place, right?
A better approach might be to have a set of guidelines, tools, and techniques within well defined processes so that a project manager does not have to also be a mind reader. If projects are constantly failing at your organization, it is not because you have a set of lousy project managers (more than likely), it’s because you have no system in place to manage projects.

2 Comments Continue reading

A Goldratt technique came in handy to map out where I see the conflict between CCPM and EVM that I referred to in my last post. Please excuse it’s sloppiness, I will try to make a cleaner computer-generated version later on, but I think I may be refining this later on anyway.

I’ve never seen an evaporating cloud with more than 1 requirement for each of the prerequisites, but I found it necessary to have a requirement which stems from both CCPM and EVM. The conflict indicated between employing Critical Chain and EVM stems from different behaviors being driven by the two. Critical Chain supports behaviors that focus on efficiency with tasks on the Critical Chain , thus improving the outcome of the project. EVM supports behaviors that make it appear overall cost efficiencies are good, even if those efficiencies are being achieved on tasks that aren’t critical to the completion time of the project. Project managers might decide to work on some easier non-critical tasks if their EVM is going to fall short and get a short-term EVM win, but if that happens it throws EVM‘s predictive power regarding schedule out the window.

The resulting direction from this is to modify the budgeting and cost control tools in the Critical Chain body of knowledge. It needs to use buffer management methods for cost, to control the project that is implemented in such a way to make it compatible with existing EVM metrics. There would be a single project cost buffer which is already part of the CCBOK. Cost buffer management would be used for controlling project costs, in addition to an accurate EVM translation based on cost buffer utilization compared to planned utilization.

Note: from a cost perspective, all tasks are on the Cost Critical Chain (CCC) because cost over run in any task will make the project over budget unless other tasks have under runs. It makes no difference if they are on the schedule’s critical chain. That’s why there’s only 1 cost buffer, the project cost buffer.

9 Comments Continue reading