The 5Ps: Achieving Focus in Any Endeavor

Always have a plan. Always.

A great, simple, framework for any plan is the 5Ps:  Purpose, Principles, Priorities, People, and Plan. This framework applies to software development projects, job searches, building a garden, or a phase in your life. I have personally found the 5Ps a useful tool for small projects (e.g. prepping for a VC demo/presentation) as well as large-scale projects that include 1,000s of people.

The 5Ps : Purpose, Principles, Priorities, People, and Plan

J Allard taught me the 5Ps while we were building Microsoft’s Internet Information Server (IIS):

• Purpose: What is the point of this plan? Why do we exist? Why are we in business? Where do we want to be in the future? What will we deliver?
• Principles: What are the non-negotiable rules and key strategies? How will we act? What are our tenets?
• Priorities: In what order do we do things? How much mass or energy do we apply to each element of the plan? What is not important?
• People: Who’s accountable for every key part of the plan? Who’s just an observer?
• Plan: What’s the end date? How are we going to stage and tackle solving the problems? What are the intermediate milestones, dates, and forcing functions that are required to complete the plan?

I cover each of these below. To illustrate each I use how a group of us used the 5Ps when building the Windows Phone 7 Developer Experience.  The extracts below are taken from a plan document that was shared and referenced by the entire team during planning as well as execution.

Purpose

Your purpose answers one or more of the following questions:

• What is the point of the plan?
• Why do we exist?
• What is the customer experience we want to create?
• Why are we in business?
• Where do we want to be in the future?
• What will we deliver?

For the Windows Phone 7 developer experience our purpose was:

Our purpose is to harness the energy, talent, and attention of developers and designers with a platform and ecosystem that delivers on the developer experience end to end; that, combined with the phone’s end-user experience, results in a winning virtuous cycle.

When you write down your purpose try to be concise. The example above may be too long, but for a large project like WP7, it worked fine.

Here’s another example to illustrate:  I helped my 17-year-old daughter write her plan for a summer internship. I taught her the 5Ps and for her “Purpose” she wrote:

To get real experience with and learn about the medical science over the summer.

You may already have a “Purpose” for your project. Some people call it a “Mission”.

Principles

The Principles you debate and agree on will enable everyone involved to know how to behave throughout the endeavor. They are laws that shall be followed by everyone involved. The word principle is synonymous with tenet.

• What are the non-negotiable rules and key strategies?
• How will we behave?
• How will we treat and interact with others?

As with our purpose, we wrote down a set of principles for “wp7dev”; tenets or rules we would live by as we did our daily work:

• Every decision we make must be made mindful of the effect on end-users.
• We will do a few things and do them very, very well; we are better off not having a capability than doing it poorly. There are always future versions.
• No API will be created or documented without a clear use case; “build it and they will come” APIs almost always do nothing but create bad legacy.
• We will build on the shoulders of giants; where possible integrate instead of create.
• We will strive to not show our organizational boundaries to developers.

Call them mantras if you want. A good leader will continually re-enforce these principles (by leading by example and through written & oral communications) with the team.

For more on how to effectively craft Principles, see my Tenets post (Principle and Tenet are synonyms).

Priorities

The most critical tool you can give small independent teams of creative people is a list of clear Priorities. Such a list, combined with a set of Principles, helps people make independent decisions rapidly knowing that they can justify those decisions later on.

Priorities indicate two things: The order in which things get done and the mass applied to each. Higher priority parts of a plan get done first with more people focused on them. Lower priority things get done later with fewer resources applied until higher priority things are done.

For the Windows Phone developer experience, we had several things to prioritize.  For example, we prioritized the developer segments we would target:

1. Consumer Developer – Pro Devs who build products that are sold directly or given out for free to general public end-users.
2. Non-Pro Developer – Non-Pro Developers building products for academic/personal use.
3. In-ROM Developer – Pro Devs who build products & technologies that are sold to mobile operators or device manufacturers.
4. Enterprise Developer –Pro Devs who build apps & technologies that are sold to corporate clients and businesses.
5. IT Developer – Pro Devs who build apps & technologies that are only for use by their own corporation.

It may be pedantic, but it’s important to call out that the way you read a prioritized list like this is top-down.  Priority 1 is a higher priority than priority 3, but that does not mean priority 3 isn’t important. It’s also worth calling out that prioritization is temporal.  Overtime (e.g. for subsequent releases) it is perfectly fine to change priorities.

Creating this list within the context of the overall Windows Phone strategy was fairly easy. Getting people to understand it and live it was harder. But once it was understood individuals, feature crews, and other groups could use this list to more easily identify which decisions & issues were in the 90% bucket and which were in the 10% bucket.

People

Writing down who is responsible for what (and as importantly, not responsible for what) will help ensure everyone knows who’s accountable for every key part of the plan. It is important to focus on People and not groups or teams.

There are tons of frameworks/tools for clarifying roles & responsibilities. They can all be made to work, as long as you don’t overdo it.  To illustrate how to think through the people part of the 5Ps, I’ll use RACI:

• Responsible – The individual(s) who do the work to achieve the deliverable.
• Approver – The one (and only one!) person who is ultimately answerable for the correct and thorough completion of the deliverable.  (I don’t like using “Accountable” for this because accountable is an overloaded word and I want everyone to “feel” accountable).
• Consulted – Those whose opinions are sought; generally via two-way communication.
• Informed – Those who are neither responsible, accountable, or consulted; but told.

Use whatever tool you want, but you do need to explicitly write down the names of individuals for each part of your plan.  Avoid naming groups such as partners; if a plan can’t identify a person the plan is soft, and there better be a date on the Plan (see below) that makes it clear when the person will be identified.

It is really helpful and liberating to also write down explicitly who’s NOT accountable.  The “Informed” bucket is great for this. If Sally is responsible for widget A and widget A has no dependencies with widget B Sally will actually find it liberating if she knows the people responsible for widget B don’t expect or want her opinion or help.

Plan

The Plan is a top-down schedule. It shows how you are going to stage work and tackle solving the problems. In the framework of the 5Ps the plan should be “top-down” and not “bottom-up”; a detailed bottom-up schedule should be used to determine whether work should be cut (using your principles & prioritization as a guide) or scoped back or (never happens) added.

A top-down schedule ALWAYS has an end date (even if, when you write it, the date is wildly conservative or aggressive). The schedule is best visualized as a timeline that starts with today and ends at the “done date”.  For Windows Phone 7 the end date was “Launch in the Fall of 2010”. The start date was May 2009.

The top-down schedule should include as many known or anticipated dates as possible. Dates that are immutable like holidays and conferences should be included. These are dates you know you will have to workaround. I’m always stunned when I see people haven’t put them on the timeline.

The plan should also include important milestones. For example, for my daughter’s summer internship, we agreed she should have a “mid-summer” check-in where she would meet with her boss.

For WP7 the top-down schedule was relatively easy to create. We knew the overall top-down schedule for Windows Phone itself so that provided boundaries. We also knew there would be a MIX conference in the spring of 2010. This gave us a great forcing function. Invite thousands of people to a big event and you better get your sh** together (events are great forcing functions for engineering teams to get their sh** together).

See also: Have a Plan (With Dates)

Updating a 5Ps Plan

Dwight D. Eisenhower was famous for saying “No battle was ever won according to plan, but no battle was ever won without one.”  Or, as Mike Tyson put it “Everyone has a plan until they get punched in the mouth.”

As progress is made against a 5Ps plan, things will be learned. Update the plan document accordingly and share the changes with the People.

Experience shows different parts of a plan change more over time than others. Purpose rarely changes. The Principles are, by definition, supposed to be long-term and thus also rarely change. Priorities are more fungible. In an ideal world People would stay relatively static, but in the real world change as teams grow or people move to other jobs. The Plan part of the 5Ps changes frequently (but hopefully not the end date).

I’ve applied the 5Ps for personal and professional projects of all sizes. I’ve coached hundreds of people on using it to great effect. But remember: 5Ps is just a tool. There are other tools you can use to achieve similar ends. Like all tools don’t over-use them.

Related posts on planning, focus, and decision making:

• Have a Plan
• Have a Plan (With Dates)
• Tools to Achieve Clarity of Thought
• 90% of the Decisions you make Don’t Matter
• CBTO: Customers, Business, Technology, and Organization