FocusMe Feature - Using Projects to Focus

Problem

Moving from managing action via an email inbox to more task driven lists is a great step forward. However, soon we end up with long lists of tasks that are constantly overdue, causing frustation, and often returning us back to our more comfortable (yet less productive) habits.

Feature

A foundational feature of our Outlook add-in [FocusMe for Outlook] [1] is the ability to organize all objects by project, i.e. tasks, email, appointments, and contacts.  When we break up the work into projects, we can selectively focus on the most important work.  The human mind can only focus on a limited set of things at any one time. Usually, three (3) to five (5) major items. That's one reason why many time management or personal productivity experts suggest planning your "big rocks".  That way you can make sure to carve out time to focus on what is most important.

In this article, I'm not going to try to convince you that working from a project based foundation is the most productive - we can talk about that later. I am going to talk to you about how to create a project based foundation. Many of our customers, once they get the 5D email processing down, struggle with the 'right' number of projects.

Starts with Goals

Objectives or goals (I will be using those terms interchangably) provide a guide for decision making.  If that next email has something to do with your goals, then it is important. If not, it is NOT important, and you can move on to the next item.  Which suggests that you need a way to align that next email with a goal.

[2]

Goals to Projects to Processes

Goals provide a direction, e.g. we will increase our ability to process work orders by 20% this year.  Goals do not suggest a method as to how to achieve the goal.  To accomplish the goal, we break it down into one or more projects.  A project is the method by which work can be bounded, described, planned and tracked.

What is a Project

A project is a bounded body of action, with a distinct starting date and expected end date, focused on delivering specific outcomes.  It is based on a project charter that is described using a number of the following; business case, problem statement, objectives, deliverables, scope, schedule, resource plan, project plan, and risk management plan.  Common tools used in project planning management include work breakdown structures (WBS), program evaluation review technique (PERT) charts or activity network diagrams and timelines and dependencies analysis (GANTT charts), 

Projects Organize Work

There are two fundamental project types to be defined as you set up your project based foundation; 1) deliverable based projects, i.e. the work necessary to deliver a specific outcome, and 2) operational projects, i.e. the work necessary to do the every day repeatable tasks.  We often call the "deliverable based" projects - Improve the Business (ITB) projects, and the "repeatable work" projects - Run the Business (RTB) projects.

ITB projects are often obvious, i.e. each year most folks are required to declare their objectives.  That is, what are the specific things you want to get done in the next year?  Most of the objectives are focused on specific outcomes.  For example, deliver xyz product by Q2 or reduce processing time by 30%.  When the expectations are clearly defined, it is a planning exercise to design and articulate a series of steps, milestones and deliverables to accomplish the outcome.

Usually, those declared objectives are only a portion of the actual work everyone does everyday.

[3]

Objectives Tree

Objective 1 breaks down into projects A and B.  Objective 2 breaks down into projects C and D.  Then all the other work we do is in the "Everything Else" bucket.

We can use RTB projects to describe "Everything Else".  That is, the work processes that are done everyday that may or may not have a direct relationship with the declared annual objectives, they may be the 'other' work that is part of your job.  In order to understand how to evaluate specific requests for action (emails) for your attention, the "everything else" bucket needs to be defined.  This is done by getting an understanding of your processes.

What is a Process

A process is a series of repeatable, value added steps that are performed for a specific purpose. A process differs from a project because the process is bounded using work boundaries rather than time boundaries. We use the SIPOC tool to describe a process at its highest level.

[4]

SIPOC: Supplier, Input, Process, Output, Customer

Defining a process using the SIPOC tool starts with declaring the work boundaries, i.e. where does the process start and where does it end.  Declaring the boundaries shortens conversations regarding the process because everyone knows and is aligned to the box that defines the work.  The next step is to define the parts of the process.  Many experts suggest starting with the customer and working backwards, i.e. define the customer, declare what is delivered to the customer, what steps are taken to deliver the output, what is needed to perform the steps, and who provides what is needed.

The parts of the process are:

• Supplier: the person, group or process that provides an input
• Input: the product(s) or service(s) necessary to execute the process
• Process: the actions necessary to transform inputs into outputs (usually 3 to 7 major steps)
• Output: the product(s) or service(s) delivered by the process
• Customer: the person, group or process that receives the output

In defining the steps of the process, use the 3 to 7 rule, as described earlier.  Processes can be described in hierarchies versus details.  Hierarchies are much easier to understand and to explain than 35 step flowcharts.

All Work is Part of a Process

If your processes aren't obvious, i.e. you've never sat down and defined your work into processes, then I recommend this exercise.

Exercise

1. Find a quiet place to think that has a white board or blank wall.
2. Using a post-it pad, write down every task you perform in a given week.  One task per post-it.
3. Place all of the post-its on the blank surface, don't worry about order.
4. Move all of the post-its into groups.
5. The resulting groups are your processes.  Hint: I suspect you'll end up with 3 to 5ish groups.
6. Give each group a name - these are your RTB projects.

Here is an example of the projects that I've defined (a subset of my projects in FocusMe):

[5]

Project Hierarchy Example

Each blue box represents a goal or operational grouping, and the projects (green boxes) are numbered to reflect that they belong within the hierarchy (number range).  FocusMe supports Workspaces, which can also be used to group projects and view them visually in the "All Projects" dialog.

Client SOWs (Statement of Work) are specific jobs we've scoped and performed - which support our professional services goal.  The EvCC Partner and Government groupings represent similar work.  Non-Profits represent volunteer work.  Back Office represents specific processes that are performed as part of Ceptara's operations - which represents much of the work that is necessary, however, isn't directly billable.

End Notes

When all of the projects have been defined so that they 'cover' all of the meaningful work that you do. Any new email that doesn't fall into a project should give you pause.  You may discover that there are many requests that come in that defocus you from what you think is important.  In that case, what a great place to start reclaiming your time.