Someone from one of the project management groups I belong to on LinkedIn asked this question today:

"what 3 common core competencies to a project manager should apply to every new project to take good start."

Here is what I could come up with while trying to limit it to 3.  What do you think?

Planning - in this order with iteration: 1) Why 2) What 3)How 4)Who 5)When

So many people running projects tend to get these things out of order.  If you are opening up MS Project before you know Why, What, How, and Who you are doing it wrong.

Relationship building, relationship building, relationship building

Building relationships with your team, stakeholders, customers, and management is key.  You are going to need strong relationships to get through tough times and just to keep everyone on the same page and headed in the right direction.

Leadership- through facilitation and communication; trust and empower your team; do not rely on role power/formal authority even if you happen to have some.

In my experience, far too many project managers try to make people do things on the basis of formal authority.  Sometimes they really do have role power, and sometimes they've just fooled themselves into thinking they do.

I've always had the best results when I make the assumption that my team WANTS to do a great job, and is capable of it.  As a project manager, I see my major role as facilitation.  I'm helping eliminate obstacles, greasing the wheels of the project, and gently guiding as part of the team with a common goal.  I don't want fame and glory; I don't want to be the one with all the good ideas.  I want those things for my teams.

What do you think?

When using MS Project to track EV, how do you track actual hours worked?

Many different answers exist based on how you are doing the EV function.  In my case, we don't use any of the EV tools built into MS Project, so we update the % complete and feed it into an EV tool.  Our actual hours from the time charging system go in to the EV tool as well for ACWP.

I recently received this question from a student and would like to share it with you.  (note they are referring to Figure O in the eBook, not in the full work breakdown structure training course.)

"I realize that it is important to capture testing and integration but your example (figure o) seemed somewhat arbitrary. Since integration exists to ensure that subsystems work together, shouldn't we have integration identified under deliverable 1 and deliverable 3 as well? Also, is it acceptable to have a deliverable called "final deliverable integration" at level 2? Just so you know,  I am a scheduler by background so I tend to think in terms of activities. What you stated about deliverables makes a lot of sense."

Thank you for the question Russ!  I'm happy to share my thoughts:

Integration as an example of a support element happens at multiple levels (components, subsystems, systems, segments, etc.)  On the project I'm currently working with now (NASA, USGS), for our software and hardware systems we have Integration & Test at the subsystem, system, segment, ground system, spacecraft, and mission levels.  We also do unit testing within components of the subsystems but that activity is called out as a schedule item along with code reviews, etc. and the WBS doesn't go down to that level.

Change management is tough.  On a large and complex project it is a difficult challenge, even with the best processes in place that everyone adheres to in a perfect scenario.

I saw a tweet recently that asked "Why are Change Requests an output of Plan Procurements process, but not of any other planning process?"

I answered with a question....Why doesn't the PMBOK have a dedicated knowledge area for change management?

This is an area that deserves much more attention than it receives.  I manage two project teams that are developing 4 subsystems within a very large multi-level and complex project.  There are several segments of the project, and when one (say a spacecraft vendor) makes a change it often impacts my teams who are developing pieces of the ground system which will receive, process, and store this information.  Everything has to be in line, and when you start crossing contract boundaries it gets really difficult at times.

Even within my own teams, it can be difficult to properly assess the impact of a change.  One team decided we should make a change because as far as they knew, this change was only local in scope.  The next day I found out one of my other teams was a user of this data and so we couldn't make this change.  The impact would have been very high.

Change Management FAIL

As a result of this lesson learned, my team and I are putting some new processes in place.  The trick is to make them as lean as possible while still delivering the value of being able to fully understand the impact of change.  We'll see how it goes.

As a project manager, you will find yourself coming across 'lessons learned' like this all the time.  The question is, what are you going to do about it?  Do you shrug your shoulders and say 'Yeah, I hate that.  I guess we'll do the best we can to avoid it in the future.'

That's not good enough.

When you find issues like this, talk to people on the team and come up with a solution.  Then implement it.  Right away.

photo by Chill05 via Flickr

From the perspective of team member who do the real work, especially when management sees their role as mainly facilitation and not giving orders.  Traditional project organization charts focus on the chain of authority and high-level structure, while the real relationships of team structure and those who make them up is an afterthought.

Tell me what you think.  Here is a link to the XMind sample org chart I created for this video.  You can download Xmind for free at xmind.net and use it on Windows, Linux, or Mac.

Maximize to full screen in the lower right hand corner for best viewing.