Plan-Go-Regroup (or "PGoR") — How to Master Project Productivity to Boost Momentum

This time of year is the calm before the storm–the season of back-to-school, back to industry events, back to projects in high gear.

There’s no silver bullet for dealing with competing demands and the load on your plate, but let me share an uber-simple approach I use to cut through the norms (and nonsense) of corporate protocol, project management gimmicks, and the noise of productivity hype.

I call it Plan-Go-Regroup (or PGoR).

In this last article in my series on team productivity, let me share what PGoR means, why it is needed for today’s knowledge work, and how you and your team can leverage it to push your projects along as efficiently as possible.

Less Is More with Knowledge-Based Project Planning

Knowledge-based projects are nebulous. Unlike a house, the measures of progress and the logical order of the work – like building a foundation, laying bricks, carpentry, landscaping – are not as clear-cut on the surface.

While you can’t see these steps with your eyes, they are there when you create them and make them visible. As a knowledge-based leader or project manager, it’s up to you to define “wins,” create a sense of progress, and build in concrete steps and deliverables that lead to the ultimate goal.

From my extensive experience in running knowledge based projects, I can say with full confidence that you can’t have a successful knowledge-based project unless you break it down. This breakdown is not a one-shot deal, it’s a constant effort to dissect, act, review, and strategize, pushing forward on one “chunk” at a time to get to the next level.?

Too often, teams get stuck when they approach new–and often ill-defined and abstract–projects as a whole and feel overwhelmed. They can spend endless hours trying to plan something that is too big, amorphous, and missing the knowledge that will come from each step along the way.???

That’s where Plan-Go-Regroup (PGoR) comes into play. It’s all about breaking your projects down into chunks (with deliverables and deadlines) and then continuously learning and iterating till you get to where you need to be.

A Refreshed (and Stripped Down) Approach to Agile

Many teams have experience with the Agile approach to project design shares the same philosophy of “sprints” — or, “short, time-boxed periods when a scrum team works to complete a set amount of work. Getting sprints right helps Agile development teams ship better software with fewer headaches.?

I love the image of a “sprint.” It makes me visualize myself or a team darting toward the finish line. A sprint connotes speed, focus, and bursting. In practice, this means intense focus to get to your next versions of draft reports, stages of development, presentations, articles, testing iterations, and so much more. It’s a philosophy centered on getting to the next “step” so you can climb most effectively.

Agile development applies a 6-step model to product development (1. Plan, 2. Design, 3. Develop, 4. Test, 5. Deploy, and 6. Review). While these steps are relevant and applicable to developers, they don’t resonate with many, if not most, knowledge workers in their everyday work and projects. PGoR is a stripped-down, simplified approach more closely aligned with how we run most knowledge-based projects.

PGoR: Breaking it Down?

Let’s dive into what PGoR means and how it can work the most effectively for you and your team.

Plan

If you set out to do anything, like launch a social media campaign, fix your company’s procurement process, implement a new scheduling tool, or anything else, you need an overarching plan. If you’re going solo on the project, you can manage, to a certain degree, by the seat of your pants. However, the need to plan intensifies when team members, other stakeholders, and corporate complexities are involved.

In my work with clients, I develop an overarching plan for the year with high-level goals for long-term and projects and “themes” for my ongoing initiatives. I work with each client team to clarify and recommit to certain outcomes. When we run internal control or audit programs, our plans also define key areas of focus for the year, that is which processes, issues, systems, or concepts our client wants us to put the most time on.

But the most important (and most difficult) part of planning is not the big picture. It's the micro-planning. This means the planning to get to the next logical step (or sprint) of your project. Micro-planning might mean setting deadlines, giving “brain dumps,” booking touch-base meetings, consulting with experts, and producing interim deliverables in the form of memos, reports, outlines, and initial research.

Be extremely cautious of over-planning. Over-planning (and its close cousins overthinking, over-consensus, and overkill) is a challenge I have found in many projects. Project managers and professionals love to plan. Planning is the honeymoon phase of a project before the “stuff” starts hitting the fan, as they say. While most of us (myself included) love to plan to a certain degree, be careful not to get carried away with your planning

I’ve seen detailed, elaborate audit plans or internal control plans created by auditors and accountants (who are natural detail lovers) that have taken months to create. Unfortunately, the company’s priorities shifted before the plans were approved. I once worked for a client who was obsessed with the “perfect” scope of a project and changed the plan so many times that the project could never be finished.

Go

Go is the center of PGoR for a reason. The Go supports the “P” and the “R”. Unlike the many project models that put the emphasis on planning and meetings, PGoR is all about Go. Go is doing, executing, and getting the work done.

Sadly, I have no shortage of examples of projects in the corporate world where Go is forgotten in the whirlwind of meetings, corporate requirements, administration, and busywork. I once worked for a PM that would bug me three times a day for an update. Naturally, I was so busy giving updates, I had no time to do any work. (Thankfully, he didn’t last long on the project.)

On my team, when we’ve agreed on what Go looks like for a 2-week or 4-week sprint and what will be delivered or what the stopping point is, I just let my team members execute. We will review, plan, and regroup again when they reach the next logical step or else are stuck.

Regroup

Regrouping is my personal take on meetings, review cycles, and feedback loops.

I don’t love meetings, but I do love regrouping to gain valuable feedback and share successes. The PGoR philosophy is that you meet (or “regroup”) with your team or team member for two reasons only:

1. When you or your team member arrives at the next logical “step” and requires review.
2. When you or your team members are stuck.

(Of course, this is a bit of an exaggeration. We can’t completely eliminate update meetings and meetings intended to support camaraderie and connection. I do believe in these–within reason!).

In my business, I do have one-on-one meetings scheduled with team members every two weeks. But I often cancel them if the meeting doesn’t meet one of the two criteria. If you trust your team, then there shouldn’t be a need to meet everyday. Anything that creates distraction from GO should be removed from your team’s schedule.

When meeting with my business advisors, editors, or coaches I have used over the years, though I might have bi-weekly check-ins scheduled, but my intention is to meet only when I have a draft of something (like an article, plan, proposal) or I’m stuck (or second guessing or can’t make a decision) on a business decision.

This philosophy is in sharp contrast to the corporate world that has a quasi-religious obsession with weekly (or even daily, in some cases) update meetings. In my opinion, meetings are often held too frequently when there isn’t enough progress to have fulsome, high-value feedback.

Regrouping is about reviewing the work to date, looking out for issues, and capturing feedback to give you momentum. The trick with successful regrouping is to have the right “flow buddy” (or buddies) which is about teaming up with others where you know you have right working chemistry to generate energy, accountability, cross-checking, and idea-bouncing for each other. Finding the right flow buddy adds energy (or calms nerves) on important projects and relieves the psychological burden of having everything on your shoulders.?

Remember that there will be times when you or your team won’t make the progress you hoped for. It happens. If something isn’t working (for whatever reason), regroup, assess the reason why, and change your micro-plan to get to the next step.

Plan (Again)–Iterate

PGR doesn’t stop at one iteration. It keeps going. Think of yourself climbing steps each time pushing to the next level. Each time, you Plan-GO-Regroup when you are stuck or when you reach the next level.

You might not see big results after one PGoR sprint. But when you start to layer it as part of a larger sequence of logical phases in your project, you will see remarkable results over time. For example, for my internal control clients, we always create draft reports with recommendations early in the year, way before the deliverable is due. While the initial drafts might not be anywhere near what they need to be, doing the early sprints allows us to reflect on what we have learned, sharpen our recommendations, and add iterative levels of depth to our reporting and professional advice to our clients.?

If you begin to practice PGoR, your colleagues and clients will wonder how you could grow so much knowledge and depth over time. The secret is iteration, steps, sprints, and layers.

But don’t forget — before you take the next PGoR step again, don’t forget to celebrate in some small way by taking a break, a coffee, a cat video, or saying a good word to your team member.

********

Thank you for catching the latest edition of my Leverage Your Knowledge newsletter. If you haven’t subscribed already, please click at the top. If you really liked this article, please share it with your friends and colleagues.

And if you'd like more from me, I also publish an email newsletter covering personal productivity, personal development, and other topics. You can opt-in here.

If you are interested in my work on documentation, productivity, and workflow best practices, check out my latest book atThe24HourRule.net .