This is not a post about critical chain project management

Ever had an itch you can't scratch? I don't have one of those.

What I do have is a lingering doubt. A sense that something or someone could answer a lot of questions if I just knew the right questions to ask and the right forum in which to ask them.

Some of these doubts and uncertainties have been discussed previously in this blog. But for clarity I'm going to cite the half dozen things that (I think) are just not good enough in project management right now.

1. Planning. Consistently falls short of what is required. Work is not identified, not adequately defined, not forecast accurately and doesn't have the corresponding supporting information to enable the brokering of appropriate resources. Successors and predecessors aren't pinned down accurately, F-S, F-F, S-F relationships aren't identified with the precision required
2. Resource brokering. If (as is the case within technology infrastructure projects) your project's delivery is dependent on skilled and scarce human resources  then resource brokering should be fit for purpose. Hands up all those people who work on projects with great resource brokering.
3. Success. Don't get me started (mainly because there's an angry man here who already has)
4. Perception. Does anyone out there hold projects, project teams, project managers in high esteem?
5. Benefits / return on investment. Goodness me but there are far to many people charging out for delivering change when surely the game should be delivering benefits.
6. Profits. Executing change effectively and efficiently will enable you to deliver your strategy with less risk and more value than your competitors. It follows that your costs will be lest, your agility greater and your profits will reflect this. 

Notwithstanding all this, there's Prince 2 and PMP accreditations, quite a bit of software intended to solve some of the knottier project management headaches, a recognition that practitioners of change are specialists and even that some expenditure on those specialists is a worthwhile investment. And, health checks, specialist consultancies, more historical data than you can shake a stick at, more than one MSc and a partridge in a pear tree. 

Perhaps most importantly (and I can speak a bit from experience here) there's quite a few bright folks in the industry and there is no limit to their determination and tenacity in trying to bring projects in on time (whatever on time means - 'cos I'm starting to get a bit jaded around that - but more on the "Aggressive but Possible" (ABM) vs. "Highly Probable" (HP) paradox another time. Discussions of 'on-time' aside, there's still the questions of scope, quality, benefits and cost.

Could it be there's something fundamentally wrong with the underlying mechanisms of project management or their application? I could go the route here of an extended negative hypothesis routine in which we discounted one by one all the other candidate explanations. I'm reasonably certain that a blog post is neither the time or the place. So let's cut to the main course.

Planning assumption #1 then; there's something wrong with project management approaches / mechanisms. Or at the very least something wrong with the way they're applied. 

If this planning assumption is born out (and there's quite a weight of evidence to suggest that it might be) then ideally we'd need something waiting in the wings as a substitute. While the current status quo is (ripe?) for improvement, it wouldn't be impossible to make it worse.

And that substitute just might be Critical Chain Project Management. I'm not going to tell you what I think. There would be an implication perhaps that you too should be thinking that. I think we all need to come to our own independent conclusions about Critical Chain Project Management but I will post on it again in the future and if it elicits only critical scrutiny of existing methods and approaches then that alone will be a worthy objective.

Top tip #1 - Milestones, baselines and tracking in MS Project

A bit of a departure from the norm today. No far-reaching debates on the state of the nation - just neat way of creating a baseline and tracking and reporting milestones in MS Project.

Take the example below (Figure 1). We can save a lengthy discussion about Duration and Work for another time.

Figure 1

You'll see a very brief example project plan with some milestones, tasks and all the usual carry on.

It's not everyday that you get to play spot the difference on this blog but have a look at the illustration below (Figure 2). What's the difference? And, does it matter?

Figure 2

How about Figure 3 then?

Figure 3

Last one then. Have a look at the excerpt below. It's actually the same as Figure 3 - but just formatted a bit differently.

Figure 4

For the eagle eyed amongst you this was all about Tasks x & y and amending the duration. When Task y was adjusted in Figure 2 - the milestone Task z didn't get pushed out. But when Task x was extended in Figure 3 - it forced the milestone Task z to get pushed out a day.

This is hard enough to spot and track on this simple example. At the 50 to 100 row level its next to impossible (yes - I know Project helps with highlighting tasks which change but that's not a panacea for us here. Particularly when plans are being shared and updated by multiple parties).

What is shown in Figure 4 however is a tiny bit of formatting on a baselined project plan and it is immediately apparent that the milestone has moved. I think this is very very helpful. It helps you (the project planner or project manager) while tinkering with your project plan to see what you have manipulated and which milestones move and by how much. It's also extremely helpful in tracking a milestone summary derived from several plans - but we'll come to that another day.

For now a quick explanation on how this is done.

1. Baseline your project plan. In Microsoft Project 2010, select Set Baseline from the Project group on the ribbon.
2. Select (say) Baseline1 from the drop down (you can use the default)
3. Click OK
4. Select Format | Bar styles from the Format group on the ribbon
5. In the name column, find Milestone and change the colour to Red (for instance)
6. Select Insert Row, enter Baseline1 in the name column, format your the appearance as a black milestone, enter Milestone in the Show for tasks column and select "Baseline1 finish" for both the From and To fields.

The output should end up looking like Figure 5 below. Click Okay to apply the changes.

Adjust your project plan to push out a milestone and you will see both the original baseline milestone and the new milestone date.

Very handy.