pmStudent

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.

I work on a complex project.

Lately, one of my most important roles has been to get decisions made and documented.  I've been kicking down doors ( opening them with a polite knock and charming smile), crashing meetings (asking for a walk-on agenda item from the host of a standing meeting I don't normally attend because the right people did attend), and interrogating miscellaneous stakeholders and customers ( friendly conversation expressing my empathy for their needs).

The Curse of Indecision

For one reason or another, many conversations in the life of a project stakeholder tend to end up ambiguous and without clear agreement.  People nod their heads, reserving the questions or objections they have.  Many figure this isn't the last word and they can have their say in another venue, and unfortunately they are usually right.

Get the Right People In One Conversation

In the same room, on the phone, whatever.  Provisional decisions because someone is missing are not decisions at all.  There is enough uncertainty in projects without adding a preventable source like this.  Time and time again, I will engage in conversation with someone and hear something like "so and so said we were going to do A".  Another person says "no, I heard we were going to do B."

There have been a few occasions recently where upon being involved in a conversation like this, I walked over to the person who could settle the question, or said "Hey, there is a meeting going on later today with all the right people.  Let's crash it."

When the decision is made, make it clear to everyone in the room there is no going back.  "This is what we move forward with.  If you have any concerns or comments, now is the time."

As a project manager, some of the most important things you can do for your team are to eliminate unnecessary uncertainty in their work and remove obstacles like "waiting for a decision".

Even better, you can lead by example and show your team how they can do the same for themselves.

Photo by Perfecto Insecto

Thanks go out to Carissa from the USA for this question.  You may also want to check out a post on Project Manager Interview Questions too.