PMPM -- Initiation

Time to kick off our Practical Magic Project Management (PMPM) Working. If you want to work along, pick your objective and expect a new post every other week or so for the next half year. Also, see my offer for deeper content via email -- it's free.

Previously, I talked about the PMI Process Groups. These five areas govern the categories of processes that happen during a project (or working). The first group is Initiation, and while it's one of the least complex, it's also one of the most important. While all the groups overlap, initiation really does need to be front loaded because it defines and authorizes the project.

During initiation, you need to do three things:
  • Develop your project charter
  • Identify your stakeholders
  • Initiate the project

Charter

Your project charter describes, at a high level, what your project is about. It's like a map describing the landscape of your project (the charter is much more a cartography of your project than a chart on paper).

In a corporate environment, the charter is created or approved by the sponsor (the one signing the paychecks) and gives the PM authority to move forward. In reality, this is not always the most formal process, but the information in the charter has to be known at some point and the earlier the better. Even if your magical project is just you, you should still create the project charter. First, because we often think we know what we want, but when pressed there's a lot of vagueness in our goals. Second, we can easily lose sight of our goals over time. For major workings, this is a potentially big problem. Third, we if we need to change direction on our working, its easier to readjust course if you wrote down what you wanted in the first place. Finally, if we haven't clearly stated what we want out of a working, we can't measure whether we were successful or not.

When I say "develop a project charter" I mean that literally. You should write this stuff down and keep it so that you can refer to it later. You will want to review this information from time to time over the coming months to see if anything has changed. There will be other project material you will want to document as well. At minimum, here's what you should put in your project charter:
  • The name of the project and its purpose 
  • High-level requirements and objectives
  • The success criteria
  • Summary budget / milestones
The easiest way to get this is to go through a couple of examples. Let's assume that your BHAG is to start your own business. I once had a side-hustle doing people's resumes so that will be my example business. Or maybe it's solving a problem. For example your housing is unsatisfactory. And of course there's mitigating a risk. Maybe the risk of losing your job.

Here's what goes in the charter:

Name and Purpose
Name: For the first example, this would probably be the name of the business you want to start. Or if you don't know what you'd call your business, you can use a temporary name: Kickass Resume Writing. For the problem, put the solution if you know it (Buy House) or put a positive spin on the problem itself (Better Housing rather than Escape Crap House). For mitigating a risk, put the mitigation rather than the risk (Sustainable Finances).

Purpose: The purpose is your elevator pitch (if you find yourself in an elevator with a prospect, investor, etc. you might have only a minute or to for your pitch). "Make a living helping people reach their employment goals through innovative and personalized resume writing and editing." or "Move into an affordable place in a safe neighborhood." or "Thrive without an income if I need to."

No low-level details, but just the goal at the highest level. Make sure you get the whole goal. Not "help people reach..." but "Make a living helping people reach..." Not "find an affordable place..." but "Move into an affordable place..." I know this might sound pedantic, but really think about this. The purpose is the distillation or essence of the entire working. You want to get it right.

High Level Requirements and Measurable Objectives
This is one stem more detailed than your purpose. Note, that doesn't mean every detail. In fact you may not know every detail right now (nor should you, too much detail at the start can kill a project through over planning). Just put the major things that are required for this working, for example:

  • Have a pipeline of at least 5 clients at all times
  • Automate workflows so that business operations and services take no more than 20 hours a week
  • Two-bedrooms and covered parking
  • Less than $x a month
  • Alternate, flexible sources of income
  • Reduced expenditures without impacting quality of life

And so on. The difference between requirements and objectives is subtle, but requirements are things you need to make the working a success while objectives are the subgoals for the working. What's relevant here is that these must be measurable. "Better place to live" isn't measurable. "Two bedrooms" is. Even if the goal of the working is squishy (like to be happier), you can still create measurable objectives. For example, you could pick some kind of measurement instrument to use to judge any change in your overall happiness. Or you can choose a metric that relates directly to your happiness (number of times you cried, days you couldn't get out of bed, times you binge ate, etc).

Success Criteria
How will you know if your working, you know, worked? This is what the success criteria tells you. The objectives are part of the overall goal. Subgoals, if you will. The success criteria relates back to the core purpose and describes the situation you will find yourself in when your working has been completed.

  • Generating a net profit of $X.XX/month.
  • Settled into my new place and unpacking.
  • Able to tell my employer "take this job and shove it" without fear.
The success criteria should be concrete, but depending on the working you may not want to get overly specific. For example, the goal to be more financially sustainable in case of a job loss. You may not yet know exactly how that needs to happen. You figure you want some side hustles, but you don't know which one will pan out. You will need to be agile and try different things out. So your success criteria shouldn't limit you to any one thing. You need to give your magic some room to work.

Summary Budget and Milestones
Budget: Magical workings may not have detailed budgets in the way that corporate projects do. However, if your working does have a financial cost element, you'll want to note how much you have or how much you need to spend on the endeavor. From business startup costs, to the amount needed to get a new place and move, to the amount of cash you have for spell supplies. However money is not the only thing you need to budget, you also need to get a sense of the amount of energy you want to put into this working. For example:
  • $150 dollars needed
  • Eight hours a week
  • Daily offerings, weekly check-ins, bi-weekly workings, monthly full refresh
The energy and effort you put into this is more important than any money, and you still need to consciously allocate resources for that. If you are embarking on a major working that will take a lot of effort, it's not unreasonable to account for that in your project. And if you do need cash and you don't have it, part of your project will be to raise the cash you need. In this regard your magical working is more like a non-profit project than a corporate one. Raising the funds you need to get things done becomes part of the project.

Milestones: In this case it's probably going to be milestone -- the duration you've given yourself for the working. Really big projects can have several high level milestones, but you always have an end date. Because if you don't, you won't know if you've been successful. And the thing to remember through all of this is that it's about successfully completing the working. So set a reasonable end date based on your goal or if there's a hard end date (you have to move by Autumn) then scale your goal to match. And if you want to go all out and have a goal that's big for the amount of time you've got, well then expect to spend a lot more on your budget... something's gotta give.

Stakeholders

It's not all about you! Or, maybe it is, but it's likely there are other's involved in or affected by your working. Unless you are doing a group working (and honestly, if anyone considers using the PMPM techniques for a major group work, I will be fascinated to hear about it) your team is usually just you. But there are still people who can help, need to be informed, have information you need, or who have a vested interest in the result, in you personally, or in both. These are your stakeholders.


Not that kind of stakeholder!
Basically, you want to capture who's on your list of stakeholders. What their roles are. How they are involved. And how you want to keep them informed. The interesting thing about a magical working is that the stakeholders may not all be corporeal: immediate family, extended family, ancestors, friends, spirits, patron or primary deities, and so on. You can get pretty over the top with this, but keep the goal in mind -- to make sure your relationships are preserved through the process, to inform people as necessary, to ask for and ensure help from your stakeholders as appropriate.

Once again, keep in mind that the point of this is to help you reach the complex result of a major magical working. It's not an exercise in and of itself. Planning is important, but it doesn't get the job done. So give this the time you need, but do it in the interest of starting the work, not planning it. And so it's in that spirit that I hereby officially add an additional process to the Initiation process group specifically for PMPM management:

Initiate the Project

Time to dust off the tools of the trade. Yes, your project should kick off with a full on magical initiation. Of course, how you initiate your project is going to depend on your particular path. There's not a single right way to do this. But consider the following elements:
  • Announcing your intention to dedicate yourself to the project.
  • Stating and codifying your project name, goal, and ending milestone.
  • Asking the blessings of any relevant stakeholders.
A big project deserves a full ritual to kick it off. So don't scrimp on this last, important step. From this point on, you will be an initiate of your own goal, an acolyte of your own working.

The deeper content emails contain some additional details on this material.

Comments

Popular posts from this blog

The Bullet Ephemeris

2017: The Year of Being Agile

EBER Project -- Bullet Ephemeris Redux