The Hard-Nosed Project Manager

IPMA C/B/A or PgMP

In my last few post I’ve discussed issues of certification and competence.  Lately I’ve also been interested in standards-based project, programme, and portfolio management and researching what is currently out there. 

Two of the approaches I’ve been comparing are the IPMA C/B/A and the PgMP.  One aspect I like in the IPMA C/B/A is peer reviews.  Basically a board constituted of your (prospective) peers has to accept you into the fold.  The PgMP just doesn’t have that; instead it relies of a 360 degree type of review which in my opinion would be way too easy to “game”.  If I decided to pursue a more advanced certification I think that I’d go for the IPMA C.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

 

Global project management standard

If a global project management standard emerged would you want it to be solely informative or would you want it to have a normative component?

Personally I’d go for a competency based normative standard which in my opinion could lead to a globally recognized credential.  Individual practitioners and/or organizations would be subject to reviews and auditing to improve the public perception of the PM field and most likely improve the outcome of project, programmes, and portfolios.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

PMO crazy talk

In the past I may have occasionally ranted about PMOs.  I may even have said that I would not rant about PMOs ever again.  If I did say that; I LIED…

A PMO may mean:

• Project Management Office.  Sounds fine.
• Program Management Office.  Still fine; a program is a collection of projects.
• Portfolio Management Office.  OK, I’ll buy that; a portfolio is a collection of projects or programs.

Now, let me just refresh everyone’s memory with the definition (PMBOK) of project:

A temporary endeavor undertaken to create a unique product, service or result.

I’m pretty sure that anyone involved in project management regardless of the certification body, framework, or methodology can agree to this definition or something close to it.

As I often do while driving around I was listening to podcasts.  Actually I was catching up on my listening when I heard 2 well know PM talking heads mention OPERATIONS PMO… 

I almost drove off a bridge at the first mention and I yelled at the top of my lungs at the second.  I checked the date on the podcast to see if it was an April Fool's prank.  I replayed both passages to check if I was not hallucinating.  Negative on both counts...

What the hell is wrong with these people?  Operations are continuing endeavors; they are not projects.  You can’t PMO them; stop the crazy talk.  What’s next; PMOs that run PMOs?  Do we really have to call a PMO any structure that holds 2 or more PMs?  Call I call the pub a PMO if I go there with another PM?  Again, stop the crazy talk.  Do it right now and I promise that I will not rant about PMOs ever again.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Kill, kill, kill

No, I’m not angry and no, I’m not going postal.  Anyway, we don’t have weapons up here in Canada.  Do you need a chief killing officer? is the title of an article I read a couple of day ago in The Globe and Mail.

The main premise of the article is that you need to clear out the clutter, the accumulated baggage.  And that applies to products, product features, people, standing (as in regular) meetings, reports, investors (partners), processes, HR practices, and software code.  Give it a little thought and I’m sure you can’t find other things that are in need of a good pruning; for example the project that doesn’t end and for which all hopes of an ROI have long since evaporated.

A couple of anecdote that illustrate the topic:

• In Steve McConnell’s book Code Complete he mentions the case of a lady who cuts the ends of a roast before cooking it.  She does that because he mom did it and mom did it because grandma did it too.  Looks like a best practice to me…  Eventually the lady asks grandma why she used to cut the ends of the roast; grandma’s answer?  Because my roasting pan was not big enough.  As I said, looks like a best practice to me…  

• A couple of years ago I took a couple of courses with Dr. Harold Kerzner.  Let me go in a tangent to say that it feels pretty good when a guy with 40+ years of project management says the things that you think about in your little corner of the world.  Anyway, Dr. Kerzner was advocating periodically weeding out best practices libraries and doing the same with project portfolios.  That sounds like a job for the CKO although the tendency is for project manager to reuse best practices and fight to complete their projects at all cost.  I don’t advocate giving up easy but you don’t want to have your own “Charge of the Light Brigade”; somehow the cry of “For the glory of project management” does nothing for

Now, I’ve always said that I didn’t want to be a CxO; I’d rather be a NOO (that’s a NO O), but I might just change my mind.  Elect me Chief Killing Officer; I promise to be ruthless…

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Interesting video on resource leveling

Many PMs struggle with schedule resource leveling.  Most of the time, the schedule is not dynamic enough and resists leveling. 

The Ask a Project PM: Resource Leveling video (14 min, 37 sec) discusses a number of best practices around resource levelling.  The demo uses MS Project but the same best practices can be applied to other software packages.  Some of the best practices reference an Enterprise Project Management (EPM) system and portfolio management.

My take away ordered punch list:

• Use an up to date company calendar.

• Use individual calendars for each resource, based on the company calendar and on their specific availability constraints.

• Remove all constraints that are not essential. You may have set fixed start dates or other constraints for tasks that do not require them.

• Remove all dependencies that are not essential. You may have set dependencies between tasks that are not logically related. I’ve been guilty of that.

• Assign resources or resource groups to tasks.

• Set task priorities; higher priorities get scheduled first. I’ll start doing this; never knew about this.

• Set the leveling options for your software package.

• Start leveling and level periodically.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

 

PMOs don't have to be fads

Geoff Crane commented on one of my previous posts on PMOs.  I do agree with him completely and I must admit I intended to create some controversy around the flurry of Project, Program, and Portfolio Management Office activity.

His point about ineffective implementation of PMOs is part of the “fad” pattern and my main concern with these structures.  I’ve been bouncing around Manufacturing IT for almost 23 years and I’ve seen my lot of fads and bad to horrible implementations.  Let’s see if you remember any of these; if so you may still have nightmares about them and I am sorry for torturing you:

• Computer Integrated Manufacturing (CIM). Regardless of what some may say; CIM s pretty much dead. Grandiose promises, but most of what was called CIM only had limited functionality. Most of the people who were pushing this moved on to MES or ERP. 

• Manufacturing Execution System (MES). Still very much alive with a large number of software and service providers. The main problem is that most companies that decide to implement an MES do not take the time to streamline their processes and end up automating bad practices.

• ISO 9000. This one I’ve “enjoyed” a lot… The first two attempts at ISO 9000 I experienced where multi three ring binders full of procedures, best practices, workflows, forms, etc. that were so cumbersome that the emergency change management procedure was the only one really used. A pared down version was finally developed, audited, certified, and promptly forgotten.

• Quality Management Systems. Pretty much the same as ISO 9000; once again three trips around the block but nothing much at the end. After ISO 9000 and Quality Management Systems my take is that Quality is either second nature or some unachievable goal. You just can’t put Quality into the product you can only preserve it.

• Project Management Methodologies. Most of them are similar efforts to ISO 9000 and Quality Management Systems. Guess what the result is…

A Project Management Office (boy I hate that term) can work as long as it does not try to fix all the ills of the world in one fell swoop. There is hope if a Project MO, acting as a collegial group of PMs, identifies and then tackles the 3 worse problems PMs can influence, eliminate or mitigate those problems, and then repeats the process as many times as needed.  Eventually all PMs will sit quietly, with their feet on their desks, doing nothing.  Not grandiose, just workable.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Do we need accurate estimates?

You bet your life you do and you should involve as many people as possible developing one.  If you do get that accurate estimate you will enjoy, in no particular order, the following benefits:

• Focus on the deliverables; hopefully you started with a WBS. Are the task in the estimate directly related to the deliverables or are we gold plating?

• Buy-in from your team members and management. It is not YOUR estimate anymore, it is EVERYONE’s estimate.

• You can run a Monte Carlo simulation to figure out the realistic end date instead of the optimistic one. It is pretty amazing how both values may differ.

• You’ll have identified the training and staffing needs you’ll have if this project becomes part of your portfolio.

• A strong basis for contractual negotiations. Now your sales force knows how much you think this will cost and why.

• If the client says you are too high by X your sales people can ask what can be dropped from scope.

• If your company wants the project to satisfy both its Balanced Score Card financial and customer objectives we now know how many hours we may agree to give away to gain a new client or keep an old one. Remember; do not drop the rate, give hours away instead.

• Faster response time when revising your estimate following scope changes. You already have figures out where you can cut. If the client doesn’t volunteer potential areas of scope reduction you probably have identified them already.

• You’ll have a good starting point for the next time a similar project crops up.

Of course you’ll only know how accurate you were after you get the project and you deliver on it…

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

I don't like PMOs

Actually I don’t hate PMOs but I needed another serving of TLA salad…

What are we supposed to like exactly? What does PMO stand for?  Is it Project, Program, or Portfolio Management Office?  Projects, Programs, and Portfolios are different beasts that do not fit in the same cage. 

What is the purpose of the various PMOs?

• Is the Project Management Office supposed to ensure that best practices are documented and followed? Do you need a formal corporate structure for this to happen or can you rely on a collegial approach base on a document management system?
• Since a Program is a group of related Projects do you need a Program Management Office or could you do with a Project Management Office? It looks to me like both forms deal with the tactical level and may be competing for the same turf.
• Since a Portfolio is a mix of Projects and Programs that have to be coordinated at the enterprise level do you need both a Portfolio Management Office to deal with the strategic level and a Project Management Office that deals with the tactical level?

What is the value of a PMO (of any form) to the enterprise?

• Do we need multiple PMOs for a single enterprise? How many do we need; one for IT, one for HR, one for Manufacturing, etc.? Aren’t most of the best practices the same anyway?
• What do the various PMOs do to fix #1 problem of most projects, i.e. bad requirements?
• Are PMOs created only as a “me too” fad?

I’m thinking we may be looking at solution(s) looking for problem(s).

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

The PM and the BSC

I thought I’d start this one with a little TLA (Three Letter Acronym) salad.  Beware; TLA salad is highly addictive…

I recently finished reading “The Balanced Scorecard: Translating Strategy into Action” by Robert S. Kaplan, David P. Norton.  This book presents the BSC (Balanced ScoreCard) approach to enterprise strategic performance management.  The book puts in perspective the relationship between the financial, customer, internal processes, and innovation and learning dimensions of an enterprise.

My main takeaway was that the BSC is an amazing tool for enterprise, and by association, project leadership.  For PMs lucky enough to work in an enterprise that uses a BSC approach (I’m not one of them), the clarity of purpose creates fantastic leverage in leading projects to completion.

• You can either link your project to the goals of the enterprise as documented in the BSC or classify it as a “target of opportunity” that was undertaken purely by chance. Push comes to shove; target of opportunity will lose support to the benefit of projects that support enterprise goals.
• The BSC approach will either steer the enterprise towards projects it can accomplish given the human resources it has, seek to retrain human resources to achieve the goals, or acquire new resources that enable the goals. This is a powerful driver for continuous learning both enterprise funded and employee self directed.
• The BSC approach will steer the enterprise towards processes that decrease production costs while preserving or improving quality. Fix the process, not the people.
• The BSC approach and the metrics it implies will eventually eliminate projects undertaken for clients that do not contribute to the bottom line.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.