The Benefits of Career-Oriented Education

Here’s an extract of an interview I did for Central Connecticut State University’s Continuing Education Blog.

Tell us about PM College. What educational opportunities do you offer?

PM College creates and delivers learning for strategy execution topics such as strategy, leadership, portfolio and project management.

What sets you apart from other schools or organizations offering career-oriented training programs?

Our programs don’t simply deliver pre-packaged content. We work with clients to tailor learning to their organization’s needs and opportunities. Furthermore, our clients leverage our research to assess their talent’s skills and competencies, which allows us to design targeted development experiences (e.g., training, coaching/mentoring, job rotation).

How important are training/educational programs like yours to the success of an individual or an organization?

Most clients use learning as a platform to support those taking on new roles. Our best clients use training, assessment and mentoring services…

Please read the rest of my interview here.

Agile Prep for the PMI-ACP®: Tips from Personal Experience

PM College has upped its agile game over the last few months. We now have a full suite of offerings across a variety of agile approaches: Scrum, XP, Kanban, Lean, and different ways to combine them for success, including SAFe or agile certifications.  As I reviewed our course offerings, I became curious and followed a link to the requirements for PMI’s Agile Certified Practitioner (PMI-ACP®) certification. I’ve been in and around agile for quite a while now, from the first stirrings of what became SAP’s Agile Business Add-on to ASAP, to using VersionOne daily as a program recovery manager, to now teaching our Introduction to Agile course. I figured that if I was eligible to apply, perhaps I could bone up and pass the exam. My experience with it, I figured, could benefit the training managers who rely on us, as well as their course participants.

Over the next few posts, I’ll walk through some of what I found when applying for, then studying for, the PM-ACP exam. This post will be an overview, then I’ll dig in a bit more to specific agile domains.

First, it turned out that I was just in time: my live project experience would’ve aged out in six months! The application process was relatively smooth—though waiting for an audit decision is always nerve-wracking—but I was indeed eligible. If you’re like me, a practitioner who gets sucked into management every so often, I suggest applying straightaway after you complete a relevant agile project.

Because I had just built an agile course, I figured that I was ahead of the game when it came to studying. I had a lot of material about the elements of Scrum, XP, and other agile and iterative methodologies. Therefore, it was easy for me build a study sheet and practice questions. After a few rounds of practice exams—gradually getting my percentage correct into the mid-90s—I figured I was good to go.

Well, it didn’t feel like it when I sat before that Prometrix screen! I was faced by a series of situational questions on the application of agile principle, value-driven delivery, stakeholder engagement, and team performance. The emphasis on these topics wasn’t a surprise: the PMI-ACP exam outline notes that they make up 69% of one’s exam score. The cleverness of the questions was a surprise, however.

Therein lies the heart of my first suggestion in this series: don’t expect cramming to be successful. While prep exams are useful to ensure you know your terms, the exam doesn’t reward simple rote learning. I had a head crammed full of agile tools and methods, but I found few questions amenable to regurgitating those facts “fill in the blank” or “this statement defines” answers. In question after question, I had to walk through the brief agile scenarios, walk through them, and then apply my agile experience to select the right answer. My take is that inexperienced agile practitioners will struggle with large sections of this exam, largely because they will not be able to put themselves into the agile dilemmas presented. This is a certification that requires some agility in preparation, as well as in response to the questions. And that’s how it should be.

Stay tuned for more tips on agile certification prep, coming soon.

Quote of the day: Albert Einstein

Try not to become a person of success, but rather try to become a person of value. — Albert Einstein

Quote of the day: Thomas Jefferson

I never consider a difference of opinion in politics, in religion, in philosophy, as cause for withdrawing from a friend. —Thomas Jefferson

The Bad Apple Does Spoil the Bunch

When I teach Strategies for Stakeholder Engagement, I get many questions about dealing with tough cases, problem children…yes, bad apples. Organizational theory assumes that group dynamics make that old saw obsolete: a group can send any bad apple to the bottom of the barrel. However, recent research suggests that a team that tolerates a bad member runs the risk of poisoning itself.

  • Invariably, groups that had the bad apple would perform worse….
  • Even worse, other team members began to take on the bad apple’s characteristics….
  • What they found, in short, is that the worst team member is the best predictor of how any team performs….

The situation isn’t hopeless–there was one group who had a strong leader that diffuse these situations–but it requires skills in a specific leadership style. And of course, there is one approach that does get to the root cause.

Still, the obvious solution is to address the problem at its source: get rid of the bad apple.

Even if it’s you.

As they say, read and listen to, the whole thing.

Quote of the day: Abraham Lincoln

Honest Abe knew not to overpromise and underdeliver.

We must not promise what we ought not, lest we be called on to perform what we cannot. — Abraham Lincoln

Troubled Projects and Root Causes

UPDATE: Our Troubled Projects webinar is scheduled for 12 April 2016. Register here.

Our colleagues at PM Solutions just put out another great white paper: Troubled Projects? Key Strategies for Quick Turnarounds. It synthesizes multiple project research studies into a straightforward approach to project review and recovery. Which, not so coincidentally, is the title of our course on the topic: Project Review and Recovery. While we wait for our upcoming webinar, I thought I’d add a few notes about the paper’s findings.

Right off the bat, the section on “The Bad News” highlights two perspectives on the root causes of troubled projects. The first comes from the CHAOS studies from the Standish Groups, which focused on information technology projects. In this view, the two factors that drive project failure are a lack of executive involvement or a lack of stakeholder involvement. The second comes from our own research, Strategies for Project Recovery. These prescriptions are more specific, pointing to poor requirements management, resource issues, scheduling problems, inaccurate planning, and missed or mismanaged risks.

Which set of root causes resonate with you? Do you gravitate towards the “softer side” approach, or would you pick with the one that focuses on traditional “hard” project management themes? We choose not to decide between the two diagnoses, noting that:

These risks align precisely with the fundamental strengths of project management: stakeholder management, planning, scheduling, and risk management, and also suggest that executives and stakeholders have not been involved at an early enough stage.

There’s more to not choosing between these two groups than simply saying “both are true.” It reflects the fact that we come with different perspectives on causation and influence in projects. I gravitate to leadership-driven causes. Missing executives and poorly engaged stakeholders make sense as prime suspects for project failure. I’ve lost count of the times I’ve seen these suspects drive poor planning, scheduling, and risk management outcomes. For example, executives can simply ignore project progress or forecast reporting, stakeholders may resist engagement, or managers may release only lesser-quality resources to a project.

However, re-reading this white paper reminded me that the causation can run the other direction. Let’s just look at one of my examples above: executives who ignore project progress or forecast reporting. Many project managers lament this situation. They say “that’s the typical disconnected executive mindset…they don’t appreciate or get project management.”

In such cases, the project manager should look at him or herself first. After all, who is responsible for ensuring that communications are understood? Isn’t it both sender and receiver? Did she know that many executives don’t understand or don’t like much project reporting? Has he asked the executive why she’s neither attending status meetings nor attentive when there? In many cases, senior leaders will give quite direct and actionable feedback: usually that project reporting is obscure and overly elaborate. Your most important stakeholders disengaged because your work product wasn’t fit for use: its receivers couldn’t or didn’t value it.

%d bloggers like this: