|
|
Earlier this month, PMHut.com posted an article, “So What’s Your Project Charter.” It caught my eye. As I hope you’ve noticed, I’ve been considering the various tools and processes that PMs can use on projects and trying to determine which are most relevant to our environment, Cottage PM (see About Cottage PM on the left nav bar).
And I fully intended to suggest that the formality of project charters is usually not needed for Cottage PM environments. I tend to shun formalities in general in my environment; they’re often quickly interpreted as process overhead with little value, and once that conclusion is made, it’s hard to overcome.
But then a colleague of mine latched onto the project charter as a solution to a huge new project problem he’s facing. I had my doubts, but today began to see some fruits of his approach, so my anti-charter stance is softening. In fact, I’m beginning to think that some form of charter is probably essential to Cottage PM success.
What’s a Project Charter?
Well, for a really good write-up, see PM Hut’s article here: http://www.pmhut.com/so-whats-your-project-charter. It’s worth the read.
PM Hut provides this short definition of a Project Charter:
…a formal agreement between the creators and consumers of project deliverables that establishes the purpose, boundaries, directions, limitations and participants of a project.
The Charter is the first run at formally defining the project. Expanding on this quick definition, PM Hut offers a few more ideas on content. The following are those that my colleague is using to define his project.
- Project Goals
- Project Scope (boundaries)
- Project Objectives
- Project Approach
Project Charters in Cottage PM
So, why am I shifting my stance on project charters in Cottage PM? Maybe we’re not building rocket ships, but our projects carry significant impact and investment and risk for our organizations. For all projects, small and large, clarity of expectations and direction are essential to producing the right output and to creating value for the enterprise.
In Cottage PM, we work where there is little formal knowledge or formal practice around projects. We work with really talented, creative people who know how to get things done. Really talented people get lots of ideas. Lots of different ideas. That’s both a boon and a bane to the PM. Lots of ideas are good for finding solutions. But at some point you have to reign that all in and align it to a single project vision.
The Project Charter is perhaps the first tool the PM can use to begin to align all those stated and unstated expectations; the first step to being able to paint a picture, to create a vision that everyone can get behind. It’s also a more formal way to validate one’s own understanding of what’s intended.
You need that just as much in Cottage PM as in larger projects. We could argue that in the absence for project formalities, you need this early definition even more than others may.
How To Use A Project Charter
The answer to how to use a project charter depends on your organizational norms and expectations. In my case, we’re getting away with using the word “Charter” — more on that below. But the charter, like any other project process or tool, should not be created and sent out as a notification. Do that, and you might as well not bother. Instead, you can either create it collaboratively with your sponsor and key stakeholders, or you can distill your own understandings into a charter, then meet with them to present it, to discuss it, and to adjust it.
For example, today my colleague introduced this idea during a staff meeting with the VP. On the agenda was a quick update about this project. As part of the update, he indicated that he was drafting a charter and would be meeting with the VP soon on that. He briefly define the charter in non-threatening language. He even shared some key points of the charter already so that it didn’t appear that he hadn’t done anything on it or that he was saving it all for later. Very open communication, but also setting a stage for more formal, more complete understanding. Now the VP has both an update and a plan for further definition. And he’s not surprised or confused by a new process. Score one for the project manager!
I Still Hate the Term “Project Charter.”
Typical teaching about Project Charter centers both on this definition value and on the idea of “authorization.” This angle of authorization may not be so meaningful in Cottage PM. Often, the PM is also the functional manager and has natural ownership over the project. Declaring some separate authority seems redundant and can lead to that perception of meaningless process overhead. However, if you work in an environment where declaration of authority is needed, then by all means, leverage the Charter for that, too.
If we remove that idea of “Authority” from the Charter, then the term “Charter” itself seems empty to me. I dislike the term. It says to me: “You’re trying to process me; we’ve already talked about this; quit forcing me down a PMBOK path and just go do what I need!”
If you face that perception risk, too, then change the name if you need to. Label it something meaningful for your environment. Or, if the term “Project Charter” is simply unknown, you may do better to simply define in meaningful terms and move on. Just don’t feel trapped by the label. I bristled at the label for a long time, and am now realizing that I rejected the value of the tool because its name and its focus on authority. All the while, I was fighting problems created by a lack of early formal project definition.
So, I stand converted to charters, though perhaps by another name.
I have hanging outside my office the overview poster that came with my PMBOK4. The poster shows a rough flow chart of all the PMBOK’s project management processes. It also shows the macro-flow between Planning, Monitoring & Controlling, and Executing. A decent flow chart. Wish I could find a soft copy of it.
One of our young developers walked by today. He helps me out when I have more technical linux questions. He saw the chart and asked some questions. The crux of the questions really came down to this:
“Out of that whole project flow, where do I fit?”
The answer, for a developer who spends all his time developing on projects, was at first discouraging. All his stuff, all his work, fit only in that box at the very center of the chart: Executing. And not just within the set of Executing processes, mind you. Pretty much just in the single process of Executing.
We chatted about it. It was a good chance for me both to reassure him about his place on the chart, and expand his understanding of what it takes, of everything else that has to happen so that he can be successful developing on the projects.
Here were the key points we discussed.
Project Planning
On the chart, planning is the biggest process group. It can be an “ah-ha” for a developer to begin to glimpse all that has to happen before he starts work, just so that he knows what the heck he’s supposed to do.
I also tied in his experiences having to redo work as requirements shifted, or as we discovered misunderstood requirements. He, like many, has had the unfortunate experience of demoing the first half of your work only to hear, “But, I thought it was supposed to do [insert new, surprise requirement].”
Planning helps to avoid that.
But that leads to the next principle: “Plan to replan.” It’s gonna happen. Expect it. Plan for it.But if you didn’t have a good plan in place, you can’t judge impact, downstream changes, etc., nearly as effectively.
And that leads to the next topic.
Project Control
In projects, “control” refers primarily to knowing where you are on your plan, spotting variance, and handling that variance.
Principle: “If you don’t have a plan, you can’t know where you are on the plan. If you don’t know where you’re supposed to be, you can’t judge variance.”
Well, you can guess. And if you’re really good at what you do, you’ll even guess right a lot of the time. That might even be more true for us in talented Cottage PM organizations — smaller project teams, smaller projects, even though they have huge impact. But it’s not necessarily true for us, either.
It goes further, too.
If you don’t know where you’re supposed to be, you can’t report your progress — at least not with any reliability — to stakeholders and sponsers.
Wrap Up
Finally, was able to point out the key planning process outputs that he uses: WBS & Schedule. The PM we have working on his team is pretty darn good, so he knows these tools well. I reassured him that from the project manager’s view, all the developer’s work might be in that one box, but in that box are those really long WBS charts and detailed Schedules — all those things the developer is working to. It represents all the “getting it done.”
I’m not sure he left feeling the “ah-ha” that I’d hoped he would feel after my explanations. Perhaps I wasn’t as clear or as insightful as I’d hoped. But perhaps it sets a stage so that the next time the PM is pulling her hair out, he can understand that a little better.
 I’m preparing to review Cornelius Fichtner’s PMP exam preparation package called “PM PrepCast.” Cornelius runs the web site, http://www.project-management-podcast.com/. I’ll be writing soon about my impressions and how I’d such a package fitting in one’s PMP exam prep, comparing it to my classroom prep experience, and musing about its use for the environment that I care most about, Cottage PM.
Early Impressions
I’m encouraged. I’ve been a free subscriber to Cornelius’ podcast for a while. I enjoy listening to it, and a few others, on my daily commute. (I put the podcast on my MP3 player, pull out the knitting, and knit and listen for 40 minutes. Yes, I knit. I write about that on my personal blog, www.MaxWalker.name. But enough about knitting. Back to Cornelius’ podcast.)
I’ve been impressed with the quality of information provided at PMPodCast. So, a few weeks ago, I took a moment to glance at Cornelius’ “Try It Free” section the web site. The first impression was really good. Very organized. Appears thorough from the first look. And appears to have the same “consumable” and approachable quality of the podcast.
Happenstance
Then, as it happened, I ran into one of my organization’s PMP candidates, Dean, last week at work. Dean’s been preparing for the exam for quite some time the same way a lot of us do — we start, we stop, we start again, we stop, then we finally set a goal and get serious. Dean’s serious now. Having already approached Cornelius about such a review, I mentioned PM PrepCast to Dean. To my surprise, he already had PM PrepCast, he said. I started to dig down a little to see if it was the same package or not. He reassured me that it was, and was able to refer to Cornelius by name without even thinking about it.
Dean told me how impressed he was with the package. He bought it quite some time ago and has benefited from Cornelius’ free updates to package owners. It’s Dean’s primary tool for prep, and he’s been really pleased.
So, now I’m all the more excited to review the package.
In A Hurry?
But if you’re in a hurray, I suspect you could certainly get the package before I write about it in more detail. One learns to trust community response and feedback, and Cornelius has good response and feedback from the community. Compare to many other PMP exam prep choices, Cornelius’ PM PrepCast is very economical at $99. I paid a lot more for my classroom prep course.
————–
For the record, I am signed up now with Cornelius as an affiliate, so the links here are affiliate links. If you buy the package through these links, I’ll get some Pepsi money.
OK, I promised you another story on self-interest. Here you go.
Ethics — c’mon, keep reading
Let’s start with discussion ethics and those pesky ethics statements. Some whine about it, and I’ll concede that ethics statements are usually way over-though and over-stated, and even if you agree with them, you still often end up rolling your eyes with a “Really?!” kind of response. You agree, of course, sincerely, and both in form and in intent, but the statements can seem so out there. Such was my reaction to the PMI Ethics Policy that you sign upon becoming a member and that you sign again when sitting for the PMP exam. (The test questions on ethics can be particular amusing, errr, frustrating, because they can so unpredictable and situation-dependent. But moving on.)
But I’m grateful for focus on ethics and reminders on them. One is always grateful as one observes the lack of ethical behavior.
The Story
A few years ago, I worked in an account management role. As in many teams, you had those team members who were the acknowledged stars, the right-hand to the team leader, the ones who always seemed to have the roughest customers and handle them the best. I learned that things are not always what they seemed.
We had 2 such team members. Let’s call them Bill and Joe. Their customers were always in a state of escalation. There was always a crisis. We were all aware of it, and always duly impressed with how Bill and Joe handled these irate and uncontrollable customers. They were always on escalation phone calls with the customer and the VP. They had to get extra resources assigned to solve problems. They frequently got upset themselves and threw their own tirades, but that’s just an aside.
At one point, Bill moved on to another position in the company, and Joe took over many of Bill’s rough customers. Later, Joe left the company, and his customers were reassigned to another account manager. Let’s call him Tim. Tim was a mild-mannered fellow whose customers were never hollering, never yelling. It was perceived that he had easy accounts.
As was the norm, Tim approached the main contacts at these accounts, the same contacts whose names we all knew because they were always making so much noise. Tim approached one of these customers and introduced himself. Through conversation, Tim was surprised to learn that the customer didn’t even know Joe’s name. Didn’t know what role he played in our account relationship. And the customer expressed a general contentment with the company and services provided. Over time, that proved true; the customer virtually never escalated again.
The Conclusion
Bill and Joe had snowed us over. They’d created crises to gain visibility and notoriety. And it had worked for a long time. The leadership at the time was slow to catch on to the dynamic, even after that experience. It was explained away. And trusty Tim was eventually let go when budget cuts required staff reductions. He was apparently not perceived as valuable enough, he who could manage accounts so smoothly as to never create crisis, and who could resolve crisis so ably that no one ever heard of it.
So What?
OK, so what’s the message for Cottage PM? Two things jump out at me today. One lesson from Bill and Joe, and another lesson from Tim.
- First, well, ethics matter. Integrity matters. This kind of unethical behavior may appear to work for a while, but at some point, it’ll become clear that you’re not creating value. It will erode your project team’s trust in you. Motivation will fall. Results will suffer.
- Second, communication matters. And that ties back to my previous post on communication. Tim was so quietly effective that he may have been undervalued. (I wasn’t involved at a managerial level, so I can’t speak to the decision process there.)
There is a valid self-interest that pairs very readily with an organizational self-interest to communicate well in your projects. Your leadership does need to know what decisions you’re taking, what problems are surfacing and being solved, what priorities are shifting, resource challenges, etc. You’re professional. You can communicate that without whining and without an obvious self-pat on the back. You can communicate it legitimately and sincerely in light of the organizational needs for that information. You can be sure your project team gets credit for their good decisions, avoidance of risk, handling of crisis.
And it strikes me that while that communication is important on any project, it may be particularly important in a Cottage PM environment where there are few norms and standards for projects themselves, and where an organization of even really talented people may not anticipate problems and downstream effects of project decisions.
So in the absence of set project expectations, leverage the general communication methods of your organization (if they’re generally effective). Use established communication norms. If you’re an email culture, do email. If you’re a reports culture, do reports. If you’re a meeting culture, do meetings.
But whatever it is, do it.
Seems like everyone is talking about project communication and the soft skills of project management. One of the things that attracts me to the PM practice is the all-encompassing nature of it. To be effective, one has to understands projects, yes, but also general business, one’s own industry, contract norms, people management, financials, etc.
And you better be pretty darned good at communication.
And that goes double for a Cottage PM environment where the formalities for project selection and project charters and scope statements and such may not exist.
The Story
Here’s my story from today to back this up.
I work in an Operations group. We provide some process support, customer support, project support, and technical development for certain business and services units. We’re a Cottage PM shop. That is, we do a lot of projects without the rigor of any PM standards or norms. We have really talented, go-getter people, and we get some amazing work done. But as our success and responsibilities grow — yeah, those go together — we sometimes get bit in the behind from some of that lack of project formality. Like you, we have to figure out how to scale the big-PM thought that dominates PM literature, training, and certification down to a functional level for our environment.
So what’s up with communication today (the literal today, not the figurative today)? The principle is this: you gotta make sure that your sponsors / leadership / stakeholders understand properly the level of work involved in the projects. When you have a standing Operations team like ours who own most of these projects, it’s easy to forget that resourcing is still just as real a challenge as if you were hiring out for resources.
The Problem
Today, a colleague and I were visiting about a communication challenge. As in most project environments, including Cottage PM environments, there are many more desired projects than we have resources to work. Prioritization is a constant challenge. My colleague was lamenting that leadership was wanting two major projects by the end of the month. One had been prioritized above the other because it involved a hard date for customer announcement. The other is still wanted. What came to light in recent conversations, though, was that the business leadership had through that we were working only on that 2nd project. Leadership was apparently unaware of the technical work that had to be done — and was being done agressivley by a virtual team of at least 3 people — for first, higher priority project.
We had shifted our priorities to match the shifting business priorities with such efficacy that the leadership didn’t even know it.
On the one hand, that’s awesome agility! On the other hand, communication didn’t accompany the change. The impact of that shift was not called out, wasn’t known, and as a result, expectations didn’t shift with that shift in priority, and now there’s a problem.
As project managers, we have the functional need and the ethical duty to be sure that those expectations shift, too. Duty? Yes, duty. And not just because of expectations. It’s because the organization leadership really needs to understand how its limited resources are deployed and to have the freedom to exercise its own ethical duty to allocate those resources to the benefit of the organization.
Now What?
As my colleague and I talked, I discussed with him the use of a WBS as a means to do that communication. The WBS exists for these projects in one form or another (remember, we’re a Cottage PM environment in which there is no particular standard or practice for such things). But the WBS is not usually in a form that can paint a picture for leadership. And it should be. It’s a critical communication tool, not just a planning and control tool. So my colleague and I identified 3 things to address this problem:
- First, he’s going be diligent about a written Charter/Scope document to define the project and its borders at the beginning of the project before work begins. (Our organization won’t support the oft-touted rigid processes of written and signed Charters followed by Preliminary Scope Statements, then Scope Statement, then who knows the heck what, so this combined Charter/Scope idea is probably and appropriate scaling of those processes for our environement. We’ll see how it goes.)
- Second, we’ll explore using pictorial WBS geared toward communication. To do that, we’ll leverage some of the really good, straightforward recommendations from Josh Nankivel’s WBS Coach package.
- Third, we’ll be more diligent about project closure where we sit down with the leadership, pull out that Charter/Scope doc, and prove the results.
If you look at it, it doesn’t really add that much work. That work is already happening. But it happens so informally that memory shifts, priorities shift, crisis takes over, but things only ever get added to the plate; nothing very really gets prioritized off the plate.
It’s important to note that there are both self-serving elements at play and altruistic elements at play. And that’s OK. Just don’t let the self-serving aspect overtake the altruistic. It’s your job to keep them aligned and heading the same direction. I remember a college history class that discussed the idea of “enlighted self-interest,” and that’s probably what we’re talking about here.
I’ll write again about that self-interest gone amuck in a little while. Got a good story on that one, too.
I spent Friday morning in the first of several one-on-one meetings with staff finalizing objectives for the fiscal year. That’s got to be the best part of managing!
Last quarter, one of my teams had an important project to deliver by Q-end. It seemed impossible. We were half-way through our Fundamentals of Project Management book club as a team. That put us through the project definition, initial planning, and WBS conversations. The team had already had lots of “ah-ha” moments.
Then the project got serious as we realized there were conflicting demands for the team’s time. The team agreed to adopt some of the PM principles and processes we’d just studied at a high level. One team member took over as PM and consolidated the team’s knowledge about the project into a WBS and rough time line. Instead of resisting what might have otherwise been perceived as an overhead, administration, “just let us work” exercise, the team went with the flow and realized some important benefits.
Among these was focus. With two important projects running simultaneously, using the WBS let them quickly figure out how to divvy up responsibilities and made deadlines clear. There was a sudden focus in the team that had been missing. Then their natural talent kicked in as they were able to focus on the work and not on panicking about time line and “are we forgetting something.”
The team recognized that change, and ever since, they’ve been asking to repeat that experience as new projects with conflicting resource demands start to weigh down on us. So I spent the morning shifting some team responsibilities to support more targeted work, more focus. We begin next week defining one of the projects together, then we meet with leadership to prioritize a stack of projects the following week. It hink we’re on our way to repeat that really exciting experience of focus that was the result of using project methodologies.
One of my other staff members seems to always possess that kind of focus. She manages a program all on her own, and some of the projects she has to drive with IS&T and other departments take quite a long time. She always knows her current status, her next steps, and even past decisions taken. It seems to always be at her fingertips. I don’t do it that well. I’m sure she follows some sort of methodology to do that, in addition to possessing a natural ability to organize details. But I think the methodology is not defined; she does does it naturally and has done it for a long time. I asked her today to see if she could identify her method, even if it’s really low tech (maybe even better if it is really low tech) and to share it with the team in an upcoming meeting. I’m intrigued to see what she comes up with.
I got the first issue of my renewed subscription to Inc. Magazine this week (November 2009, see inc.com). One of the first articles I read had a good Cottage PM scenario as the opening story. The article is “Slow Growth = Slow Death?” and is mostly about growth questions and strategies. It’s an insightful read on that topic. But the opening story should be pretty familiar to those of you who work projects without formal PM practices.
The article is nicely written; I recommend that you read it. Here’s the story I’m referencing, though:
One of our best programmers just came into my office. . . . Implementing the new prices on our website going to take too long, he told me. . . . Changing the prices for new customers is easy, he explained. The hard part is building a slick new area on our website where existing customers can go to convert to the new pricing. “What if we don’t have a slick website?” I asked. “Anybody who wanted to convert would have to call in, and we’d have to do it manually,” he said. “Could you get that part done on time? With the manual conversion?” He said he could. Which means we’re going to do a half-baked job of implementing these new prices. We have to, this time, because we’re committed to a date. (Reference link.)
There’s a lot to conclude and consider about project management in that short scene. I’m sure that for many of you, this is not an unfamiliar scene. What can we observe and how can we make this go well?
Some Assumptions and Next Steps
Making assumptions on a short story who’se point was not PM analysis, I note the following:
- There was apparently no PM involved. The story gives no insight into how the project was scoped, defined, controlled, or managed. I’m presuming something existed between the organization leader and the programmer, but perhaps not.
- Notice the trade-off in what PM types call the triple constraint, the constant balance between Time, Cost, and Scope. In this case, Time (launch date) was firm, so Scope had to change (change in deliverables and quality of deliverables).
What needs to happen next? What’s the fallout from this decision? If you were PM-ing this project, you ought to readily see the following considerations:
- Who needs to know the change in deliverable? Are others doing work that needs to be called off now?
- It’s not just that we’re not doing the new interface; we’re replacing that deliverable with a new deliverable: the manual process. Who’s going to define that, frame it, design it, test it, train it? Is there new cost associated to that?
- Are we still going to want to build the new web interface later? If so, will it be a new project, or a new phase of this project? Is it subject to other prioritization decisions / processes?
Planning for Change
These kinds of changes are not uncommon. When you plan your project, you need to plan to re-plan. It’s going to happen. Sometimes it happens big, sometimes it’s just small adjustments, but change is, well, a constant.
If you were the PM on this, whether formally the “PM” or simply the functional manager who owns it — that’s how it often happens in Cottage PM environments, as you well know — how could you manage this well? How could you structure the project to anticipate such change and to be able to manage that change quickly and well?
In his recent package, WBS Coach, Josh Nankivel (Twitter: @PMStudent) makes the case that you can probably do this best by using a Work Breakdown Structure (WBS). You don’t have to be a formal PM or a certified PMP to be able to use a WBS effectively.
A WBS captures the full set of deliverables — the work — for the project. If it’s part of the project, it’s on the WBS. If it’s not on the WBS, it’s not part of the project and you don’t pay attention to it. Then, if your programmer says the deadline prohibits delivery of a key deliverable, you can quickly see the impact of that change, and the impact of introducing a new deliverable in its place. You can communicate that change to the project team and stakeholders easily using a WBS.
You might simply stop there, just having the WBS. Already, that would be really helpful and would give you more control of and visibility to your project. You could also go further and tie that WBS to schedules and cost structures. This provides “traceability,” making it much simpler and much more reliable to quantify and manage the impact of change.
I highly recommend that you learn how to use a simple WBS on all your projects. Whether or not you bear the title of PM, if you’re leading projects, you need this tool. Need to know more about the WBS? Check out Josh’s “WBS Coach” package. It’s a quick 4-hour self-study. Choose to read the PDF (like me) or to listen to the MP3 files during your commute. Watch Josh demo some common approaches and tools to building a WBS. Pick your preferred medium and start using it immediately.
Don’t be thrown by project change. Plan for it and know how to manage it.
In December, Pawel Brodzinsk post the following article on his blog, Failed Projects: You Can Do Worse. In that article, he puts a really good list of contributors to project failure. While Pawel writes from a formal project environment, I find his list of contributors project failure relevant to informal PM environments — Cottage PM.
Here’s his list in summary (you should read his post for more perspective):
- Crappy Estimation
- Scope Creep
- Wishful Thinking
- Ignoring process on client side
- Compromising quality
These risks face any project, but may be even more risk for you in an informal project environment. Just because your organization may not use formal PM practices doesn’t mean the project you’re undertaking doesn’t have a big upside or downside for the organization. You’re doing the project for some reason, and you need to deal with these risks.
You don’t have to use fancy PM tools to handle it (although you can). But fancy tools or not, you have to start in the same place: Just be aware of the risks and handle them in your own way. Do it in a spreadsheet. Do it on the back of a napkin. Speak in terms of end results and impact, always in light of the intended results and payoff for the organization, and you’ll get more traction.
For example:
- Crappy estimating: Whether you have a formal estimating process or not, you’ve made some assumptions and some estimates on cost, time, quality, scope, etc. Are those estimates sound? Or are you in a totally new space, using a new technology, and really have no basis for estimates? Maybe you can’t change it, but you can help everyone know the risks associated with that weakness.
- Scope Creep: Using whatever process and approach you like, did you lock in the project vision and scope? Do you all know and agree on “what done looks like?” Do you have a clear list of deliverables? Are the specific enough to provide a basis for control of the list? (Tip: Consider using a Work Breakdown Structure – WBS – to provide better visibility to scope. Click here for some more info about using WBS.)
- Wishful Thinking: Yeah, well, you know better.
- Ignoring process on client side: This may be less of an issue for you if you’re working within your own organization instead of hiring your PM services out to a client. Still, even if you’re working with other internal organizations, such as your IS&T group, then you need to explore this possibility.
- Compromising quality: If you lose control, this may be the last ditch effort just to get something out the door, something delivered. But something bad could be worse than nothing at all. Be careful. Re-scoping is valid as constraints change, but do it openly, consciously, purposefully, and knowing full well the impact of the changes.
If you do some very basic project planning, and focus work on the WBS, you can avoid myriad problems, even if — perhaps especially if — you’re new to PM.
One of the personnel management principles for project managers is that of rewards: the need to recognize and reward project team members for good, effective work.
And that’s what I’m going to do for the next 2 weeks. 
While academically speaking, my launching a new professional blog with me owning all the tasks may not comprise a project, we all know that it involves similar planning, deadlines, pressures, risks, etc. It just means that I only have me to blame if something goes awry!
So, having launched and feeling somewhat content with the launch, I’m ready to reward my project team — me — and take a nice holiday break.
So I shan’t be posting new posts until the new year. My thanks to those who’ve followed me on Twitter and left comments here and on Twitter. I feel really content and grateful for the support the #pmot Twitter community have offered me, including in particular, Josh Nankivel of PMStudent.com.
I’ll see you all again the first week of January!
Merry Christmas and Happy New Year!
I see others in the #pmot community on Twitter also talking / asking about the benefits of PMP certification (see PMI.org for more info on the PMP). Threads are taking both the career angle and the project success angle. Both are interesting and valid threads.
Recently I had a follow project manager in my organization ask me about certification. She’s been doing project management a lot longer than I and has an established reputation as a successful PM. We talked about certification. Here were some of the key considerations.
PMP is not the end of learning.
My colleague had some concern that she may stop learning after PMP. There’s a perception that PMP comes at the end of one’s learning cycle, and practitioners may delay certification, thinking it needs to come later after they’ve learned everything (or everything else).
I argue that PMP certification — or the preparation for it — is one learning exploration among many. It could come anywhere along the PM’s career-long learning. Even if you’re at the beginning of your career, you can certify with the CAPM certification (see PMI.org), which doesn’t have the requirement of having been a practitioner for some time before certifying. Whenever you certify, you certainly should not assume to stop learning. Not only does PMP have the requirement for ongoing learning (Professional Development Units or PDUs), but you may find that the focused exam preparation opens up for you areas you’d naturally like to explore yourself and possibly with peers in your organization.
It’s important to acknowledge, too, that there are other PM certifications. The topic of which is best or most valid or most credible beings to elicit lots of impassioned opinion. Pick the one that’s most relevant to you, your job requirements, your chosen industry, and your part of the world.
What’s the best way to prepare for the PMP exam?
The best way to prepare is the way that best matches your learning style and comfort. There is no single best way. Me, I shudder at the thought of using flashcards. Too 3rd grade for me. Others would shudder at my own methodologies, including my 3rd grade level notes in the margins of various texts! I can’t speak to all preparation methods, but here are some approaches to consider.
- Read the PMBOK standard. (See PMI.org.) No, really. Read it. You’re certifying on that standard. It’s an odd thought to me to certify on a standard without reading it.
- Use sample test questions. Josh at PMStudent.com provides lots of links to free sample questions on line. I’d recommend that you consider buying a larger test bank to help along your prep.
- Consider a self-study prep course. There are many offerings for self-study prep courses out there. Take a recommendation from a trusted colleague. If you don’t have such a reference, consider PM Prep Cast, a package recommended by many leaders in the online PM community, such as PMStudent.com, PM411.org, and PMPodCast.com. (I have not used Prep Case myself.) Most of these courses provide the needed 35 contact hours, enhance your study effectiveness by summarizing and focusing on key ideas, and do it very economically, sometimes for as little as $100 USD.
- Network in your local PMI chapter. Ask your local chapter about exam prep opportunities. Unfortunately, my local chapter doesn’t provide an online forum through which I could pose the question, but they do provide nice monthly luncheon events that allow for face-to-face networking. My local chapter also periodically hosts exam prep courses.
- Consider a prep course. This is the more expensive end of preparation options. I was lucky; I was able to use corporate training plans and funding to fund my own prep course. The payoff has been good for me and the organization, as I’ve focused on spreading that skill set through my organization since certifying. Many people like the dedicated prep time provided by a classroom. However, among these courses, you’ll have to choose whether you want a boot camp or a prep course. The boot camp (not known by that name, necessarily) would have you attend Monday-Friday and take the examt that Friday afternoon. These courses are test-focused with all sorts of memorization techniques, etc. That’s not my preferred style. Other prep courses simply take you through the PMBOK material, usually with a work book of sorts to facilitate learning and make it easier to consume the full structure of PMBOK. They usually include tips for exam prep and come with some sort of bank of sample test questions. Most of these courses will recommend that you take the course within 2 weeks.
- Use a study group. Consider teaming up with other PMP candidates to study together. You may attend a class together or buy the same self-study course, for example. You may follow class with regular study time, or simply provide each other the support you may need to push through and actually take the exam.
So should you certify? Your choice.
When should you certify? Your choice again.
Will it help in Cottage PM? Check my other posts on that topic.
It’s up to you, just like all your other career decisions. Me, I recommend PMP certification as one stop along your way.
|
The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.
|
