PMPM -- Planning Part One

First of all, I need to stop pretending that I'm going to spend time writing blog posts while I'm traveling for work. Between the meetings I'm there for, keeping on top of stuff back at the office, professional dinners with lots of professional drinking, and cramming in sightseeing and shopping in every spare minute -- well, let's just say that you are all awesome, but not as awesome as Tokyo.

Also, I've got some additional responsibilities in my professional life... the scary but good kind that will stretch me personally and professionally and, with luck and effort, reward me in kind. This means that I'm even busier and under a brighter spotlight than before. Still, we've started something important here and I refuse to let it drop.

So, it's been a couple of weeks since you kicked off your major PMPM working and you know at a high level what, where, and how you will achieve your goal. Have you initiated your project? If so, it's time to get going. But here I give you an important warning:

DO NOT WAIT until the planning is complete before getting started.


If you recall from my intro post on the process groups, the planning phase happens after the very start of the project launch and continues through the final stages. Of course there's more planning at the start and it tapers off through the course of the project. But you do not wait to start the project until you've all done planning. Let me assure you that is a sure path to failure because the planning will never really be done. It can't be, because the process of actually doing the working changes the plan as you go. That's why you need to get started right away, because your first steps will help direct the work that comes after. Project planning is a process, not an event. You don't just do it, you continue the planning process, adjusting and refining, over the life of the project.

I know some of you are wondering why bother planning at all. In fact, there are times when making a detailed plan seems counterproductive. Instead you need to try out a bunch of ideas to see what actually seems to be working. I direct you to this extremely detailed post on the agile methodology. However this type of project management still includes planning. It's just a more flexible type of planning that allows you to change course more easily and rapidly.

But whether or not you will be using agile methods, you should still have some kind of plan in place for your working. If for no other reason than for major workings, the kind that take months -- even years -- to complete, you need a whole lot of discipline and focus. A plan helps you do that.

In my experience, you get the biggest benefit when you combine elements of classic project management along with agile methods. You let the plan serve the goal, and not the other way around. The sections below, include some elements of both that I find work well for the type of 'life-change' workings that tend to be on all our lists.

Integration
Before anything else, you have to realize that the plan is an integral part of the working. It's not separate from it. You have to make a commitment to revisit your plan throughout the project. I recommend deciding up front how you will do this. Because, shit happens. Life happens. Chaos happens. But what's not going to happen is you meeting your goal if you don't keep it in mind. Your charter and your plan work together as a operating manual for your working. They keep you on track through the many months of actually doing the work. You don't just set and forget.

In an agile process, you do this every sprint. You revisit your plan and just give it a sanity check. Do you need to add stuff, remove it, change it outright? Do you need to re-prioritize things in the plan?

For a year long working, checking back with your project plan monthly makes a lot of sense. Toward the end of your project, you may just review, validating that you are reaching your goal. But at the start, you will be digging deeper, expanding and refining and even changing your plan as circumstances dictate. Decide on your re-plan day (every first Saturday? the new moon? the 15th of the month?) and record it someplace that you will remember. Give yourself a reminder if you need it. Most of us are drowning in technology to help us remember things, so use it.

Process Groups and Knowledge Areas
In formal project management, there are the five process groups (Initiating, Planning, Executing, Monitoring, Closing) -- we discussed these before. There are also 10 "knowledge areas" (which sounds like a term invented by committee). The knowledge areas include things like scope, time, cost, quality, risk... some of them more relevant to our process than others. For the PMPM process, I prefer the term Focus Areas because if there's one thing magic requires, it's focus. And for a major working, one that lasts many months, there's a lot of things you have to focus on.

The complexity of the PMI process here is intense. There's a huge grid with various processes in different sections and lots of dependencies, deliverables, and so on. Part of my prep for the PMP exam was memorizing the entire chart. We will not be going there! The thing you need to keep in mind is that for each part of your working there will be certain things you need to focus on. And those things reappear through the working. That's key. You don't just think about your working once at the start, you continue to reapply your focus (both magically and mundanely) over the months.

When you're planning and re-planning -- I have to keep emphasizing that you don't just do this once at the start -- you need to focus on several different areas of your working. This post discusses the first, and most important, to give yourself momentum at the start:



The Scope
In your PMPM charter, you identified the high-level requirements and objectives. Those are the things you need to complete the working and the high level goals of the working. This is where you take those items and break them down another level into smaller detailed requirements and sub-goals. In the Initiation post, one example was a working to "Make a living helping people reach their employment goals through innovative and personalized resume writing and editing." If one of your objectives for this working is:
  • Automate workflows so that business operations and services take no more than 20 hours a week
Well, that's a good objective, but it's not exactly actionable, is it?

So you need to think about the components of that particular goal.
  • Automate workflows so that business operations and services take no more than 20 hours a week
    • Contract a website that lists services and allows users to sign up and purchase online
    • Create an email account for the business and setup automated sorting for incoming email
    • Buy a piece of small business accounting software to track income and expenditures
    • Create templates for common client communications that can be reused
    • Create a sigil for smooth pathways and easy interactions 
    • Set up an altar above your work desk where you can regularly leave offerings for relevant spiritual stakeholder
And if your house moving working requires: "Safe, walkable neighborhood" then take it to the next level (Eastside or Lakeview neighborhood, within 5 min walk from grocery and dry cleaners, near bus stop, on a small side street, with a wooded area nearby for magical working)

Depending on the the granularity of the original requirement or objective, you may need to really break it down or just come up with a couple of sub-goals. And from an agile perspective, if your charter was kind of vague, you need to come up with research goals. If your working is to "be happier" you may not know how to accomplish that right away. OK, you almost certainly don't know what it will take -- humans are notoriously terrible at this particular exercise. So you go agile. You don't know quite what happier means and you certainly don't know what's required to get you there. So you create a list of experiments to try and plan to apply the results to your measurement method (see the previous post).

In any case, the point is to take the high-level stuff down a notch to the next level. Once you do that you will have effectively defined the scope of your project. You will have a better sense of what's necessary and what's nice to have, what you need to do and what you do not. Please believe me that being clear about what you don't need to do or even what you shouldn't do to successfully complete the working is as important -- maybe even more important -- than knowing what you should do.

Because everything has a cost. And the most damaging cost in terms of making your workings come to fruition is opportunity cost. When you are spending energy, especially magical energy, doing unnecessary things or outright wrong things, that's energy you can't spend on the right things. It's a lost opportunity.

Not to mention that when we're looking at changing beliefs, thoughts, or behaviors, believing/thinking/doing the right things means first stopping the wrong ones. And your magical working is going to require belief change, thought change, and behavior change. Because, hello, it's a magical working, not just a business plan or to do list.

We'll be coming back to this when we get into project execution. For now, make sure your scope reflects as much of what you need to do as you know at this point and none of what you don't need to do.

You should also be able to take any one of those items and turn it into small doable tasks. But note, you don't have to figure out all the tasks for the entire scope at this point. That's going a step too far at this stage and can really bog down your planning (see warning number one -- don't wait to start).

Once you have your scope, then put the items in rough order. Figure out where there are broad dependencies between items (you probably need an email setup before your website is done). Determine if some items are more important than others (safe neighborhood is number one, bus stop and bike path are number two). Identify the most likely experiments to try (attend a play, go to a club).

Sometimes the order will be simple: you need to save a down payment before you sign a contract. Sometimes it's more complex: you need the email before the website is done, but not before it's started. Sometimes you just follow your gut. You don't have to over-analyze it. Just get your sub-goals roughly listed so that you know where the starting point is.

If you stack rank the entire list, you have an agile backlog that you can work through. Or maybe instead you have three high priority items to start in parallel now and some lower ones to start later. Or maybe two urgent things, followed by mid range and long term ones. Your actual working should dictate what makes since in each circumstance. But we're looking at months of working on this goal, it's not all going to be done at once.

There are other aspects to the plan (the timing of things, the budget you have) all of which are a more granular breakdown of the things in your charter.  We'll be digging into these in the next post, because you do want to include them in your planning. But before we go any further, there's something you have to do right now...

Start.

Take the first requirement, figure out the first thing to do to get there and do it. If you can't do it because it's too hard, long, or big break in into smaller pieces and then do the first of those. If you still can't do it, rinse and repeat. Here are some examples of tiny first steps that are doable right now:

  • Make a sigil for the first item on your list. Incorporate the symbols that are meaningful for your project (go see Gordon for great suggestions -- he's the master of this)
  • Make a single call to source something you need
  • Google "how to <your requirement here>" -- for example, how to build a professional website, how to get a small business loan, how to find a safe neighborhood in your-city
  • Do one small symbolic thing that represents the goal (designate a "moving fund" jar and put a dollar in it, label a folder customer list and put it on your desk, find the most unhealthy thing in your kitchen right now and throw it out)
Getting big things done rarely requires doing big things. It usually requires doing tiny things, every day, one after another or over and over until the big thing is done. It's water wearing the stone, not a deluge. And if there are rare and glorious moments of deluge the water only knows where to go because of the previous patient wearing of the channel. If you don't prepare the channel, you get a flood and drowned by too much success too fast.

So take your first tiny steps, one at a time, while you keep up the planning process.




Comments

Popular posts from this blog

The Year of Being Agile -- Agile Risk Management, Informed Intuition, the Hard Part

The End of the Summer - and Things to Come

Project Ivy: End Game