Working Smarter : Gantt Charts

Three Ways Our Customers Are Fighting the Recession

Aaron Stannard — Wed, 29 Oct 2008 21:32:00 GMT

The economic climate as of late has become demonstrably unstable and, as a result, many businesses are battening down the hatches and making preparations for the upcoming fiscal year. This means cutting down on operating costs, eliminating projects that don’t have an immediate impact on the bottom line, and implementing other cost-cutting initiatives.

Over the next few weeks, we’re going to be publishing a lot of material which will provide you with some ideas to help you find ways to tighten your belts. Today we’re going to provide you with a preview.

Here are three strategies that we’ve received from customer case studies regarding how they’ve improved their bottom lines in the face of recession:

A Major U.S. Health System Saved $1,000,000 per Month by Optimizing Processes

The more time a patient spends in a hospital, the greater the cost to the hospital. So it is no wonder that one of our customers, a major U.S. non-profit healthcare system, was under the gun to increase its patient throughput. By documenting the existing hospitals’ business processes with flowcharts, our customer was able to identify and correct major inefficiencies throughout the healthcare system’s operations. This netted them a savings of roughly one million dollars per month as a result of increased patient throughput.

A Small Business Saved $20,000 per Year by In-Sourcing Marketing Materials

A small business that specializes in brokering industrial property solutions was able to save approximately $20,000 per year by drawing a large portion of its own marketing materials, namely floor plans and landscapes, using a copy of our software instead of relying on expensive third-party graphic artists to do the work.

A Major Charity Saves 100 Person-Hours per Month by Improving Project Management

A major charitable organization in the U.S. uses SmartDraw routinely to create training materials using flowcharts and mind maps. These types of diagrams are self-explanatory and thus require less explanation and communication with instructors. Most recently, they took advantage of SmartDraw’s project management capabilities to simplify a major IT system migration, saving the organization even more time and money. The charity estimates that its routine use of these visual management and communication mechanisms helps them save roughly 100 person-hours per month.

In the upcoming weeks, we’re going to be publishing an extensive amount of material which will tell you how to recession-proof your business and get the most of your organization during economically turbulent times—so stay tuned!

Discussion: How Are You Cutting Costs?

We’re pleased to share with you some stories of how other SmartDraw customers are saving money in the down economy by cutting costs. But we’d also like to encourage you to share your success stories with us here on the blog by leaving a comment below. How have you been able to cut costs in the face of a possible recession? Have you found any of the techniques that you’ve read about on Working Smarter to be helpful?

Please let us and other readers know!

If you want to try building your own mind maps, project charts, flowcharts, or anything else mentioned in this article 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.

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.

Four Techniques I Use to be a Better Manager

Paul — Thu, 22 May 2008 11:00:00 GMT

When I founded SmartDraw.com I was a software developer not a manager. Not that this mattered much because the only person I needed to manage at the time was me!

As the company grew, management was "thrust upon me", and I learned four techniques I still use to manage people and projects effectively.

1. I Organize my Thoughts with a Mind Map

I'm a visual thinker (as you might imagine) and I use a mind map at the start of any new project I am working on to organize my thoughts and ideas.

A mind map is a visual outline. Using SmartDraw of course, I just dump out my ideas onto the page and then re-arrange them into logical groups. I use SmartDraw's keyboard shortcuts and automatic formatting I find this even easier to do than using Word to make a traditional text outline. Here's an example of one of my mind maps.

Watch my screen cast on drawing mind maps with SmartDraw too.

2. I Organize my People with Organization Charts and Team Charts

There are two ways we are organized at SmartDraw: into a traditional reporting hierarchy and into teams for specific projects. I use the traditional top-down org chart for the former and a team chart for the latter.

Your company organization chart is actually a device for showing positions and their responsibilities rather than people. Sometimes in a small company one person may be the "incumbent" for more than one position. I have written about this in a previous post.

A team chart is an effective way of making sure everyone working on a project knows what part of it they, and the other members of the team, are responsible for and what's expected of them. Just because it's clear in your mind doesn't mean it's clear in the rest of the team members' minds.

Watch my accompanying screencast "How to Draw Organizational Charts and Team Charts with SmartDraw."

3. I Organize my Operations with Processes

As my business grew it soon became evident that we needed to formally define the way we did routine things so that the result was the same each time and we could train new people more easily. Whether it was something technical, like the way we built software releases, or something simple like the way we shipped product, we needed to define a process that was followed each time.

I use flowcharts to define our processes. With SmartDraw 2008 that we released in September, this is so easy I can actually revise the chart on the fly as I think it through.

Watch me do this in my screencast "How to Map Your Business Processes with SmartDraw."

4. I Organize my Work with a Project Chart

In my experience the biggest reason projects are completed late (and over budget) is because all of the steps involved were not considered up front. Managers specify tasks that are big and vague like "Create Website". A big task like this is actually made up of many small tasks and can take months. You cannot properly estimate how long a task like "create website" is actually going to take without breaking it down into smaller more specific tasks.

My rule is that if any task takes more than three days it's too broad and needs to be broken down into smaller tasks. As I go through this process I always think of new things that I need to do and that add time to my initial estimate. Something that sounds simple is often not so, once you get down to the nitty-gritty.

I use a mind map to start the process of identifying all of the tasks. I break big tasks into smaller tasks. The natural outline format of a mind map is perfect for this. Then I convert my mind map into the traditional project chart (or Gantt chart) format an assign a time to complete each one. SmartDraw makes this particularly easy because it does it automatically and lets me go back and forth between the two views with a single mouse click.

Watch my screencast, "Managing Projects with SmartDraw" to see this in action.

All of these techniques help me keep multiple projects on-track, and the people working on them informed and on the same page. For more details read the companion PDF from our Working Smarter series: Four Ways to be a Better Manager.

Getting It Done On-Time with Simple Project Management

Aaron Stannard — Tue, 20 May 2008 11:00:00 GMT

The most important aspect of any project, personal or corporate, is cost and cost is determined by the answers to the following two questions:

How much time am I going to need?
And how many people am I going to need?

My background is primarily in software development and like most modern forms of work it's very much a project-driven field. Software developers are notorious for always delivering their projects late and over budget. Why? Because project managers don't fully scope out all of the tasks that must be done, and then they assign arbitrary times to their list of vague overly broad parts of the project.

I use two techniques to solve these problems: I use a mind map to identify all of the tasks and then a project chart (Gantt chart) to assign how long each task will take.

This sort of project management may not be necessary for the tiniest of projects, but for most projects you are going to need an organized, measured approach in order to accurately anticipate costs and to keep your project on schedule.

How I Manage Projects Using Business Graphics

In my last semester of college I was involved in a marketing project along with three other students - we had to perform some basic market research on the behalf of our client, an online niche news service.

We had to gather information from four target audiences:

What attracted current subscribers to the service;
What might draw potential new subscribers to the service;
What might draw large advertising networks to publish with the service; and
What might draw smaller, direct advertisers to publish with the service.

I'm going to use this small project as an example for the purposes of this article.

Step 1 - Scope Your Project with Mind Maps

I've written before about using mind maps to organize your thoughts and ideas. Mind maps are a great tool for organizing one's brainstorming but mind maps are also a great project management tool, and they are especially helpful for breaking down a project into smaller components.

The ultimate goal with our mind map, for the purposes of project management, is to narrow the scope enough such that the tasks identified on the map are specific enough to be easily understood by the project members.

I'm going to begin my mind map with the four target audiences that I mentioned earlier.

That's the first step - the next step is to start adding more specific subtasks as branches to each of the original tasks, like how I have done in the picture below:

Now we're ready to move onto our project chart, given that our mind map is complete.

Step 2- Convert Your Mind Map into a Project Chart (Gantt Chart)

We used a mind map to clearly scope out all of the tasks that will go into executing our basic market research project - now we need to use a Gantt chart to schedule our project and monitor our project's progress.

In SmartDraw it's actually really easy to convert a mind map to a Gantt chart because SmartDraw will automatically do it for you, as we demonstrated in our most recent screencast "Managing Projects with SmartDraw."

Here's the product of our initial conversion to a Gantt chart:

I had to crop out some portions of the Gantt chart in order to make it fit into this blog post, but you get the idea - we have an initial Gantt chart to work with and now we need to begin determining the appropriate start dates and durations.

Step 3 - Schedule and Order Tasks on Your Gantt Chart

We have a basic order of operations that we need to follow in order to complete the data analysis for our market research project:

Prepare survey/questionnaire material
Prepare prospect lists (if necessary - we already know who our current readers are, for instance)
Prepare distribution letters (if necessary)
Identify distribution channels
Distribute surveys and conduct interviews
Analyze results

Some tasks can be conducted in parallel, such as preparing questions and paring prospect lists, but some tasks can't begin until others are completed - you can't conduct an interview without any prospects, for instance.

After taking all of these factors into consideration we can begin defining our start dates and durations, which would make our Gantt chart look something like this:

The lines in red represent the deadlines for our primary tasks, so they include all of the deadlines set by the subtasks contained within the Gantt chart hierarchy. I've included a link to a full-sized version of this Gantt chart in PDF format below:

[PDF] Example - Market Research Mind Map and Gantt Chart.pdf

As you can see, the Gantt chart is small enough and simple enough to be clear and easily understandable by the other members of my team - they all know when each deliverable is due and when we need to start work on any given portion of the project.

Step 4 - Measure Your Progress with the Gantt Chart

My four man marketing project has a total duration of 10 business days - updating the Gantt chart with new Gantt bars, "progress bars," wouldn't really be necessary given the small scope of the project - however, in the context of larger projects with larger teams it's important to communicate your unit's progress to the other units that compose the project team, especially if their tasks are dependent upon the completion of yours.

Learn More about Project Management Using Mind Maps and Gantt Charts

If you'd like to learn more about project management using business graphics you can watch our most recent screencast "Managing Projects with SmartDraw."

Also, if you'd like to play around with the diagram that I used in this example, you can download a free trial of SmartDraw and open the example file below.

[Example] Example - Market Research Mind Map and Gantt Chart.sdr

Screencast: Managing Projects with SmartDraw

Paul — Thu, 15 May 2008 11:00:00 GMT

In this screencast we show you how you can use SmartDraw and to manage projects; first we show you how to scope your project with a mind map, then we show you how you can easily convert that mind map into a project chart (Gantt Chart), and finally we show you how to use those two charts as effective project management tools.

Download a free trial of SmartDraw here.

Learn More

If you'd like to learn more about this topic then be sure to read our companion PDF - Working Smarter with Project Charts.