projhugger

Detailed Commentary: Chapter 2 of Project 2010 Step by Step

This week I continue the “highlights of highlights” series: I include some excerpts from the Project 2010 Step by Step chapters and elaborate on them. This week: Chapter 2, "Creating a Task List."

In Project, there are several different kinds of tasks. These include summary tasks, subtasks, and milestones. (pg. 23)

The subject of tasks in general is one where there's a big difference between the mechanics of MS Project and your intent as a project manager. Mechanically, the differences between  summary tasks, subtasks, and milestones are easy to explain. In the real world of project management, however, these are very different things that serve fundamentally unique roles.

A project plan is essentially a model that you construct of some aspects of a project you are anticipating…(pg. 24)

When I first began to seriously study Project (around 1998), the "Aha!" moment when Project really started making sense to me was when I began to think of Project more like a simulator and less like a database application. A colleague of mine summed it up perfectly: "Project is a database that knows about time."  I have found this explanation of Project as a simulator or modeling tool to be highly effective.

Each task has a unique ID number, but it does not necessarily represent the order in which tasks occur. (pg. 27)

I have found that  some Project users really fixate on the task ID sequence. They find a task list just looks wrong if the ID sequence doesn’t align with, say, the start sequence of each task. There's really nothing magical about task ID; normally it conveys nothing more than the order in which you entered the tasks. That's all.

Think of a manually scheduled task as an initial placeholder that you can create at any time without affecting the rest of the schedule. (pg. 28)

The feature called manually scheduled tasks is a game changer for Project 2010. It's a really, really big deal. But truth be told I was not a big fan of the feature when I first encountered it. The more I've worked with the feature though, the more I've warmed up to it. My initial though was, "Why bother using Project? I could just record this kind of static and unstructured task information in Excel!" Well genius, yes exactly!  My initial complaint turned out to be a great compliment. Now I can record all kinds of unstructured task information right in Project, and then flip the switch either per task or across the entire plan when I'm ready to move to automatic scheduling.

Defining the right tasks to create the deliverable is an essential skill for a project manager...distinguish product scope from project scope. (pg. 29)

This is from a sidebar called "Project Management Focus: Defining the right tasks for the Deliverable." This sidebar relates to what I regards as some of the magic pixie dust that gets sprinkled on great project managers. They have the ability to look at some desired end result and break it into component parts, and then decompose those down into well-defined and understandable work packages (or tasks). In general this focus is called the Work Breakdown Structure (WBS) and is a cornerstone of project management. Indeed WBS is so basic to project management that one valuable bit of advice I was given when prepping for the PMP exam was this: "If you're not sure what the right answer to a question is but one of the choices is WBS, pick it." Good advice.

In Project, phases are represented by summary tasks, and the tasks indented below the summary task are called subtasks. (pg. 35)

This is one of those mechanical explanations I alluded to above that turns out to be so simple to do in Project, but so hard to get right in the real-world project. It seems to be human nature to want to divide big things into smaller components with hierarchical relationships. If you like doing this, good news! There's a place for you in the world of project management! It turns out it's very hard to get right, however. I've seen many (and been responsible for some)  projects where all the stakeholders could reach agreement on the desirable end result, but absolutely not agree on how to break that apart into manageable work chunks.

These two tasks have a finish-to-start relationship (also called a link or a dependency), which has two aspects:

• The second task must occur after the first task; this is sequence.

• The second task can occur only if the first task is completed; this is a dependency. (pg. 37)

Well that's the whiteboard definition of task linking with a finish-to-start relationship. We cover the four possible link types: FS, SS, FF and that strange cat SF.  In a Start-to-Finish (SF)  relationship the start date of the predecessor determines the finish date of the successor.

The project calendar defines the general working and nonworking time for tasks. (pg. 46)

In the book we devote a lot of pages to the mechanics of calendars and working/nonworking time. We do so because it turns out to be a pretty complex but also very useful area of Project. Managing working time effectively is one of the distinct capabilities of Project as compared to, say, Excel.

 Previous posts in the "Detailed Commentary" series:

• Introduction of Project 2010 Step by Step

• Chapter 1, "A Guided Tour of Project"

###

Detailed Commentary: Chapter 1 of Project 2010 Step by Step

This week I continue the “highlights of highlights” series: I’ll include some excerpts from the  Project 2010 Step by Step chapters and elaborate on them. This week: Chapter 1, "A Guided Tour of Project."

 

We think you'll be able to recognize many of the scheduling problems that the project managers at Lucerne Publishing encounter and apply their solutions to your own scheduling needs. (pg. 4)

For me one of the most interesting aspects of writing in the self-paced tutorial genre is the creation of the tutorial's scenario. This is the fictitious but plausible background of Project users at a fake book publisher named Lucerne Publishing, and their approach to using Project. Developing a plausible scenario means that you, the reader, can see situations in the book and transfer them to your real-world needs. Developing a strong scenario substantially adds to the instructional value of the material.

                       

Let's walk through the major parts of the Project interface…(pg. 6)

Project 2010 adopts the Fluent interface (commonly called "the ribbon) first introduced in other Office 2007 applications. Overall I think the Project engineering team did a good job of using this new UI model to surface great Project features that often went unnoticed in the older pull-down menu UI design. 

        

The entry bar (also called the formula bar) is hidden by default…(pg. 7)

OK this is one decision on which I don't agree with the Project engineering team 's choices in the 2010 UI. Fortunately you can turn on the entry bar. Here's how: On the File tab, click Options. In the Project Options dialog box, click the Display tab. Under "Show these elements," click the "Entry bar" check box.

                                                             

One common concern with sharing project plans is they may contain sensitive information like resource pay rates. You can save a project plan as a template and clear such information…(pg. 10)

This came up in a sidebar about templates. It's very valuable to be able to generate a template from a project plan you have developed and fine-tuned. To generate the template but exclude sensitive data like pay rates or schedule actuals, do the following. On the File tab, click Save As. In the "Save as type" box, click Project Template, entehr the template file name you want, and then click Save. When the Save As Template dialog box appears, select the types of information you want excluded from the new template.

 

The working space in Project is called a view...In general, views focus on task, resource or assignment details…(pg. 14)

A key part of mastering Project  is mastering views in Project. A Project plan is multifaceted and complex. Views give you insights into specific focus areas. My favorite advanced views are the Task Usage and Resource Usage views.

Previous posts in the "Detailed Commentary" series:

• Introduction of Project 2010 Step by Step

###

Detailed Commentary: Introduction of Project 2010 Step by Step

 Over the next several months I'm scheduled to deliver some in-house hands-on training from my book, Project 2010 Step by Step. This will mainly involve me performing the hands-on activities and providing narrative discussion about the subject matter as I go.

With this blog post I kick off the “highlights of the highlights” series: I’ll include some excerpts from the Step by Step material and elaborate on them. This week: the book’s introductory material.

Manage tasks, costs, work, and resources at whatever level of detail is appropriate for your project’s needs (pg. xv)

This is a subject we address repeatedly throughout Project Step by Step. It’s all too easy to create project plans that are either way too detailed (e.g. task durations measured in minutes or hours for multi-year projects) or way too broad (tasks that lack sufficient definition to be well understood by the resources assigned to them). Proper task definition is a key component of that critical focus of project management, the work breakdown structure (WBS).

The Microsoft Office Fluent interface (the “ribbon”)…(pg. xvi)

Project 2010 adopted the ribbon, which was introduced in some of the other Office applications at their 2007 release. So Project is catching up with the Jones. I personally am a big fan of the ribbon UI. There is an up-front learning curve, but I have found it is well worth it.

Project 2010 is a substantial update for desktop project management (pg. xvii)

Yes indeed! While most of the action in the last several releases of Project has been on Project Server and enterprise project management (EPM), in 2010 the desktop app gets lots of loving attention from the product development team.

If any of your settings are different, the ribbon on your screen might not look the same as the one shown in this book. (pg. xxiv)

One of the really smart behaviors of the ribbon UI is that it gracefully resizes itself based on your computer’s screen resolution or just by resizing the MS Project window. Go ahead and give it a try—start with a maximized Project window, then adjust it to smaller sizes. Note how the items on the ribbon are changed—text labels get dropped, the some commands get dropped, and ultimately just the group labels remain. It’s a smart UI but does take some training to master.

Next week: Chapter 1.

###

10,000 Hours to Expertise

In his book Outliers, Malcolm Gladwell popularized the notion that achieving real expertise at something complex takes about 10,000 hours of effort.  This is the so-called "10,000-Hour Rule," and Gladwell cites the Beatles and Bill Gates as two examples of people who put in at least 10,000 hours of consistent practicing and mastering their craft (music and programming) before they really had their big breakthroughs to success.

We Project zealots immediately note that this is 10,000 hours of work, not 10,000 elapsed hours. There is a difference--a big difference. How big? Let's use Project as a time calculator to find out.

Scenario A: The Relentless Aspiring Expert

Let's say that our Aspiring Expert, A.E., has through a series of fortunate events found herself with the opportunity to devote 10,000 hours of her time to gaining true Gladwellish expertise in her chosen passion. A.E. is indeed fortunate because she has a benefactor who will foot the bill for her living expenses and training costs during this impressive ramp-up time period.  A.E. commits to begin her road to expertise on January 1, 2013 and further commits to spend a full 40 hours per week with her nose at the grindstone. When can we schedule A.E.'s graduation to expertise upon completing her 10,000 hours of training?

First off, in Project I set the project's start date to be January 1, 2013 and leave the default project calendar at 40 hours per week. A.E. has signed up to work a full 40 hour work-week, and won't even pause for holidays. She'll do her laundry and all other mundane tasks required by life on the weekends. Here's the initial task and assignment I create:

TIP  Click the screenshot image to see a larger view.

Next I'll modify the view a bit. Because the 10,000 hours is work and not elapsed duration, I want to see work in my Gantt Chart view. (Right click the Start column heading, click Insert Column, and select Work.) I also like to see work quantified per time period, so I'll show the Resource Usage view in the Details pane. (On the View tab, in the Split View group, click the Details box and then select Resource Usage.)

Now we're ready for Project's scheduling engine to do its magic. I enter the impressive value of10,000 hours in the Work field for task 1:

There it is--making all of the above assumptions about our aspiring expert A.E., we see that A.E. will complete her training by October 16, 2017--about five years, 10 and a half months later.

Next to get a better look at how A.E.'s work will be distributed over that impressive time period, I fiddle with the timescale. (On the View tab, in the Zoom group, in the Timescale box click Years.)

There it is--just over 2,000 hour per year at 40 hours per week for almost six years is A.E.'s ticket to expertise.

Scenario B: The Slow Dabbler

Not many people can actually set up their lives so they can commit 40 hours per week to their passion. How about for those of us who can commit only a few hours per week to our passion? Let's look at the case of A. Hobbiest, or A.H. This person can invest only eight hours per week to developing his expertise. How long will A.H. need to achieve Gladwellian expertise? Let's take a look.

First, I set up the task in the same way:

This time though I'll go about things a little differently. I'll assign the resource A.H. to the task at 20% units (which equals 8 hours per week for a normal 40-hour workweek), and then enter the same 10,000 hour work value:

Oh boy, I hope A.H. is a patient person! Looks like he'll be chipping away at his expertise at a rate of eight hours per week for a long, long time--all the way to December 15, 2036 to be exact!

Is either scenario very realistic? For most people, probably not. Developing expertise in any complex domain or skillset is very unlikely to follow this predictable and linear progression. However I hope this post has illustrated some neat capabilities of Project, and especially reinforced the difference between work (those 10,000 hours) and elapsed duration.

Hands-on with Project Step by Step

To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.

The Scheduling Formula (Project's magic sauce that links task duration, resource assignment units and work)

• Project 2010 Step by Step: "Changing Task Types," pg. 158
• Project 2007 Step by Step: "Changing Task Types," pg. 156

 Resource Usage view

• Project 2010 Step by Step: "Tracking Timephased Actual Work for Tasks and Assignments," pg. 263

• Project 2007 Step by Step: "Tracking Timephased Actual Work for Tasks and Assignments," pg. 297

 More goodies

• Like this dish? See related blog posts on ProjHugger.

• Still hungry? Read previous ProjHugger posts.

###

The Project Triangle, rebranded! (Project Conference inspiration)

I have used the Project Triangle mental model to help explain project management for many years. At the Project Conference last month, however, I was reminded of an even broader mental model that fits well with the Project Triangle.

First, here's a quick refresher on the Project Triangle, or as it is also known, the triangle of triple-constraints:

The basic concept here is that every project has some element of a time constraint, has some type of budget, and requires some amount of work to complete. (In other words, it has a defined scope.) The term constraint has a specific meaning in Project, but here we’re using the more general meaning of a limiting factor.

With this starting point established, you can next see how a change to one side of the Project Triangle's element would affect at least one and possibly the other two elements. For example, in our Project Step by Step editions here is how we illustrated a change in cost (or budget) and its possible impact on time and scope in terms of the Project Triangle:

At one of the sessions I attended at the Project Conference one of the speakers mentioned a phrase we've all heard many times, but this speaker presented it via the triangle metaphor. The phrase was "Fast/Cheap/Good" and was represented something like this:

Do you see how it matches up?

• Fast is a descriptive value of time.
• Cheap is a descriptive value of cost.
• Good is a descriptive value of scope.

The way most of have heard these descriptivevalues phrased is along the lines of:

You can have it good, fast or cheap. Pick two.

Yep, that's another way of invoking the Project Triangle model! The logic works the same:

• Fast (time) and cheap (budget) may result in poor quality (scope).
• Fast (time) and good quality (scope) may result in an expensive budget.
• Cheap (cost) and good quality (scope) may result in an a late deliverable.

I find the Project Triangle to be a powerful and effective mental model. Like all mental models, though, it has its limitations. Here's the disclaimer we added to the 2010 edition of Project Step by Step and it bears repeating here:

Like all simple models of complex subjects, this model is a useful learning tool but not always a reflection of the real world. If real projects always performed as the project triangle suggests that they should, you might see projects delivered late but at the planned cost or with the expected scope; or projects might be completed on time and with the expected scope, but at higher cost. In other words, you’d expect to see at least one element of the project triangle come in as planned. But the sad truth is that many projects, even with rigorous project management oversight, are delivered late, over budget, and with far less than expected scope of functionality.

Hands-on with Project Step by Step

To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.

 

The Project Triangle model

• Project 2010 Step by Step: "A Short Course in Project Management," pg. 431

• Project 2007 Step by Step: "A Short Course in Project Management," pg. 475

 

More goodies

• Like this dish? See related blog posts on ProjHugger.
• Still hungry? Read previous ProjHugger posts.

###

Beware the Flowchart (Project Conference excerpt)

Over the next few weeks I'll publish excerpts from my talk at the 2012 Microsoft Project Conference. This week: Beware the Flowchart.

Here's my starting point. I believe the Project users/project managers can add business value to their organizations in compelling and sometimes surprising ways. Here for example is how one might look at that seemingly harmless artifact of business process visualization, the flowchart. A project manager brings with him or her an appreciation of the inescapable fact that things get done over time, and looping actions in flowcharts sadly don't result in time travel. Let me illustrate.

Here is a highly, highly simplified flowchart of a complex endeavor:

 

The items in the flowchart should be very familiar to you--they're a generic representations of a project's broad phases. It's certainly not the only such representation one could draw, but it's fine for our purposes here.

Now I can start with a flowchart like this and with a little customization and more detail, I could more or less illustrate most projects that come across my desk. I could do so in a way that would more or less make sense to my projects' sponsors, resources and other stakeholders.

Here's where my project manager focus comes in. First, let me rotate the flowchart to its side, and introduce that tasty magic sauce of project management, a timeline (TIP: click image to see a larger view):

See what I did there? I sequenced the broad phases of the project against a specific timeline. What I can't represent in this view of the flowchart though is the loop-back route out of the "Complete?" decision point. Let's see how this plays out.

Let's give this project the benefit of the doubt and say that it was initiated, planned and executed as planned--right up to the "Complete?" decision point. This point might be, for example, an integration phase of work where the components of the project come together and we find out if they work together as planned. I've drawn a progress bar through my timeline to date:

Let's say that the answer to that question, "Complete?" turns out to be...No! There are many, many reasons why this might be so. The specifics don't matter here but the higher-order bit here is this--what's the consequence of not being complete at this point in time? In the original flowchart, the consequence was a graceful loop back up to the Execution task. But what happens in the real world? I'm referring here to the real world we inhabit where time (unlike flowcharts) does not loop backwards--time travels only in one direction. Here's the result, which we call...rework! It looks like this:

The project has grown in scope (compared to baseline)--we've added rework to address whatever caused our initial answer of "Complete?" to be negative, and we've incurred an additional task to again determine if we are now, at last, done.

Sadly, we run through these additional tasks (or rework), and again determine that yet more rework is required:

We may complete the rework to everyone's satisfaction, or more likely we (or the customer) will run out of patience or money. We'll declare success (such as it is) and release the product:

Ouch, that's quite a lot of additional duration (and we can assume cost) that was added to the project just due to that seemingly harmless "Complete?" loop in the original flowchart. And by the way, you can be sure the ship party will be cancelled due to the sad ending of the project.

This has been of course a grossly simplified telling of the story, but it's based on a kernel of truth. The traditional flowchart format, with its failure to address work over time, can lead to disastrous simplifications of the true nature (and especially risks) of the work. I hope this blog post will help you work through similar problems when you discover them.

  ###

Index of 2011 ProjHugger Blog Entries

March 19 update: I'm having a problem with the image upload feature of my blog hosting service. Until I get that fixed I'm holding onto my next blog post. Hope to have it here for you shortly. -Carl

Previously I indexed my 2010 entries (here), and I now continue that tradition for my 2011 entries.

Im keeing the same three broad subject areas:

• Microsoft Project features
• General project management issues
• Knowledge workers and issues unique to their projects

 

Plus I need the catch-all "Other" for a few odd ducks.

Note also that you can always see the chronological list of posts here.

Microsoft Project Features

• Jan. 10: Alternative Ways to Track Resource Allocations
• Jan. 24: Who's Got Time? Examining Resource Capacity, Part 1
• Jan. 31: Who's Got Time? Examining Resource Capacity, Part 2
• Feb. 7: Microsoft Project, the Time Calculator
• Feb. 28: Video Demo: Introduction to Project 2010 Ribbon Interface
• March 21: Video Demo: Inactivate Tasks in Project Pro 2010
• April 4: Video Demo: Improved Paste into Word and Excel
• April 25: Resource Calendars, Part 1: What, Why and How
• May 2: Resource Calendars, Part 2: What, Why and How
• May16: The Project Map: Why Project is the Funnest Office Application
• May 23: Split Views in Project: What, Why and How
• May 30: Pan and Zoom the Timeline in Project 2010: What, Why and How
• June 27: Track Simple Resource Allocations with T-Shirt Sizes
• July 11: Timeline View FAQ
• July 19: The Case of the Disappearing Overallocations
• Aug. 1: Mail Bag: Team Planner Features, Part 1
• Aug. 15: Mail Bag: Team Planner Features, Part 2
• Aug. 29: The Deadline Date Feature: Better Than Tying a String Around Your Finger
• Oct. 24: Vacation Tasks: The Lazy Project Manager's Alternative to Resource Calendars
• Dec. 12: Inactivate Tasks, Revisited

General Project Management

• Jan. 3: The Project Manager's New Years Resolutions
• Jan. 17: Who Will Be the Future Project Managers?
• Feb. 21: Waterfall--Not Such A Bad Thing?
• March 7: Projects within Projects
• March 14: Projects within Projects, Part 2
• June 20: Of Yearbooks and Risk Management
• Sept. 5: The Controversial Yet Tasty Buffer Task
• Sept. 19: Is your Project's Variance Front-loaded or Back-loaded?
• Sept. 26: Strategies for managing front-loaded or back-loaded variance
• Nov. 7: Risk Management, Oh My!
• Nov. 14: Response to Paul Giammalvo's Provocative Question "Is Project Management a Profession?"

Knowledge Workers

• Feb. 14: Care and Feeding of the Zealots
• April 11: There's No Substitute for Reading the Face
• June 13: The Virtue of Very Small Teams
• Nov. 28: Could Your Team Survive Total Honesty?

Other

• March 28: Talk About Your Project Deliverables!
• April18: Project User Group Meeting at MS Store, Bellevue WA
• May 9: Multiple- or Single-Document Interface: What's the Deal?
• Oct. 10: Project 2010 SP1 Available, Recommended
• Dec. 26: Hope You Have the Merriest of Holidays!

Whew! That's another year of ProjHugger behind us!

###

Technical Difficulties

I'm trying to fix a problem with the ProjHugger site that is preventing you from viewing previous posts in the Archive. In the meantime, you can sequentially travel back in time through my blog posts by clicking the "Next " link below. Hope to have this fixed soon.

###

Sale! Sale! Sale!

Our book distributor O'Reilly is having a sale on the e-book format of Project 2010 Step by Step: US$11.49 CHEAP! The sale won't last long; check it out here.

Since Project 2010 Step by Step is a self-paced tutorial, give some thought to how you'll handle window management on your computer screen (or ideally, screens). You'll need to shift focus back and forth between the e-book and Project, just as you would need to shift focus between the printed book and Project if you were using the printed book. My favorite arrangement (and what I have set up at my desk) is a dual-monitor arrangement with the second monitor turned vertically in portrait mode. I find this ideal for cases where I want to scan or read content (such as an e-book or web page) on the portrait monitor, while I work in an application on the landscape orientation monitor.

If you have a single screen to work with, here's another option for you. You can very quickly arrange the two windows (in this case, the e-book and Project) vertically side-by-side with this handy Windows keyboard trick. Click on one window, press and hold the [WINDOW KEY] (that's the key with the Windows "flag" logo on it, probably near your [SPACE BAR] key, and simultaneously press the [RIGHT ARROW] key. That window will tile nicely on the right half of your screen. Now click the other window, and simultaneously press  [WINDOW KEY] + [LEFT ARROW] key. Depending on your screen resolution, you may find that both windows are large enough to be perfectly legible. This keyboard combination works in Windows 7 and I think also in Vista.

I have a long running interest in e-books in general. If you do work with the Project 2010 Step by Step e-book, please let me know via a comment below what you liked or did not like about the experience.

###

Microsoft Project and Project Management: The Venn(erable) Diagram

This week I continue exploring ideas I'm developing for my  talk in March at the Microsoft Project Conference 2012  in Phoenix, Arizona. For this week, I explore the intersection of Project and project management. I welcome your feedback to help me fine-tune this material before March.

 Let me begin with one of my favorite explanatory crutches, a Venn diagram:

What I'd like to better understand is what is unique to Microsoft Project, what is unique to the field of project management, and what is common between the two?

Here's why I pose this question: in my work in both circles above, I often see core issues about project management practice framed as Microsoft Project feature issues. Example: I've had Project users ask me "Why can't Project level my resources without pushing out the project's finish date?" When I examine their plan, I see that there's no degree of resource leveling (a Project feature) that can meet their needs because they have a fundamentally out-of-balance project in terms of time, cost (i.e. resources) and scope. Astute readers will recognize these items as components of the "Project Triangle," which I have explored previously here.

I'll cut to the chase and show you how I've illustrated this Venn diagram:

As you can see I've focused most of my analysis on the PMBOK knowledge areas as defined by PMI. If you're counting knowledge areas, it appears my analysis is is rather harsh on Microsoft Project: six of the nine knowledge areas are unique to project management and not at all supported by Microsoft Project. When I first shared this illustration with others, one person gave compelling feedback that as PMI defines Human Resource Management, Microsoft Project does indeed support this knowledge area and it should be in my middle column. It's a fair point and I may make the change.

Overall though you see just three knowledge areas from project management supported by Microsoft Project. But good news--it's the Big Three of time, cost and scope (there they are again). If Microsoft Project did not directly focus on these three knowledge areas, it would be a far less useful tool.

One quick aside

In the left-most column above I also call out some aspects of Microsoft Project that have nothing specific to do with project management. Because Microsoft Project  is published by Microsoft and its user interface is generally consistent with the UI standards of Microsoft Office applications (Hello, Ribbon!) it is pretty easy to get your hands on. The UI is inviting so you can dive right in possibly produce something useful.

But looks can be deceiving. I like to think of the Office applications (including Microsoft Project) on a spectrum. At one end, you've got my second-favorite Office app, OneNote. Everything about OneNote is optimized for what I like to think of as the instant happiness user experience. OneNote users don't need much ramp-up because just about everything about the application is designed to exploit their existing knowledge about creating and organizing their notes. Well done OneNote.

At the other end of the spectrum are the applications like Microsoft Access (relational database) and my favorite, Microsoft Project. Notice the same user interface standards as we find in OneNote, but to really get your money's worth from these apps, you're probably going to need some ramp-up time!

Hands-on with Project Step by Step

To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.

The Project Triangle

• Project 2010 Step by Step: "A Short Course in Project Management," pg.431.
• Project 2007 Step by Step: "A Short Course in Project Management," pg. 475.

Project management skills

• Project 2010 Step by Step: "Roadmap for Developing Your Project and Project Management Skills," pg.439.

###