pmStudent

Like this? Share it!

Thanks so much for the email Vinay, and I'm glad you enjoyed the Work Breakdown Structure book.

To answer your question, I've seen many IT projects structured that way and done it that way in the past myself, that's the norm.

However, I think there is a better way.

First, I try to avoid using SDLC/project phases as a way to structure deliverables at a high-level. There are obviously deliverables associated with phases, but in general I think doing this takes the focus away from the product and towards the process. For a scope definition document, I want it to be very much product-focused without regard for the methodology that may be used (and may change during execution).

Second, I use the levels as examples in the book and you'll probably remember my point regarding the levels at which deliverables "live" - trying to assign these levels ahead of time (a level for subsystems, another for components, etc.) is problematic. It tends to introduce artificial groupings of deliverables and levels that don't make sense. The same goes for trying to assign cost control points at an arbitrary level across the entire WBS - sometimes it makes sense to control costs higher or lower depending on the stakeholders, visibility of the element, etc.

That's probably why I went light on full-fledged end-to-end examples - no two projects are alike, and with templates people start making decisions that end up creating artificial complexity and overhead. I've been involved in several large-scale projects where this happened and we ended up with these 'phantom' levels in the WBS and requirements that just create extra work for no value. Lower-level requirements get traced through an intermediate level when they could just get traced directly to the higher level, etc. I'm talking about millions annually down the tubes just due to the structure of a WBS.

Like this? Share it!

Like this? Share it!

In a recent post Bas de Baar asked the question, "Are Introverts More Suited For Virtual Leadership?"

It's a good post with some thought-provoking ideas, but I take issue with some of the premises.

Let me explain.

Behavior Matters

In the feedback model I endorse and use, the focus is completely on observeable behavior, not on attitudes or wishy-washy generalizations.

The same goes for parenting. I strive to give timely feedback to my sons when they have done something good or bad specifically regarding their behavior, not general platitudes such as "You are a good boy."

And the same concept can be applied to this question. There are no 'introverts' and 'extroverts' in my view.

That's a false dichotomy.

Instead, every person engages in actions (behaviors) every day which are both with people and without people. And in different contexts, interactions which may be seen as easier for 'extroverts' may actually be easy and fullfilling for an 'introvert'.

Context Matters

I am what some people would classify as a traditional 'introvert'. But stop trying to label me!

I'm not so comfortable going up to people I don't know and introducing myself out of the blue at a networking reception or other social event.

But I'm extremely comfortable with my teams, new team members, and even getting up in front of many, many people to give a presentation on a topic I know a lot about.

People who observe my behavior in one context would classify me as an introvert. Others who see me leading teams or teaching would probably say I'm an extrovert.

So Which Is It?

I'm I an introvert or an extrovert? The answer is neither. And neither is anyone else in my view.

Without getting down to specific behaviors and context, it's not a very fruitful exercise to ask me.

What do you think?  Leave a comment now and share, you extrovert you.

Like this? Share it!

This came in yesterday in the Project Management Central discussion board:

Get a Motivated Go-Getter

I coach people everyday who would love the opportunity to take on these activities as a way to gain experience working in the project management realm and growing their experience base.

The best resource for this type of work is going to be someone who is interested in project management. It certainly can be an administrative assistant, many of them are interested in getting into project management. 

They more self-motivated they are about project management as a discipline and potential future career path for themselves, the more you will be able to confidently hand off to them over time as they prove themselves. 

Otherwise...

If you just take any administrative assistant available without regard for their pre-existing motivation to gain experience in this way, you'll be missing out big time.

I've had this experience myself; trying to delegate activities to an admin assistant who just didn't give a hoot about the project or project management.  They will do what they are instructed to do, but you really want someone who is going to add extra value into the process by taking their own initiative to make things better as they see them.  You want someone who WANTS to impress you with their dilligence and interest in the projects and programs you run.

And perhaps most importantly, you want to groom someone who can step up in a few years as your next star project manager.

What do you think?  Leave a short comment now with your thoughts.

Recently there has been some heated debate about the value of the MPM Certification.

From time to time I learn about new programs that I've never heard of before.  Sometimes they are valid start-up certifications, and sometimes I find them to be dubious.

Certification Red Flags

• The entry requirements are usually very low (there are so many exclusions on their website, almost anyone with any PM experience or education meets them)
• To get them you just need to fill out some paperwork and send some money in
• Renewal fee in order to ‘maintain’ your credential (every 2 years in the case of MPM)

I think this is more like a club than a credential.

Seriously

In order for me to take a credential seriously, it has to either:

• Test knowledge of a SPECIFIC standard(preferably ISO, IEEE, etc. like PMP, PRINCE2) AND require experience verification.
• Verify and validate competence in practice such as some of the IPMA/asapm credentials.

That is my honest opinion on the matter.  What do you think?

Like this? Share it!

I bet you didn't know it, but Wile E. was a project manager.

A specific breed of project manager.

So what lessons can we learn from our friend Wile E.? What made him so special?

Super Genius

You may remember, he preferred to use fantastic (and usually absurd) contraptions and elaborate plans to pursue his quarry.

His primary supplier was Acme Corporation, from which he procured complicated and usually ludicrous devices in the constant pursuit of success.

Two things usually happened with these devices upon implementation:

• The devices fail in spectacular ways (Kablooie!)
• The devices work, but operator error results in failure (Splat!)

But Why?

Why did our hero continuously end up smashed, blown up, or with a difference of opinion with gravity off a high ledge?

Like the time where Wile E. procured the Dehydrated Boulder, and then it became much larger than expected and crushed him?

Or the time he donned the Bat-Man outfit thinking it would make him fly, and it didn't live up to his expectations?

Teach Us, Mr. Coyote

So what do I mean, he wasn't a project manager, right?

No, not really. But he reminds me of many I know.

Wile E. Coyote relied on gadgets and tools, all of which either:

• Didn't work
• Worked too well
• Didn't fit his needs
• He didn't know how to use
• Introduced unnecessary risks

So thank you Wile E. for being the Tim Allen for my own project management career. You've taught me:

• Simpler is better
• Do only what adds value
• An ounce of execution is worth a pound of whiz-bang software
• No single solution fits all needs
• Risk management is freak'n important

So, what has Wile E. Coyote taught you? Leave a comment and let us know.

Like this? Share it!