Project Management

Taking the Plunge

In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog


Recent Posts

Festina Lente

Everything Old is New Again

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Festina Lente

Categories: communication

My working title for this post bounced back and forth between 'Translation Please!', 'Lost in Translation,' and 'The Telephone Game.'  Let me explain why knowing this matters.

I'm currently studying for the Agile Hybrid Project Pro micro-credential (I told you this wouldn't be about preparing for the PMI-ACP exam), and came across the concept "Go slow to go fast" in the recommended reading.  This was in line with what I was planning to write about, so I asked my friend, Google, for a little more information on this quote.  Google didn't have much to say about the supposed "warrior-leaders studying the martial arts," but I was directed to a related quote by Augustus - festina lente, meaning "make haste slowly."  Knowing this brings us closer to understanding the actual title and working titles of this post.

At two of the companies I've worked for, executive leadership has used motivational concepts and phrases, among other things, to help motivate employees during transitional periods.  It seems that somewhere between the message that is delivered and the message that is received, something is being lost. 

At Company A, a change in leadership brought a new slogan - "Fast Speed."  My first thought was, "What the heck does that mean?"  Things devolved from there.  On the plus side, it was memorable and received a lot of buzz, but opinions were definitely split on the effectiveness of the slogan.

Compare this with Company B, where there were eight buzz words.  Two of them stood out, for different reasons - 'Zoom' and 'Focus.'  I'll let you guess which one received the most emphasis.

It's easy to say that the burden of communication is on the person who is speaking, but let's not forget Active Listening.  Company A was a little top-heavy and it was difficult to get an answer on what was meant by Fast Speed.  Company B was less top-heavy, but there was still a little filtering taking place as the message trickled down through the organization.  What started as an emphasis on all eight slogans became perceived as celebrating the ability of individuals to Zoom without consideration for the other seven slogans.  Reality is probably somewhere in between, with plenty of Focus taking place, just not being recognized for its contribution (which can be interpreted as a demonstration of which slogans are valued more, but may not be intentional).

I have no doubt that executives and project managers often speak different languages, even if it sounds like both parties are speaking English.  Early in my career, I was asked for a project plan.  I could have prepared a killer project management plan - I had a template ready to go, with risk, cost, schedule, change, etc. management plans (a book nobody wanted to read).  What was wanted was a project schedule (WBS with a Gantt chart).  Another time, I was asked to put together a Gantt chart for someone else's project that I didn't know anything about.  After a lot of work, I found out that what was wanted was a status report with milestones and a roadmap.

Sometimes, the message gets changed between the time that it is given and the time that you receive it.  Other times, you might think you're communicating, but the words being used don't mean the same thing to all parties.  The onus of understanding is only partly on the communicator - the receiving party should also take a little time to focus and understand the message before zooming into action.  Festina lente.

Posted on: September 14, 2021 01:37 AM | Permalink | Comments (5)

Everything Old is New Again

Categories: Agile, Exam Prep

In the spirit of the reason I started this blog - preparing for the PMP exam in 2008 - I’ll start this post with my latest certification path - PMI-ACP.  To quote myself from that first blog post:

“The important thing to keep in mind when preparing for the PMP exam is that just getting started is a step in the right direction.”

Fast forwarding to the present, I was recently approved to schedule the PMI-ACP exam (the application was soooo much easier than the PMP exam application), so now it’s time to hit the books, or more accurately:

  • An exam prep book (I’m looking for a good one.  Recommendations, anyone?)
  • An online prep-class from Udemy (we always need more PDUs!)
  • Flash cards
  • Practice exams

Can I claim PDUs for reading the exam prep book?  Hmm…

February sounds like a good time to take the exam, but that would put my renewal at about the same time as my PMP and annual membership renewal.  It might be good to stagger these, a little.  Once I get the exam prep book, I’ll put together a study plan and set a realistic date.

I’m thinking I’ll do us all a favor and NOT make my next several posts about preparing for the PMI-ACP exam.  It may come up, but I have a few other ideas that might prove more interesting.

Posted on: September 02, 2021 11:19 PM | Permalink | Comments (4)

What's in Your Project Management Tool Belt?

Categories: Project Management

What does a Project Manager need to know about Project Management?

Don't worry, this isn't a job interview; it's okay to say "It depends."

It seems like, once you get past a core set of skills, there is a lot of variation, between companies, when it comes to what is expected of a Project Manager.  I've also noticed a lot of variation in what is expected of a Project Manager from different employees within the same company.  A starting point might include the following:

  • Communicating effectively across all levels of an organization
  • Facilitating meetings
  • Documenting and managing project tasks/schedule (often using software that displays a WBS and Gantt chart)
  • Identifying/managing risks and issues
  • Managing project scope changes
  • Creating status reports/dashboards
  • Various "soft" skills

The longer you work as a Project Manager, the more important it becomes that you understand the nature of work and how it can be accomplished.  You also need to understand the culture and structure of the organization you work in to choose the best approach to successfully accomplish the work to be performed.  Here are some areas to study:

  • Agile/Kanban/Lean
  • Scaling Agile
  • DevOps
  • Waterfall (in its various forms)
  • Six Sigma
  • Organizational Change Management
  • Project Portfolio Management
  • Benefits Realization Management

As a PMP, I feel a little obligated to say that you need to know the PMBOK, but I also feel the need to point out that it is the PMBOK Guide, emphasis on 'Guide.'  There are also other approaches, such as Prince2, that may be more relevant to your career.  Knowing what is relevant to your career is more important than using the topics I've mentioned as a checklist for things you need to know.

The point of having a tool belt is to be able to know how to use the tools you need based on the situation you are in, not to use every tool you have.  So, here's a question for the rest of you - reply in the comments section - what else, in your experience, do Project Managers need to know?

Posted on: March 21, 2019 05:10 PM | Permalink | Comments (15)

Scale Your Product Owners

Categories: Agile

A few weeks ago, I was fortunate to be able to attend the [email protected] certification course, taught by Jeff Sutherland and Kim Antelo.  There is a lot, from this class, that I could write about, but I'd like to focus on just one topic that I think is critical to effective Scrum, Scrum transformations, and scaling Scrum:  Product Owners.


If you have multiple Scrum teams that are working on different features for the same product, you need to scale your Product Owners.  I'll explain what I mean by that in a moment.


When you take the Certified Scrum Master (CSM) class, you learn the basics of leading an individual Scrum team as the Scrum Master (leading in the sense of a servant leader, not a manager).  When you take the Certified Scrum Product Owner (CSPO) class, you learn the basics of participating on an individual Scrum team as the Product Owner.  Neither class goes in depth into what to do when multiple Scrum teams are working on different features of the same project.   I wouldn't expect them to; it's not the purpose of either class.


You might hear mention of Scrum of Scrums in the CSM class.  If you're not familiar with the concept, a lot of people think of it as a combined standup meeting where a representative from each Scrum team reports on his or her piece of the product.  They don't go into as much detail, and they only bring up blockers that can't be addressed at the team level. 


In [email protected], the Scrum of Scrums is actually what you might call the Team of Teams.  The meeting, described above, is called the Scaled Daily Scrum.  Do you see what is missing?  If you're going to scale your Scrum teams, you need to scale your Product Owners.  Why wouldn't you have a scaled, refined, prioritized backlog, a roadmap that covers the features that each Product Owner is responsible for, and a team of Product Owners that is responsible for these things?  This is called the MetaScrum, and it is sometimes missing when a company is trying to adopt Scrum.  Without this, your Scrum of Scrums, whether you consider it a team or a meeting, will be less effective, which means you won't be delivering value as quickly as you could be.


For more information on the terms I've mentioned and how to scale both Scrum teams and Product Owner teams, please refer to the [email protected] Guide -

Posted on: March 01, 2019 04:17 AM | Permalink | Comments (6)

When is a Good Idea a Bad Idea?

Categories: Project Management

Have you ever had a really good idea that you were excited about, that you couldn't wait to start, only to have it go nowhere?  I've had more than one hobby that went into limbo and became an "interest" because it was a good idea, but the timing wasn't right.  I'm sure I'll get back to one or more of them, but now is not the time.

Have you noticed that we have similar behaviors at work, often with one difference?  A good idea becomes a project and resources are assigned to it, but when it loses priority it never actually stops.  Nobody says, "This isn't a good idea right now."  Instead, people work on it when they have time, assuming it doesn't impact anything.  Don't get me started on multi-tasking… but multi-tasking isn't the only concern.  Activities involved in both testing and implementation tie up people and resources, and not just those performing the work.  A desktop software implementation can distract people working on other projects, as well as resulting in issues that can stop work until they are resolved.

This post is only partly about organizational multi-tasking and project prioritization.  It's also about efficiency, or at least the illusion of efficiency.

My work is primarily in IT, so there will be an IT focus in what I write, but I will try to tie it back to the business, as well.

IT is expected to be efficient.  It often feels like people think efficient IT means working on all requested projects and getting them all done on time and within budget.  That doesn't feel very efficient to me.  Can you see the connection to "good ideas?"

A company can have employees working on a lot of projects.  Some strategic, some compliance enabling, others required to keep the lights on, and then a bunch of good ideas.  The company can hire more people and buy more equipment to keep everyone working efficiently on all of the projects.  Eventually, however, there will be conflicts.  A natural bottleneck occurs with testing and implementation.  When you have interdependent systems, your dependencies limit the amount of separate changes that you can effectively test or go live with at any given time.  If you really want IT to be efficient, you need to insert a bottleneck in the decision-making process in order to limit the amount of work in the project pipeline to match the amount of output your organization is able to effectively deliver.  (Think of Portfolio Management as one step toward making this happen.) Over time, you may be able to enlarge the testing and implementation bottleneck, at which point, you will be able to increase the amount of work in the pipeline.

So far, we've just been talking about IT projects.  Now, consider a company, like the one I work for, that has global markets.  This means global marketing projects and global sales events that also impact the web, mobile, CRM, and ERP systems, among others.  The windows for testing and production implementations just got a lot smaller.  Should these activities be considered as part of portfolio management? 

Is that good idea you're working on a good idea right now, or would it be a better idea to work on it when it is a better fit with other priorities your organization is pursuing?  Or, not at all?  Does being a good idea automatically mean that it deserves to be executed?

Posted on: July 22, 2017 04:40 PM | Permalink | Comments (24)

"Man prefers to believe what he prefers to be true."

- Francis Bacon



Vendor Events

See all Vendor Events