As part of what I'm unofficially calling "PMO Effectiveness" month, I'm conducting this month's (April) survey on the topic of PMO effectiveness. 

Ok, so I never planned on being an author.  It just happened.  I was nearing the end of some project work and knew that there was going to be a gap on major project work for at least a month or so, so when I was contacted by a website about writing on project management topics I decided that I'd give it a try.  

While I still primarily focus on project management work and consulting with organizations, I've found the writing to be a completely different type of outlet - one that I enjoy far more than I thought I would.  After nearly two years, I've written close to 700 articles containing over 400,000 words for 9 different websites or organizations and I don't plan to stop ... maybe just slow down at times.

If you're visiting this site and would like someone with fresh words and eyes to write for your project management, small business, or business technology website or promote your product through article linkbacks and press releases, Contact me through the Contact section of this site.  And yes, I also can 'ghost write' for you to promote your product and quote you in press releases.  Close to 200 of my articles have been in the ghost writer role in the form of expert opinions and press releases.

This article was original written by me for the PM Tips website and published there on 6/21/09.  To view the original article, go here.

I’m assuming that most of you are like I am…you’ve been part of organizations that had good PMO’s, bad PMO’s and no PMO’s.  What set the good ones apart from others or at least seemed to make a difference?  Or if yours was bad – what made it so?  Why, in your mind, was your organization not served well by the presence of or creation of a Project Management Office?  And if you do not have a PMO, do you think your organization would be well served by one?  Why….what is lacking that you think a PMO would fill?

That’s a handful of questions and I’d like to hear feedback from anyone willing to offer information and answers – either anonymously or not.
Let’s assuming you’re in the category of individuals who think your organization is not being served well by your existing Project Management Office.  I’d like to hear your thoughts and reasons, but first I’m going to take a stab and what I believe are five reasons that the PMO sometimes does not meet the org’s needs.

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

Let’s look at each of these in a little more depth…
Executive Management not Included in the PMO Process
This one means exactly what it says.  If your Project Management Office acts independently and either doesn’t report detailed project status up to executive management or if executive management doesn’t care what your PMO is doing, then your PMO isn’t relevant to your organization and it isn’t serving it effectively.  That may be the PMO’s fault and it may not be.  It’s sad if you have a PMO that your CEO does not find important enough to follow, view project status or have any interaction with.  Either your PMO Director is not promoting your PMO well, proper and meaningful reporting is not in place to make it relevant, or your CEO is clueless.  
Training Plans are Non-Existent
Most project managers could use additional or refresher training.  Technology changes, better processes evolve, and – in the case of IT shops – application development processes can change.  To stay current, to stay cutting edge – there needs to be training plans in place for the members of the PMO.  Otherwise, even if your PMO is important to your organization now, it may become irrelevant in the future as more and more PMO members become disgruntled with lack of growth opportunities and move on to other positions and companies.
Common Templates and Processes do not Exist
If your PMO is flying by the seat of it’s pants, then it’s not functional and it’s not likely to last.  It must have repeatedly process to be relevant and for the company to have confidence in it’s effectiveness.  Otherwise, no one will no for sure why one project was successful and another was not.  With no consistency your organization will not know what to tweak or fix in order to make things right or better next time.  Lessons learned will mean nothing if there is no consistent process and no consistent, meaningful templates in place. 

Poor Upward Project Reporting
This one takes us back to the first point…the involvement of executive management.  Exec management may not care or get involved and that’s bad…but if there’s no meaningful mechanism by which to report project portfolio status (dashboards, etc.) to executive management, then it’s very difficult to show or prove PMO relevance to them.  You can show them how the PMO is making a difference if you can’t show them what that difference is.
Major Projects Circumvent the Process
This one may be the biggest tell tale sign that your PMO is not serving the organization well.  If smaller and less meaningful projects are being run through the PMO and managed by project managers…then that’s great.  But if they major projects go elsewhere within the organization and are managed by individuals that are not part of the PMO, then it’s obvious that executive management lacks the confidence in the PMO that is necessary to make it an integral part of the company’s success.   

These are just five signs…if I think of more I’ll post them.  If you have some to share please either post them here or email me at brad@bradegeland.com or both.

This article was original written by me for the PM Tips website and published there on 7/31/09.  To view the original article, go here.

I’ve written a lot about requirements and how critical they are to getting a project off the ground and headed in the right direction.  In the long run on a project good requirements are important for the following reasons and more:

• Keeping the project aligned with original goals
• Keeping the project on time
• Keeping the project on budget
• Scope management
• Customer satisfaction
• Ease of development and minimizing re-work

When I’ve discussed requirements up to this point I’ve usually been referring to them in terms of larger engagements with formal, external customers.  When you’re dealing with a cut and dried contract with an external customer, you have a SOW to work against, a set budget and change management is critical as is customer satisfaction, so therefore requirements and scope management are critical as well.

Internal Fiasco

So, what happens when you get an add-on internal project for an influential person within the organization and the requirements are somewhat grey?  I had a project like this not very long ago.  I was asked to run a project with the basic direction of ‘just do it’ along with my other projects and ‘make them happy.’  Fun! 

When one of these falls in your lap, you can try to formalize things as much as possible and wrap good project management practices around it, but if the customer (in this case, internal customer) is not interested or willing to participate and at that point considers it frivolous attention to too much detail, what do you do?  That’s the quandary…because I can tell you what happens if you don’t do enough.

I thought I was getting my hands around it...  I met with the customer on requirements, documented them at the most detailed level I could since I was only working with the information I was able to drag out of them.  They were basically ‘approved’ as I had documented and communicated them.

The bad news is that three months later at the completion of this small one-off process improvement project, one area was lacking the proper detail that this customer now wanted.  (Notice I’m not going into too much detail here – it would not be in anyone’s best interest nor is it important for the point I’m trying to make.)  Forget that fact that I had asked about this particular area of the requirements on two separate occasions and confirmed that we were like-minded…at least as far as I could tell with the minimal involvement the customer wanted to take at that time.

Of course, in the end the only real solution is to fix the issue and move on, which is what I did.  But I’m looking back and trying to figure out how I could have avoided that train wreck with some different corrective action during the requirements definition period.  Since it’s an important, visible, and powerful internal customer, playing the blame game really does no good…it’s still all about customer satisfaction no matter who’s right.

Lessons Learned

If this were to occur in the future, and I was still unable to gain the proper involvement from the actual customer, I would likely request that they appoint an individual to work directly with me in detail on documenting and finalizing the exact requirements.  That is my lessons learned from this situation.  That way, the internal customer truly has better representation in the process because they will assign a dedicated individual whose job will be to ensure accuracy on the customer side.  Whereas, in the situation I was involved with I had that responsibility as well as the delivery responsibility and the end result needed re-work before it fully met what the customer wanted. 

Unfortunately, I unwittingly walked into one of those “I’ll know it when I see it” type customer situations that we all want to avoid.  I find that those are much easier to avoid when the customer is external and knows up front that they are paying extra for everything not documented as a requirement.

This article was originally authored by me for the Projects@Work website and published there on 11/5/09.  Go here to view the original article.

As project managers, we’re judged by our management or company executives by certain criteria and by our project customers sometimes by a very different set of criteria.

Your company executives want to see on-time delivery, on-budget delivery, change orders, and customer satisfaction (or no customer complaints).  Your project customers want few change orders, they want a workable solution upon delivery, and they don’t want to pay too much for it.  They are often not as concerned with on-time delivery because they realize that their needs and requests sometimes push schedules out.  They are usually more concerned with functionality and cost. 

A common criteria for satisfaction on both the delivery side and the customer side is budget management which leads to the actual project cost realized by the customer.  Manage that budget well and more times than not you’ll come out looking like a successful project manager no matter what side your on.  Let’s take a look at five key ways to keep your project budgets in line with plans and expectations. 

Review the budget and forecast customer regularly
 
How you and if you keep your customer informed of the details of the budget is a decision that needs to be taken care of at the beginning of the engagement.  Since they are paying the bills and are truly part of the overall, I highly recommend keeping them informed of budget status throughout the project.

Customers don’t generally like surprises, and finding out the budget has been exhausted with two month’s worth of work remaining is a very bad thing to spring on the customer.  If you’re managing the project in such a way that the customer is aware weekly of where the budget stands and how any changes they are requesting have affected that budget, then they’re basically responsible for it almost as much as you are.  Remember, they want you to succeed because then they succeed, too.  And they want you and your team to succeed as efficiently and economically as possible.  Keep them engaged and aware and let them share in decision-making processes along the way.  Fewer surprises = happier customer.

Review the budget and forecast with your team regularly

As important as it is to review the budget regularly with your customer, it may be even more important – at least in some organizations – to do so regularly with your project team.  Why?  Because you are most likely managing very skilled resources whose talents are being used by other project managers on other projects at the same time they are working for you.  Just as you may be managing 5-6 projects at once, your lead developer and business analyst may each be working on 3-4 projects at the same time. 

I’m going to make some assumptions here, but they come from years of experience.  When the week draws to a close and you have to account for your project time, you’re often doing a ‘best guess’ on Friday morning, right?  That’s not always the case, I realize, but about 90% of us don’t chart our time on project work hourly or even daily.  We do it on Friday afternoons…or worse yet…on Monday mornings when accounting is calling us.

Newsflash…your tech resources on your projects are doing the same thing.  And when they can’t remember every hour of work they did last week but they know they worked 60 hours, those 60 hours are going to get charged to projects one way or another.  If you are the project manager who isn’t managing your resources, forecast and budget closely, then that’s where they’re going to charge their ‘grey’ hours…those hours they know they worked but can’t remember exactly what they did.  If they know you’re loose on your budget management oversight, then that’s where those hours will go and you’ll be very surprised to find yourself up against a wall on your budget even though things might be running smoothly. 

Likewise, if they know you’re watching the budget very closely and reporting it weekly both to them and to the customer, they’ll be more mindful of the time they charge to your project.  Watch what they charge weekly to your project – make sure it’s in line with what you expected of them as per the project schedule and your detailed forecast.  Discuss it with them on every weekly formal internal team meeting before revising the budget for the customer.  Keeping them engaged on budget reviews will keep stray hours from landing on your projects.

Manage scope with an iron fist

During the formal project kickoff with your team and the customer, you reviewed the project scope and statement of work as well as the project schedule.  From that day forward – along with help from your skilled team – pay close attention to customer needs and requests that fall outside of that agreed upon scope.   

If it is outside the scope and has a timeframe and/or budgetary affect, put it in front of the customer in the form of a change order.  If it’s important, the customer will pay for it and if it’s not, they’ll skip it and it won’t affect the project schedule or budget.  Either way, you win. 

Change orders usually result in increased budget to accommodate the change – thus eliminating the scope change from running your project over budget.  Plus, you’re implementing a change that the customer agrees is both out of scope and necessary for the project.  Likewise, in a show of good faith, it’s ok to give away some freebees if the budget can handle it….in the end customer satisfaction is what we care most about.

Keep resources engaged

Keeping resources engaged on the project means less project turnover and less loss of productivity.  Revolving door resources mean extra costs in ramping up the new resources to get back on track and to handle knowledge transfer.  Work with your executive management to minimize the affects of resource transitions – explain your budget concerns and the critical needs of your customer for that particular resource.  You won’t win every fight, but make sure you shout about it – the customer will appreciate it and executive management won’t be so quick to blame you if your project goes slightly over budget due to changing resources.

Stay on top of issues and risks

Keeping issues and risks tracked and in front of both project teams throughout the engagement can definitely reduce budget risks on the project.  The more aware everyone is of the potential issues and risks the better prepared both teams will be to avoid them or mitigate them should they occur.  Preparation and communication will go a long way in helping you manage those issues and risks and greatly lessens the likelihood of a major surprise that you hadn’t counted on that can knock they budgetary wheels right off your project.

This article was originally authored by me for the Project Management Tips website and published there on 2/23/10.  Go here to view the original article.

First, I want to thank all of our readers who took the February PMP certification survey.  I wasn’t sure what to expect, but I was very pleased with the number of responses and found the results interesting.

Certified or not?

Since this was basically a survey on PMP certification, I thought it might draw more certified PMPs to the site to take the survey.  I fully expected a majority of the responders to be PMP certified project managers.  I was somewhat surprised to see that a solid majority of the responses were from non-certified project managers.  60% of the survey responses were from non-certified PMs.

Passed on the first try?

45% of responders indicated that they have taken the exam by virtue of their 'yes' or 'no' answer to this question.  In all, 88% of our survey takers passed the PMP exam on their first try.  PMI statistics have shown that 72% of PMP test takers pass it on their first try.  Therefore, we definitely have an above average group of PMP readers on this site.

Length of certification

Because I placed ranges rather than specifically asking how long individuals had been certified, the next figure is not exact, but was actually more ‘derived.’  By using range midpoints as values, I was able to determine with less than exact accuracy that the average length of certification for our 40% of responders who are certified is 3.3 years.  I don’t have anything specific to base this on, but I know at one time last year I saw a study stating that the average PMP had been certified for just over 3 years, so we’re right on average with that figure.

Reason for certification

The next question on the survey asked what your primary reason for becoming certified was, or what your primary reason would be if you were to become certified.  Interestingly enough – and maybe predictably enough – for PMP certified project managers the primary reason they became certified was to meet a personal goal.  42% gave that response – nearly double that of any other response option.  For non-certified PMs, their primary reason for potentially become certified would for job-seeking purposes – 41%.  Again, nearly double that of any other response. 

Here’s the breakdown for this category:

PMP Certified responders

Personal goal – 42%
Job-seeking purposes – 24%
Company requirement – 18% (I thought this would be higher)
Future resume builder – 13%
Other – 3%

Non-certified responders

Job-seeking purposes – 41%
Personal goal – 24%
Future resume builder – 21%
Company requirement – 9% (again, thought this would be much higher)
Other – 5%

Combined

Job-seeking purposes – 34%

Personal goal – 31%
Future resume builder – 18%
Company requirement – 13%
Other – 4%

Career booster?
And finally, the subjective question – has the PMP been beneficial to your career, or for non-certified, do you feel it would be beneficial?  Here we had the highest percentage answer of any category as the PMP certified PMs overwhelmingly stated that earning the PMP certification has been beneficial to their careers.  A full 71% responded this way.  18% were not yet certain, while 11% stated that they had not experienced any career benefits yet for having the PMP certification.

For non-certified PMs, 47% thought it would bring benefit to their careers to have the certification, 40% were not certain, and 14% felt that their careers would not benefit from having the PMP designation.

When we combine the PMP responses with the non-certified responses, we have a total of 56% who thought their careers have benefited or would benefit from the certification, 31% were not certain, and 13% felt that their careers have not or would not benefit from having the PMP certification.