Wednesday, December 3, 2008

Worthwhile Reads

I like TechRepublic, here are a few links worth your time:

Project managers need more than PMP certification

I agree more or less with what is said here, though I think its true for most professionals. I especially feel that PM personal style is a huge question when hiring a PM. For instance, rigid, by the PMBOK PMs are not well suited to start up environments (which is not to say Start ups could not benefit from that sort of PMP). PMs who enjoy the meetings and interactions, but are soft on various project documenting and scheduling skills should stay away from more mature PM organizations (and maybe project management in general), especially if a PMO or security group/regime is in place

‘IT has no inherent value’

I will post my own review of this white paper soon. The Paper is from 2006 (I think) so I may include my thoughts on what has changed since then.

Five reasons to kill IT projects

I think every PM should always be ready to recommend killing their project if the reasons listed here (or other valid ones) come to be a reality. A PM should want the best project he or she can get and there is nothing wrong with wanting ones that make a name for them, but the interests of the company or client should come first. Conversely, PMs should not make a 'kill reason' a reality simply because they don't care for the project they are on.

Thursday, November 13, 2008

START/FINISH and the Critical Path

Assuming you are using some kind of fairly standard Gantt program (I generally use MS Project, but have used Open Workbench from time to time) and assuming you subscribe to the Critical Path Method, I recommend you start thinking about your Gantt's network diagram in regards to START and FINISH activities.

Firstly, these will be dummy activities. Secondly, they are zero duration activities, there only to provide an anchor to the beginning and end of the network. All nodes in the network must have one or more predecessor activities, which can be other activities or START and all nodes in the network must have one or more successor activities, which can also be other activities or FINISH. The exceptions are that START only has successor links and FINISH only has predecessor links.

Why do this? A network with dead end paths is not a completed network. More importantly, if you have dead end paths then the critical path you have calculated (or the software is presenting) may not be the actual path and changes in the project schedule (as the project progresses and is managed) may not reflect changes to the critical path (again, assuming you are seeing the correct one in the first place).

90% of the project plans (gantts) I see in the workplace have this dead end problem and no one seems to use this START/FINISH dummy set. Why? Maybe a lot of PMs feel that if a path ends in the middle of the project it has no effect on the critical path. That might be true, but is far from an absolute.

I think my strongest argument for this is that its just good design. Linking all activities in an unbroken network creates a dynamic plan, where changes are instantly calculated across your entire network.

You could of course call START and FINISH something else if you prefer, such as the name of the final deliverable, but I prefer the generic names for the clarity they offer, and what is my final deliverable? the created deliverable or the post mortem?

Thursday, October 30, 2008

Why Don't PMs Start Their Own Companies?

This question was posted on LinkedIn and it was interesting enough that I thought I would give my thoughts here. Obviously many PMs do start businesses. Some are people with dream and use their developed PM skills to execute on that dream. Others are professional PMs and become independent consultants or a group of consultants, who negociate direct contracts with companies.

I have spent most of my time in Corporate America and have only recently made the move to working for a consulting company. This is of course not my own business, but I do in fact have far more direct and meaningful influence over the company than I did at X corp.

All of this said, one reason I think PMs stay with companies is that the money is found there. I want to run large complex projects one day and large corporations have the kind of bankroll that those projects require. As well, my professors might disagree, but well developed methodolgies work best at more complex organizaitons (though they can be taliored anywhere) and it is corporations who might have the willingness to implement those methodologies (and the need).

Wednesday, October 22, 2008

PMI and Project Management

I have had my PMP since 2004.  I studied very hard to get it and worked hard to keep it active (I renewed in last year).   My PMP and PMI have been a positive influence on my professional life and there has been significant financial reward that is to be associated at some level with them.  I am now looking at get my PMP-Scheduling and Risk certifications (in my future I hope to be Matthew D Levy, MSPM, PMP,PMP-SP, PMP-RP).  

However, I do have differences with PMI.  They are not huge differences, but they are there. That said, my real differences are with PMI-Fanatics.  Those who believe all things should be PMI ruled are missing the the core of what PMI is about.  PMI is a body of knowledge, not a methodology.  You are supposed to learn it, stay current and practice it as makes sense for your organization/situation/project.  

I am not saying there should not be a written methodology in place, just that saying 'PMI says...' is not the correct response,  'PMI suggests...' might be a better one.  

I think the misconception that PMI represents a methodology is further complicated when it is compared to actual methodologies like PRINCE2.   The fact that PMI (and the PMP) is for many people the initial gateway into professional project management also contributes to the issue with a loyalty factor (maybe its just familairty).  

So what does a good PM do?  What else should they look to?  Here are a few suggestions:
These are just a few examples, though there are not that many PM specific organizations.  Also look at newer methodologies like AGILE and/or LEAN (these might be the same thing, I'm only starting to dig into them).  

Finally, just as Spock suggested that logic was the beginning of wisdom (not the end of it), I suggest to you that PMI is the beginning of project management expertise and practice.  It is up to you to further your knowledge and practice by going out into the world, learning more, applying and then coming back to these methods and BOKs and providing the benefit of your experience to improve them further.

Matthew Levy, PMP

Tuesday, October 21, 2008

Should a PM be an MBA?

I'm currently 3 classes away from completing my Masters of Science in Project Management (MSPM), this semester I am taking a Supply Chain Management class. While I like the lectures I find the class annoying because it assumes you have a bunch of MBA information that I don't.

The question is now occurring to me, do I need an MBA (as well)? Here is the link to the Google search I did on the topic:

http://www.google.com/search?q=should+a+project+manager+be+an+MBA

One of the first hits is this book:

The Fast Forward MBA in Project Management, Second Edition. I will take a look and report back.

Then came a number of links for Project Management focused MBAs. I was totally unaware of this trend and it makes me wonder if my MSPM will be devalued or worse misunderstood because of these MBAs?

While I have not researched them, I feel safe in assuming that as business administration degrees, they are not as science oriented as my MS. What if the MSPM is for academics (of which I am not)? On the flip side, if these PM MBAs are not successful will they make the MSPMs less valuable (or more)?

Lots of questions with no answers, but there is at least this article by
Dennis J. Cohen, Robert J. Graham, The Project Manager's MBA. It starts with a seemingly optimistic quote (for PMs) from Lord Tennyson.

Monday, October 20, 2008

MS Project Server

Here is why Niku Clarity and other networked PM software exists (well to be fair its a small reason among many bigger ones).  With MS Project Server 2003 (maybe 2005) you have to add everyone to the resource pool for that project plan, who you want to be able to view the plan.  

Did it no occur to MS that maybe some far flung VP or your average stakeholder might want to view that plan.  If they do, they have to see me, the PM and ask to be added.  More likely, this VP will go off telling half the company I don't have a plan in place (because if I don't have him in the resource pool he can't even SEE the plan file in the open file list).  

Now I might not have the best IT department, so maybe there are better ways to setup the server, but I think MS should approach PM software the way good PMs approach project management; Transparency.  The reality of the project (good or bad) should always be available.

That said, I constantly use MS Project.

Friday, October 17, 2008

Risk Matrix: 5x5 or 3x3?

NIST (The National Institute of Standards and Technology) recommends a 3x3 risk matrix for classifying risks, similar to this 3x3 matrix. In most cases you are weighting Likelihood x Impact, usually the ratings are HIGH, MEDIUM and LOW (as is the case with NIST), but 1,2 and 3 are just as justified (and equally relative to the rater or reader without further definition).

I prefer a 5x5 approach, which offers more detail and clarity. Some might argue that a 5x5 matrix is too much information and too much work for smaller projects. I think that's not the case. Either a smaller project is simpler than a larger one and therefore has less risks (so the burden of 5x5 is not great) or the project (regardless of size) is full of risks and needs that greater detail.
One of the things I like about the 5x5 matrix is that it allows you to mark the extremes, insignificant risks in particular are good to be able to breakout, rather than having them in with somewhat greater risks under the classification of 'LOW'. Should you bother with documenting insignificant risks? I think you need to classify all possible events that fall under the definition of risk that you have settled on and the definiton of insignificant. If you identify risks that are within your measurement extremes, you should include them.

Thursday, October 16, 2008

Project Management Takes Too Long!

This is a lament I have often heard from clients (mostly internal ones). My favorite instance of this syndrome was during a period a couple of years ago when I worked for a moderately sized corporation in South Florida.

The VP of 'stuff' in the Admissions department and I were chatting in her office (this was an online university) about the ongoing projects. I say 'stuff' because this company had a lot of VPs and I can't recall her exact title, no belittling of her or her work is meant. At any rate, we finished our review and seemingly out of the blue (in fact I was being buttered up) she started singing my praises. She went on (at length) about how I was the best PM there and she always requested me... but (you knew that was coming) "why can't we skip all this project management stuff and just get the work done"

So there you have it, I do great work, except when I do great work. Seriously though, I was pretty amazed by that disconnect. I could not understand how she didn't make the connection between my commitment (and practice) of project management methods/processes and the results that I delivered. It showed a personal lack of understanding on her part, but it made it clear to me that since she was an intelligent person there was a greater issue.

Had I managed my projects in secret, afraid to give my stakeholders a view on the complex world of project management for fear they would see no value in it? Are we (professionals) so results driven that even when we get our deliverables on time, budget and to spec we don't realize (or care to) the fact that these deliverables did not materialize out of thin air?

In that case I think I decided politics (a whole other topic) and other issues were to blame, but on thinking further I do wonder if the general opinion of those who work with PMs is that project management gets in the way of getting the work done?

No answers today, but you might be relieved to know that a Google search titled 'project management takes too long' didn't deliver any relevant results. Good news, or did I not write my search correctly?

Wednesday, October 15, 2008

Milestones... what are they good for?

In MS Project (and most project management software) the Milestone deliverable is offered. What is a Milestone?

Wikipedia says "... a milestone is the end of a stage that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting."

I like this statement, I do agree that milestones are great for events/work that is either so short a time association makes not sense or so abstract that again a specific timeframe is not required or justified (such as signing or acceptance, where the task is really the review, etc). Other than this, I think milestones should only be used to connect phases to another (since linking summary tasks is problematic, if not completely wrong) and completion. In the former case, sometimes deliverables do not logically flow from one to another.

A well placed milestone can solve that issue. In the case of the latter, a milestone can be used to tie phases to another in the same way that they can be used to tie deliverables.

What I think is wrong is using a milestone for every deliverable. If you build a deliverable oriented WBS (a future topic), excessive milestones should not be required.

Just my two cents.