Working Smarter : Project Management

What Happens When the Top Dog Leaves?

Rich — Fri, 01 May 2009 18:45:00 GMT

Departing employees can have a tremendous impact on an organization if it is not properly prepared and equipped to handle it – especially if the employee is one of the “Top Dogs.”

How the departure affects your productivity

Ready or not, a whirlwind of a ride may await you unless you have done some basic preparation. No matter if you are the receptionist, or the next senior level manager to serve as the interim leader during the transition, you will be affected in some form or another. Your time will be divided exponentially due to the acquisition of new tasks, and the learning curve those tasks will require. In addition, your “usual” activities may get pushed somewhat to the background and can get overlooked if you are not careful.

Projects, tasks, and decisions may proceed more slowly if you are not prepared. So, what can you do to keep moving forward with a full head of steam? Document your responsibilities.

Begin by documenting all that you do, all that you are responsible for prior to the shift, and everything you take on during the transition. Document all of your projects, tasks, and decisions that you are involved with to standardize and organize them.

Once you have accomplished this you will be in a better position to organize and delegate some smaller oriented tasks out to your team. You will also be able to properly communicate expectations and how things are to be handled during the transition. This will also allow you to be able to bring the new “Chief” up to speed more quickly once the vacant role is filled.

How the departure affects general functions and processes

Does your business run on people and anecdotal information? Meaning, do things happen when the “top dog” says it should, and how it should? If so, you may find that company processes, projects, tasks, and management decisions will grind to a halt upon the departure of this person unless you get the processes and projects documented and systematized. When you move in this direction, you will find that you are not completely dependent upon people for the processes and projects to move forward, but more on a system that works and functions nearly independently and therefore managed by its people.

For example, say the departing leader has a specific decision making process proven to be successful (shown below) as to which projects are pursued, and which are not. Wouldn’t it be helpful to know what that process is, and refer to it during the transition? Of course it would. So acquire the information and create easy to understand visuals, like decision trees and flowcharts that serve as reference guides for you to be able to make good consistent decisions and keep progress moving in a forward direction in the same manner prior to the leader’s departure.

Click here to see a larger version of this visual.

The final task is how you communicate this back to your team. The repurposing of projects and tasks can be an emotional proposition for some as time and energy may already have been invested, so you will need to clearly communicate the reasoning behind any changes. The remedy? Share your visuals like the one above so that they understand how specific processes and decisions are made. The more transparent the process and decision making is, the more on board your employees will be about the procedures. Also, you avoid the same previous problem of having only one person with the understanding of the company “knowledge bank” and you forge trust and team communication amongst everyone.

The personnel of the organization are the most impacted when there are departures, and if processes and other pertinent information are stored anecdotally within only a few people then everyone feels the pain – including you. Take the time to document, organize, evaluate and communicate your processes, projects and decisions to keep your organization stable.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

How to Calculate ROI

Aaron Stannard — Mon, 16 Mar 2009 18:02:00 GMT

Recently my co-worker Rich asked us all “Why Bother with Return on Investment (ROI)?” As Rich points out, most managers sing the praises of understanding ROI without practicing what they preach. I myself don’t calculate ROI nearly as often as I should, because it’s often difficult to do and sometimes it’s something that falls by the wayside in the midst of the noise and hustle of the workplace.

Return on Investment means a lot of things; it means one thing in the world of accounting, another in the world of financial investments, and it means another in the scope of project management. We’re just managers of one sort or another here at Working Smarter, and we use ROI as a figure to illustrate the costs and benefits of our projects. We find that calculating ROI helps us avoid pitfall projects, helps get our co-workers to buy-in to project ideas, and helps us prioritize how we use our resources.

When I calculate ROI for a project or a new marketing initiative I find that it is extremely helpful for my co-workers, my boss, and the other teams within our organization who might be involved with the project in some way, shape, or form. ROI figures help them buy into the project and help them prioritize their projects accordingly – something with an ostensibly high return on investment will be prioritized ahead of things with uncertain or perceptibly low ROI.

ROI is a simple concept; it’s the total dollar/time return your organization will receive in exchange for undertaking a project or initiative of some sort.

But how do you actually calculate it? How do you accurately calculate the Return on Investment of your projects? Well, I’ll show you – first we need to understand the two dimensions of ROI:

Reduced Costs – The first way a project produces returns is in the form of reduced costs. In this situation you calculate ROI using this formula:
ROI = Change in Operations Cost / Costs of Project
Increased Revenues – The second way a project produces returns is in the form of increased revenues to the organization. If a company decides to invest a ton of effort into developing a new product, the ROI for that new product will be the additional revenue that the project generates less the costs taken to produce and promote that product. You calculate the formula like this:
ROI = Change in Revenue / Costs of Project

We know how to calculate the overall ROI figures now, but what we really need to do is determine how to calculate the individual parts for both formulas. There’s a process for doing this, which I have defined below:

Although it looks complicated, it’s actually not too bad once you learn how to use the right tools to do each step. People have written books on this stuff, so I’m not going to go into extensive detail, but I’ll be able to give you enough to get you started with ROI.

Step 1 – Determine how much Work is Needed to Complete the Project

This is a very, very familiar step for long-time Working Smarter readers – to accurately determine how much work is needed to complete a project, simply decompose the project’s tasks into a series of very small, simple tasks using a mind map.

It’s very difficult to accurately determine how much work is needed to complete a large task; therefore the most accurate way to schedule large tasks and projects is to break them down into groups of small tasks. Here’s a relevant passage from the previous article:

Don’t believe me? Let’s [consider a project] that everyone can relate to: moving from one home to another. Consider these two groups of questions:

How long will it take you to pack up all of your belongings, move them into your car, unload them into your new house, and unpack them?
How long will it take you to do the following:
1. Pack up all of the dishes, silverware and cookware in the kitchen?
2. Pack up all of the delicate China and glassware?
3. Pack up the five-piece dining set?
4. Move the China cabinet into the car and unload it back at the new house?

Most people will find that it is substantially easier to produce more reasonable, reliable figures for the set of questions under item two than under item one. That’s why we strongly recommend using mind maps to leverage this principle.

If you would like to learn more about decomposing projects with mind maps then we highly recommend signing up for How to Manage a Project, our free eCourse which explains the technique in detail.

Step 2 – Determine the Cost of the Work Needed to Complete the Project

You’ve determined all of the tasks and amount of labor needed to complete a project - now you need to calculate the dollar per hour cost of that labor and resources. This part requires some work. Here are components of this step:

Labor wages for new hires / contractors / consultants – Divide the work time between the new hires working on the project, determine the cost per / hour for each employee, and sum all of them up.
Cost of new equipment – If you need to purchase any new equipment for your project, include all of the costs of purchasing that equipment (financing, installation, transportation, etc…) and add that as a cost.
Cost of leases / rentals – If you need to lease equipment for your project, determine the duration of the lease based on your tasks and estimate the cost for that duration. Do this for every rental needed.
Opportunity cost – Many project managers do different things when it comes to opportunity cost, because it’s not a true “dollar cost” that shows up on a financial statement. Opportunity cost is the cost of picking this project over the next best alternative. It’s really an issue that determines your priorities more so than your costs – a project with a high opportunity cost could still produce a positive ROI, but it might be that the next best alternative has a significantly higher ROI. Use this to determine how to use your in-house resources appropriately, such as your employees’ labor and your company-owned equipment.

Step 3 – Calculate Returns

For projects that don’t produce any new revenue you need to determine the extent of the costs eliminated by your project. You can do this by building a “before” workflow and an “after” workflow – study how your company’s processes change before and after the projects are completed.

This is a concept that requires some additional understanding, so I recommend subscribing to our How to Manage a Process eCourse which explains it at length. Once you’ve determine the change in costs, calculate the ROI:

ROI = Change in Revenue / Costs of Project

For projects that generate revenue, do the following:

Determine your target market / persona – determining your target market isn’t easy, particularly if you’re launching a new business. We outlined a simple thought process for determining a target market, but I suspect that many readers will not be satisfied with that explanation. The fact is that marketers will never have 100% of information needed to make a business decision – they have to cope with a lot of ambiguity, and our process is an acknowledgment of that.
The hard part: estimate the worst, average, and best cases for sales – estimating sales is never easy. Marketing isn’t easy. But it has to be done. Write down your set of assumptions for new sales and new revenues, and based on those assumptions and your target market come up with three cases: the worst case, the average cast, and the best case for sales.
Present the sales cases to your team and come up with the “most reasonable” estimate – unless you’re working by yourself, you should always confer with your team to determine if your assumptions are reasonable or not.
Determine the “likely revenue” based upon the “most reasonable” sales estimate – produce an actual dollar amount for your “new revenue” figure.

Once you have all of this information, you can make your calculation:

ROI = Revenue / Costs of Project

ROI calculations aren’t always easy to do, but I’ve given you a guide here that should help many of you get started on the right foot.

If you have an easier, simpler, or more accurate way to calculate ROI then I would be more than thrilled to read it, so please consider contacting me with that information or leaving it in the comments.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

New eCourse: How to Manage a Project

Aaron Stannard — Wed, 07 Jan 2009 16:10:00 GMT

Recently we announced three new eCourses designed to help your business soften the blow from the recession and over the next week or so I’m going to expand on the details of all those eCourses. I’ll begin with our new eCourse on project management, appropriately called How to Manage a Project.

During the good times we often begin more projects than the lean times (aka “times of recession”) can support. Now you are “almost there” on too many projects. Which ones do you cut? Is it a mistake to cut any and lose what you have already invested?

Too often, projects seem to need “just a little more time” to complete. The most important question for any project is “How much is really done and how much is really left to do?” It’s never too late to properly manage a project, even if you are months into it. Once you really know how much time and resources are still required to complete a project, it’s much easier to weigh its benefits vs. costs.

How long does it actually take to complete a project?

But how can you confidently estimate how much time each project still needs? By following these steps:

Break the project down into tasks that will take more than a day or two to complete. It’s much easier to estimate the duration of a small task than a big one.
Decide which tasks must be completed before others can be started.
When you assign people to work on a task, be realistic about how much time they will actually have to work on the project.

Easier said than done, right? Actually, it’s pretty easy to do. Want to learn how? Then click here to sign up for How to Manage a Project.

About Working Smarter’s eCourses

All of our eCourses are free and delivered via email. You will receive the first lesson immediately upon sign-up and you should receive the others via email every two to three days, until you have read all of the lessons. If you would like to skip ahead to read other lessons immediately, you can do so.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Three New eCourses to Help You Recession-Proof Your Business Now

Aaron Stannard — Mon, 05 Jan 2009 16:59:00 GMT

Economic times are tough, and will be for a while. Now is the time to cut fat without cutting muscle. But how do you actually do it?

Well, fortunately we have three new eCourses which will help provide you with some basic ideas on how you can:

Cut operating costs without cutting output;
Prevent projects from running over-budget;
And maintain or even increase sales despite the recession.

As regular Working Smarter readers are aware, we launched what we promised would be “the first of many” eCourses in December 2008. Today we’re announcing three more additional eCourses that are available to the public, for free. Here they are:

How to Manage a Project

A lesson that we have often repeated on Working Smarter time and time again is that most projects run late because they are not managed sufficiently. We’ve compiled all of our advice regarding project management into a single eCourse which will help provide you with a clear idea on how to:

Properly decompose tasks;
Schedule tasks using a Gantt Chart;
Assign the right people to the right tasks;
And measure progress using milestones.

If this is something you might be interested in, click here to sign up for How to Manage a Project.

How to Optimize a Business Process

One of the best things you can do to help soften the recession’s blow to your company is to streamline your operations using standard business processes. Streamlined operations help your company cut costs without adversely affecting output by:

Ensuring that all team members are using the most efficient method possible to do their work;
Making the output of all work more consistent, also enabling you to quantifiably measure the quality of your output;
Making it easier for you train new employees or cross-train old ones;
And making it easier for you to identify production bottlenecks.

Like project management, this is a subject that we’ve blogged about frequently on Working Smarter. We’ve gotten a lot of customer feedback on the subject and much of it has been incorporated into this eCourse. So if you’re interested, click here to sign up for How to Optimize a Business Process.

How to Manage a Sales Process

The most visible effect of the recession is the slide in consumer confidence, which ultimately reduces sales. This last “recession-proofing” eCourse that we’ve developed is an adaptation of our How to Optimize a Business Process eCourse, which goes through a sales process in detail and demonstrates how you can optimize it to close more sales despite a decreased number of leads.

Click here to sign up for How to Manage a Sales Process.

About Working Smarter’s eCourses

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Making Milestones Matter

Aaron Stannard — Thu, 16 Oct 2008 14:03:00 GMT

In our most recent post, we introduced you to project milestones and how they can be used to effectively measure the progress of your projects. To recap:

Milestones should be obvious—anyone on your project team should be able to easily recognize when a milestone has been reached.
Milestones should be demonstrable—anyone on your project team should be able to demonstrate to an outsider that a milestone has been reached.
And Milestones should be progressive—each milestone reached should indicate additional progress towards completing the entire project.

We left our discussion at the issue of how broad milestones should be and how to use them properly.

The Correct Approach? Assign Milestones for Small Deliverables and Large Deliverables.

One approach—one which I don’t recommend—is to assign a milestone at the end of each task. This defeats the purpose of having milestones to begin with. Milestones are not supposed to be redundant follow-ups for tasks.

The correct way to utilize milestones is to use them to indicate when tangible deliverables are complete. You should use a combination of milestones: small milestones that are internal to your team to indicate progress on small deliverables and large milestones that are used to communicate your overall progress to outsiders.

Let’s go back to our software project example from last time. The third milestone (Data layer is complete) is a strong example of a “large” milestone, but it’s a milestone that's composed of many smaller milestones along the way. Let me illustrate this more clearly using a mind map:

The significance of individual milestones increases the further you move to the right on this mind map—the leftmost milestones represent the completion of the least significant deliverables during the course of a project’s progression and the rightmost milestones represent the most significant ones. These rightmost milestones are the most significant because they are composed of many smaller milestones which are reached during the course of your project's progress; when a large milestone is reached it's indicative of many other smaller achievements which have been met along the way. You can use these small milestones to indicate incremental progress to your team and you can use these large milestones to say to your boss "hey, we just delivered the entire data layer this week - looks like things are right on track!"

All of these milestones represent the completion of concrete, demonstrable deliverables, and that’s good because this means that every milestone yields some tangible product—unlike the “every task ends with a milestone” approach. I recommend using this delivery-based approach because it provides you with an additional layer of information for your project chart: completed deliverables.

If you want to try building your own mind maps you can download a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Introduction to Milestones

Aaron Stannard — Tue, 14 Oct 2008 13:33:00 GMT

Over the past couple of weeks we’ve covered a variety of project planning concepts, like breaking up large tasks and recognizing shared dependencies between tasks. One subject that we have not covered is how to definitively measure progress in an ongoing project, and that’s what we’re going to discuss today.

The Problem with Most Progress Measurement

Actually measuring progress on projects is one of the weakest areas for most project managers—how many times have you been in a meeting where someone was asked “how far are you along with project X?” and the answer was “oh, uhhh, I’d say maybe 50%, 60% done.” That’s not a definitive answer—that’s a guess.

That’s what’s wrong with most progress measurement—most project managers rely on broad estimates rather than definitive answers.

The Cure: Milestones and Concrete Deliverables

There is a cure that will help project managers see clearly through the fog, and it’s called “milestones.” A milestone is a well-defined, solid achievement that is met at some point through the course of a project. The word “milestone” takes its name from the placeholders used to indicate how far travelers had progressed along the roads built by the Romans; every time you passed a milestone, it was another indication that you were closer to reaching your destination.

The analogy accurately describes what we are trying to do when we manage our projects: we want to define clear indicators that tell us how close we are to reaching our goal. So let’s take a look at some sample milestones for a software engineering project:

Milestone 1 – All of the design specifications and the design specification documents are complete.
Milestone 2 – All members of the development team have individual assignments and set deadlines. Work on the software itself can begin.
Milestone 3 – Data layer is complete. Testing is ongoing.
Milestone 4 – Business layer is complete. Testing is ongoing.
Milestone 5 – Presentation layer is complete. Testing is ongoing.
Milestone 6 – All major errors and bugs are resolved. Minor bug fixing and testing is ongoing.
Milestone 7 – Project ships.

Even though these milestones are pretty broad, these are good milestones in that they are very definitive. For instance, the data layer is complete when all of the functionality defined in the project’s requirements is satisfied. A good, definitive milestone is one that every team member recognizes once it has been met. Compare this to the old approach, which is that a milestone has been met only once the project manager thinks it has been met.

The value of having these definitive milestones is thus: when asked “how far along are you on your project?” you can safely answer, “we’ve reached four of our seven milestones so progress is coming along smoothly; following the schedule set on our Gantt chart, we expect to have reached our final milestone by mid-January.” This brings up my final point for this article: integrating milestones into our project charts and schedules.

Integrating Milestones into Project Charts

For this post, I’m going to reuse my “buying a new SUV” example project from my recent post about using project charts for scheduling.

Here is my original project chart, without any milestones:

I’m going to keep this example simple and stick to just the broad tasks and broad milestones for the sake of brevity. Now, each of these major tasks should have a milestone. Rather than list all of my milestones, I’ll show them to you on a new project chart:

I’ve highlighted my milestones on the project chart—these are all deliverables that have to be completed before the next set of tasks can begin and they are an effective way of determining how far along you are in the course of your project. The first milestone is when I’ve decided what range of cars I want to drive and the second milestone is when I’ve found a specific car that I want to purchase and so forth.

Adding milestones to a project chart is pretty trivial—the hard part is determining the right kind of milestones to begin with. Ideally, you want to create a set of definitive milestones which accurately reflect how far along your project is. In our next article we’re going to get into a bit more detail about how broad milestones should be and how to use them properly.

If you want to try building your own project charts you can download a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

The Art of Assignment

Aaron Stannard — Fri, 10 Oct 2008 13:23:00 GMT

In our most recent article, we talked about how to schedule tasks using project charts. If you read it then you already have a good idea of how to correctly order and prioritize tasks. In today’s article we’re going to discuss how to build a team around your project and appropriately assign tasks to your team.

We begin our entry today with an example project, designing a new website for a product offering, expressed as a mind map:

I haven’t fully decomposed all of the tasks involved in this project for the sake of keeping the example short; in practice, you should always decompose your tasks into very small, specific tasks. Our project looks relatively straightforward—we have some people who have to work on content production, some on artwork and design, some on IT infrastructure, and some on outright marketing activities.

I’m going to repeat what we did last time and create a project chart which illustrates the dependencies and start dates of all of our tasks:

I cut off some of the Gantt Bars—otherwise the image wouldn’t fit within the blog’s template. But I don’t think they’re really necessary for this lesson. So what do we know about how we’re actually going to implement our project so far?

Duration – we know how long each task is going to take.
Task Sequence – we know which tasks are dependent on others and which tasks can be completed at the same time as others.

One of the things that we hinted at in the last article was the concept of how resource constraints can affect your delivery dates. In today’s article, we’re going to address the issue of human resource constraints.

First, let’s talk about the “proper” way to set up a team.

Using Your Organization’s Established Roles to Build Project Teams

Let’s suppose my org chart looked like this:

This is what my organization looks like. My project is to launch a new website for a new product that we are offering, so I’m going to make sure that I assign the correct tasks to the appropriate people based upon their job descriptions.

Projects shouldn’t be treated like some alien groups of tasks; the tasks from projects should be assigned according to people’s job descriptions just like any other assignment. If your project requires that something be shipped, have the usual shipping person fulfill that role on your project team. If your project requires some new pieces of graphical art, have your graphic artist take care of it. This is straight forward.

The correct tool to use to take people from your organization and form them into a team to complete a project is a team chart. Here’s what a team chart for this project would look like:

Let’s take a look at how I formed my team using the roles found on my org chart:

Content Planning – The project aimed at launching a new website to promote a new product; the person who will be planning the content for this website is obviously going to be our VP of Product Development, Torsha Rhodes. The new product is her baby, she knows it better than anyone, and it should be her who specifies how the website sells the product to new customers.
IT – The IT tasks are divided amongst the members of the IT team. Michael Jones, our system administrator, is responsible for managing the hardware and Leah Svenkin, our web developer, is responsible for handling any back-end programming needed to get the website off of the ground.
Design – Herb Gosher, our webmaster, is in charge of building the graphical layout for every page on the website for the new product.
Graphic Artwork – Chet Barre, our visual media specialist, is in charge of putting together all of the product photography and video demonstrations.
Copywriting & Content Production – Jon Ramirez, our copywriter, follows the content plan produced by Torsha and produces the written content itself.

Putting a team together isn’t complicated—treat tasks from any project just like any other tasks that might come up during the course of your daily activities. Don’t force people to move out of their organizational roles just because they’re part of a project; instead, issue the assignments to accommodate their roles.

Human Resource Conflicts and How They Affect Scheduling

Now that I have my team together I’m going to add my team members as resources to the “resources column” on my project chart:

Click here to view the full Gantt chart – it might help clarify some of the examples below.

In the mindset of project planning, that’s how we view our team members: as resources. Just like any other necessary resource for a project, we have to determine if those resources will be available on the days that we have set on our project chart.

What would happen if it turned out that Torsha was gone for the entire week beginning on November 3^rd? With the exception of the IT team, everyone else is dependent on her content planning. What happens to our project? We have to respect the dependencies on the project chart—they cannot be changed, so the only thing we can do is push the project start date back.

On the flip side, what would happen if the IT team had a more critical project due by November 5^th and they couldn’t start work on the project until two days later than projected? As it turns out, this delay wouldn’t impact the final delivery date of the project at all as the IT team’s deliverable would still be completed many days before Jon Ramirez is done producing all of the content.

The issue here is that after you set your project chart and assign team members to specific tasks, you must confer with them to determine if there will be any work stoppages or delays along the way and plan accordingly. What most project planners fail to do is account for team members who are committed to other ongoing assignments; thus, the deadlines for those over-committed team members are unrealistically short if the project manager fails to accommodate the delivery dates for those other commitments. Your project does not exist in a vacuum.

Next time we’ll cover how to properly set milestones and delivery dates.

If you want to try making your own team charts, project charts, org charts, and mind maps, then try a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Scheduling Tasks with Project Charts

Aaron Stannard — Wed, 08 Oct 2008 14:47:00 GMT

The first step to becoming a more efficient project manager is to decompose your project into small tasks using mind maps, an issue which we discussed last week. Today we’re going to address the second step in the process, which is setting the schedule for all tasks and deliverables using project charts (also known as Gantt charts.)

If you followed my last article on decomposing broad tasks into smaller ones (read it here) then you will recall the general message from that article which is that it’s much easier to construct accurate timelines and delivery dates for projects when you can sum your total required work time from a number of small tasks because it’s much, much easier to estimate an accurate duration for smaller tasks than broader tasks.

Two Core Areas of Scheduling

In this article I want to touch on the art of accurately prioritizing tasks. There are two core areas of a scheduling that must be settled upon before you can begin to move forward with a project:

Duration, the amount of time it takes to complete single tasks or groups of related task.
Sequence, the order in which tasks are executed.

We figured out how to determine duration in our last article by using mind maps to decompose broad tasks into specific tasks, and that’s the hardest part of scheduling. The next area (sequencing) is what we’re going to address in this article and there are additional areas of scheduling that we will address in subsequent articles, like resources and milestones.

I’m going to use the example of shopping for a new SUV as our project for this article, since it’s a concise example. I’ll begin with a mind map which shows all of the tasks and subtasks that go into “shopping for a new SUV” project. Here it is:

Ok, so we have a good idea of the primary tasks that go into buying an SUV; first you do some research online, then you do some hands-on research, settle on a make and model, determine financing, determine insurance, and do some paperwork with the DMV (Department of Motor Vehicles.) Usually there are some trade-in negotiations but I decided to skip that step in this example.

Alright, with those details out of the way we can get on to meat of the matter.

Getting a Grip on Task Sequencing

We already know how long it’s going to take to execute each individual task because we decomposed our tasks into small tasks to which we can easily assign reasonably accurate durations. Therefore the next step we need to take is to determine the sequence in which we execute tasks. What’s the process for figuring out sequencing?

The bad news is that there is no simple, universal process for sequencing the tasks in every single type of project because each kind of project has a degree of what I call “natural sequencing,” meaning that there are some tasks are dependent upon the results of others.

It is important that we determine exactly what these dependencies are. Let’s consider the natural sequence of my SUV-purchasing example:

Before we can register our car with the DMV we need to own the car.
Before we can insure our car we with an insurance provider we need to own the car.
Before we can purchase our car we need to have financing secured.
Before we can secure financing we need to have a clear idea on what car we want and we need to know what our price range is.
Before we know what car we want to purchase we need to test drive the different models and makes in order to make a smart purchasing decision.
Before we test drive various cars we need to know which makes and models that we’re interested in.

Based on the steps I’ve described you can recognize the natural dependencies involved in the process of buying a car. I’m going to convert my mind map to a Gantt chart and illustrate these dependencies.

I pared down my Gantt chart to contain just the broad tasks. Take a look at the start dates – task 2 doesn’t start until task 1 ends, task 3 doesn’t start until task 2 ends, and so forth. This is how you illustrate dependencies and it is these dependencies which determine the sequence of your tasks.

The Importance of Co-Tasks

We’ve identified and planned for all of the dependencies in our project thus far, but now we need to consider “co-tasks.” Co-tasks are tasks that can be done in parallel if resources are available, and the reason that these are significant is because co-tasks can shorten the total time needed to complete a project.

Let me illustrate the point by adding some co-tasks to my Gantt chart.

Consider tasks 1.1-1.4, the ones shaded in light blue; they are all sub-tasks of “Online Research.” All of those tasks can be executed in parallel with each other – if you’re researching cars online you’re going to be weight all of those factors at the same time.

So why is this important? Let me ask you a hypothetical question: how long would it take you to purchase a new car given that you could only work on one and only one task on any given day? The answer is 21 days given all of the durations that I’ve used in my example. Follow-up question: how long does it take you to purchase a new car if you can streamline co-tasks in parallel? The answer is 12 days.

The point is that if you can correctly identify opportunities for co-tasks then you can expedite the entire project as it allows you to hit multiple birds with a single stone.

By recognizing dependencies and co-tasks in your project you can plan your project much more efficiently by capitalizing on opportunities to hit multiple birds with a single stone and by making sure you complete your tasks in the proper order. Next time we’ll take a closer look at milestones and deliverables!

If you want to try building your own project charts with dependencies and co-tasks then you can download a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.

Decomposing Tasks with Mind Maps

Aaron Stannard — Fri, 03 Oct 2008 14:36:00 GMT

Many projects are delivered late—one of the key reasons being that the tasks assigned to team members are too broad or vague. You might be asking yourself “what’s wrong with broad tasks?” As I answered in my most recent post, it’s very difficult to accurately determine a timeline for large or broad tasks.

Most projects are late largely because of these broad tasks and the estimated timeline from inception to delivery is typically unrealistically short. Thus, the solution is to decompose these broad tasks into a number of smaller subtasks. It’s easier to determine how long it will take you or your team to accomplish a smaller task as opposed to a larger one.

Don’t believe me? Let’s try an experiment that everyone can relate to: moving from one home to another. Consider these two groups of questions:

How long will it take you to pack up all of your belongings, move them into your car, unload them into your new house, and unpack them?
How long will it take you to do the following:
1. Pack up all of the dishes, silverware and cookware in the kitchen?
2. Pack up all of the delicate China and glassware?
3. Pack up the five-piece dining set?
4. Move the China cabinet into the car and unload it back at the new house?

I’m not going to list every possible task that would go into packing up your belongings and moving them into a new house, but you get the idea: it’s almost impossible to give an accurate answer to the first group of questions, whereas it’s much more feasible to provide some reasonable answers for the second set. You can use the sum of all of the times required for each small task to determine how long it will take you and your team to accomplish a much larger task. And that’s what this article is all about.

The Right Tool for the Job: Mind Maps

Let’s stick with this “move out, move in” example for now. In order to efficiently decompose our two big tasks, “moving out of House A” and “moving into House B,” I’m going to use a mind map. For the sake of brevity I’m going to limit my example to just the packing portion of the move-out project.

Here’s how we get started:

We begin by considering all of the rooms in House A as separate groups of tasks, which is reflected on the mind map above. That’s just the first step. Now we need to begin thinking about each room individually. Let’s examine the master bedroom:

So we’ve subdivided the master bedroom into four subtasks, which I can then divide further:

Now we’re getting down to individual items in the master bedroom—this is progress; rather than having to estimate how long it’s going to take us to pack up the entire master bedroom in one blind guess, we now have an idea of what individual items are going to need to be packed. However, we still need another level of decomposition; each item on this list requires a certain amount of effort to be properly packed so we must take into account the steps needed to pack each item.

Now we’re going to use a mind map to break down how to pack each item, and from this next level of decomposition we can guarantee a much more accurate timeframe for the total move-out project. We’re going to start by decomposing all of the tasks that go into packing up a king-sized bed, which is arguably the most awkward thing in the house to pack.

Here we have the key components to the bed; now let’s add some specific packing tasks to each of these components:

And one more level of decomposition:

Now we have very specific tasks instead of broad ones and we can estimate very accurately how long it will take us to take apart this bed.

Next Step: Assign Some Durations to Your Specific Tasks

I exported my above mind map to outline format since it’s a bit easier to make this next point clear. Given how specific these tasks are, it becomes trivial for us to produce a very accurate timeframe for unpacking the king-sized bed in our master bedroom. Let’s assign some durations to these specific tasks based on our prior experience:

The Mattress
- Remove Linens
  - Remove Pillows [ < 1 minute]
  - Remove Sheets [ 2 minutes ]
  - Load into car [ 2 minutes ]
- Remove Mattress Cover
  - Place mattress cover into car [Can be done at the same time as linens]
- Remove Mattress from Bed Frame
  - Place in hallway for movers [4 minutes]
Bed Frame
- Push the bed away from the wall [2 minutes]
- Remove Headboard
  - Unscrew from back of bed frame [6-10 minutes depending on tools available]
  - ii. Store screws and washers in toolbox [1 minute]
  - iii. Place in hallway for movers [1 minute]
- Place in hallway for movers [3 minutes]

I’ve added durations for all of the simplest tasks and now I can simply sum those durations to determine how long it will take to pack the entire king-sized bed: 22-26 minutes, which is accurate based on my personal experience. If you repeated this exercise (it only took a few minutes) for every room in the house you would be able to build a very accurate assessment of how long it would take you to move out.

Although we used the rather common example of moving out of one house and into another, this technique can be applied to any project to help construct a much more accurate timeframe for completing a project. Next time we’ll show you how to convert this mind map into a Gantt chart to help plan the order in which tasks need to be executed.

If you want to try decomposing your own project’s tasks down into simpler ones using mind maps then you can download a free trial of SmartDraw.

If you liked this post, make sure you subscribe to our RSS feed or follow us on Twitter.