If I have a schedule for the delivery phases, do I have a real scope of work on my hands? No, I do not.

If a schedule of major milestone deliverables gets confused for a project scope, I will get sucked into a major time-sink of wasted meetings and emails. Everyone will be fighting for clarification or justification of what exactly is being built while work is already under way. If the original project planning is broad enough to have planned for a high-level scope with a very high-level schedule (rolling-wave or agile style planning), then it can still be controlled. But a very detailed project schedule with detailed milestones without a corresponding detailed scope is a recipe for an unhappy outcome.

I draw up the scope first THEN I detail the schedule. If it's handed to me the other way, then I have to reverse engineer before delivery gets out of hand.

If I don't do the scope how do I know whether we've included the right tasks within the right phases, eh?!

I'm enjoying reading again a book by Herb Cohen entitled "Negotiate This! By Caring But Not T-H-A-T Much"

Help! Sometimes I get stuck trying to implement a project without a clear "Elevator Pitch" that everyone can agree to.

Honestly, that can spell trouble as the stakeholders might not be converging on the same goals. If at all possible, I work on crafting one that I keep repeating ad-hoc to others and fine tuning until I get reactive consensus. Not the best way to get an Elevator Pitch, but sometimes a band-aid is all I got. 

When a project needs a specialty tower I've never dealt with before, I like to find out what questions I should be asking. The key to relevance is to ask them from the person who is the expert from that specialty tower.

I ask "Since I'm new to this, what are the types of questions I should be asking others in order to get to you information that makes sense to your group?"

 

?

Acronyms have a useful role among specialists. They allow quicker and more succinct communications among specialists - think texting for geeks. However that is only useful when those specialists are in the very same narrow field of specialty. If they are not within the same very narrow field, I find that it causes more confusion than necessary.

So, as a good Project Manager, it's my job to decode the acronyms and put them in plain descriptive English for the other specialists. And yes, I sometimes have to put up with the "don't you know anything?!" look, but, hey, that keeps me humble.

It IS a big universe out there!

Because of all the sitting and staring at the computer screen, I like to see Dr. Oilar, my favorite local Chiropractor. He works wonders on my back and neck and has given me specific exercise tips to follow so I can counter the effects of prolonged sitting in front of a computer that the work of a Project Manager invariably involves.

First the cloud of unknowing

Then the brilliance of a hundred independent pieces working together.

I’m finally at peace with the WBS (Work Breakdown Structure).

What bothered me for the longest time is how phases and deliverables seem to get all tangled up during the planning and documentation of a project. And I couldn’t put my finger on what seemed wrong. But my enlightenment has arrived. I understand now that the two are not interchangeable and should not be too closely entwined.

It’s because of Josh Nankievel of www.WBScoach.com that I have seen the light: I will no longer do a WBS with phases built into it. This is project management’s answer to the equivalent of the “spaghetti code” problem in the programming world. He nails the problems right-on and provides the cure. You are the man, Josh!

From now on I will keep scheduling and phases as a separate animal from the WBS. Once I do that I will be able to easily trace my project artifacts (e.g. the docs) and delegated assignments back to numbered WBS deliverables – and back to the line numbers in the formal contract. This means project members can be flexible with scheduling and granular task changes without causing me to lose control of the formal scope.

I have this book published in 1973 by Alan Lakein (I was 7 years old) that I pulled back down from my bookshelf and re-read with interest his advice on handling 3^rd level importance tasks. Now that I’m revisiting his book again, it still comes across as a fresh, relevant time management book.

Apart from computer tools beings absent, it is very reminiscent to today’s popular and well-deserved reputation of the “Getting-Things-Done” methodology by David Allen.

Here’s a tib-bit from Alan Lakein’s chapter 10 entitled “Tasks Better Left Undone”:

“When Not to Do C’s: One of the best ways to find time for your A’s is by reducing the number of C’s that you feel compelled to spend time on. The main question with C’s is “What can I not do?”…Some C’s need to be deliberately deferred to test to see whether or not they die a natural death. Such possible CZ’s include: watering the lawn when it looks like rain,…preparing a meeting topic that probably won’t come up.”

I picked this book up at a used book sale for $1.

Book Title: How to Get Control of Your Time and Your Life by Alan Lakein