The Bottom-Line PM: A Realist’s Guide to Using SharePoint and Microsoft Project for Project Management

Float On: Free Float, Total Float, & Slack

Pamela Flora — Tue, 21 Aug 2012 14:00:00 GMT

Please pardon the interruption, folks. My paying job has had me hopping with deliverables, and I wasn't able to whip out a high-quality post in time for publication last week. I'm sure you missed me.

But having missed a week posting –being a big fat slacker– offers the perfect opportunity to segue into my next topic, which is "slack," AKA "float" in tasks for a given project. I referenced it in my last entry as "total float." (Which, incidentally, sounds really relaxing... something I'd like to be doing, in a pool, perhaps with an umbrella drink in hand.)

"Float" is a pretty important concept in Critical Path Management. It's basically the amount of time you can let a project task slip before it adversely affects other tasks or your whole project. If you can, imagine your project tasks, linked by dependencies, as pieces of rope all tied together (a Gantt chart gives you a pretty good visual here). When you have slack in your rope, you have some leeway, and so it is with project management. With slack, your project isn't necessarily stretched to its utmost limit.

You have a couple of different kinds of slack, or float (the two can be used interchangeably, apparently, though I'm not sure if one or the other is more fashionable among genuine PMs). First, there's "free float" (which also sounds pleasant). This refers to a permissible delay that will not adversely affect subsequent tasks in a project.

Then there's the aforementioned "total float," which is associated with the path as a whole and is the sum of the total free float values in a given path.

Clear as mud? Well, have a look at the diagram and brief example on this Wikipedia page. Yes, yes, we all know that Wikipedia is a suspect source, but when I was discussing this week's topic with Mike Taylor, CEO of Innovative-e, he emailed that very link to me. And he's a bona fide Project Management Professional.

But if you don't trust Wikipedia as a source, check out this article on Microsoft's Office site.

Because this is such a key concept for Critical Path Management, you'll want to read and re-read (and then read some more) so you really internalize the idea and come to understand how float can change the landscape of your entire project.

Following the Critical Path, or, Avoiding Rips in the Fabric of Spacetime

Pamela Flora — Tue, 07 Aug 2012 13:30:00 GMT

Now that we've created some dependencies on our test project, it's probably time to take another detour from the actual doing and discuss a bit more theory.

If you have any involvement at all in PM on a regular basis, you've probably heard of the Critical Path Method (CPM) of project management. Critical Path is a mathematical method of figuring out what your project tasks (the WBS), the time those tasks will take, and the dependencies between the tasks, mean in the greater sense of your project schedule as a whole.

I'm not a math-y person, but basically, the calculation of CPM is based on determining the longest path of the tasks you have planned until the end of the project, and then calculating the earliest and latest that each task can start and finish without dragging the project out beyond its due date. By figuring it this way, the method decides which activities are "critical" and which can be delayed without pushing the project beyond its deadline. Those tasks on your task list which aren't deemed critical have what is called "total float," which means those tasks can be delayed without extending the project.

According to Wikipedia, critical path is, "the sequence of project network activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date."

Originally, CPM was based on logical dependencies and was very much about scheduling (which is one reason you need to be real about your task scheduling instead of just making up random numbers that sound good), but it didn't necessarily take into heavy account the resources necessary for a project task, and how much resources can affect duration. But of course, your schedule can be highly variable dependent upon your resources, so resource leveling, a method of allocating your resources within your project schedule to resolve resource/schedule conflicts along the critical path, was added to the CPM to more realistically calculate the actual time a project is going to take.

Changing one variable -resource or time- can cause your entire critical path to shift, and it can throw your entire project way off course. Since all of your project tasks are linked together with dependencies, and are either duration- or resource-dependent, when you're estimating your task scheduling, it will behoove you greatly to finely drill into the actual duration or resources that will be required to complete the task. While the algorithm used for CPM has some flexibility built in with float and with fast-tracking (performing more tasks in parallel) and crashing the critical path (adding more resources to shorten the path of an existing activity or to keep it on-schedule), it cannot be stated strongly enough that when you are making your estimates for a project task, the closer you come to making a real estimate, the better your chances of actually completing your project before the deadline.

So, though it may be tempting to throw around guesstimates when you're determining your task scheduling and resources just to get something down on paper (or in Project), you're not doing yourself any favors by cutting those corners. You could wind up messing up your entire project.

The way I understand critical path, it's kind of like a time travel episode of a sci-fi show. The critical path you set up for your project is one universe, or reality. But if you tweak one little variable, even just a leeeetle bit, suddenly, you could find yourself in a parallel universe -on a different critical path- and the outcome of everything will be different.

Of course, now that I've given you this dire warning about altering the universe with your project scheduling, and I Google "Microsoft Project" + "Critical Path" to see if that's the default algorithm Project uses, I come up with a Microsoft Project blog post that basically says, "Eh, critical path. Sounds scary, but really isn't so much a big deal."

So I guess the truth lies somewhere in the middle: critical path is important; it's a core piece of successfully planning and executing a project. But it is adjustable. As long as you make reasonable estimates for your project tasks, you should be golden. No need to be all Chicken Little about it.

And hey, at least you don't have to make all these calculations manually, right?

You Can Depend(ency) on Me

Pamela Flora — Tue, 31 Jul 2012 13:30:00 GMT

Remember way back at the beginning of this blog when I talked about dependencies? Of course, I had no real idea about what they were at the time. And, to be honest, I still don't know more than very high-level stuff. But linking your project tasks, as we did in last week's post helps you establish dependencies for your project, and that is a Very Important Critical Crucial Project Management Thing.

The concept of dependencies seems pretty simple. Almost all project tasks depend on something else happening before they can happen – it's like a chain reaction. If this thing or condition occurs, then that project task can occur. The succeeding task is usually dependent on a preceding task or condition. This is sometimes the case, as in many of the tasks in my previous post, but it isn't always the case. There are four types of dependencies: Finish-Start, Start-Start, Finish-Finish, and Start-Finish.

The dependencies we created in my last post are Finish-Start dependencies. Task A must be finished before you can start Task B. But, though that is a very common type of dependency, a natural dependency, it isn't the only kind.

You also have your Start-Start dependency. Once you start Task A, you can also start Task B. Task B cannot start until after you've started Task A, but you don't have to wait until Task A is complete before you get rolling with Task B.

Here's an example for you. Pretty much everything I write about here, I do at the eleventh hour. I am not that marvelously together sort of writer who has dozens of posts outlined and ready to go months in advance. Often, I don't know what I'm going to write about until the day before I have to hand the finished product in to my editor.

Much of what I've been covering lately is material I've drawn from Dux's video giving viewers a jumpstart on using Microsoft Project. Now, I could treat this as a Finish-Start task. I could watch the entire video, and then when it's over, I could sit down and write however many articles I can squeeze out of the video. But for me, it's a Start-Start task. I begin watching Dux's video, and when he covers a topic I know I can write about, I start banging out my post before I've finished watching the entire video. I can't start writing about stuff I learn from the video until I've started the video, but writing about the video can happen before I finish watching the video.

The third kind of dependency is Finish-Finish, and it is the opposite of Start-Start. With this type of dependency, Task B can only finish after Task A has finished. If Task A is my writing a post for this blog, Task B, publishing the article here on Bamboo Nation, cannot occur until Task A has finished.

The fourth type of dependency is the one I have the most trouble with. It is called the Start-Finish dependency. The second project task (what we've been calling Task B) cannot finish until the first task (Task A) begins. But Task B can finish at any time after Task A starts. I can't even think of a clear example for this type of dependency. Fortunately, there are a lot of resources out there that explain dependencies and provide examples of Start-Finish dependencies. Most of those examples involve either shift workers arriving on the job to relieve their predecessors, or the making and selling of baked goods. Based on how often I've seen project management compared to making cakes, I would hazard a guess that many PMs are would-be professional bakers, too.

Besides the types of dependencies that describe how one task relates to another, and in which the order of a task's beginning or completion affects another task's beginning or completion, there are three general reasons for creating dependencies.

Causal, or logical. One task must logically follow another. You cannot read my blog posts until I have submitted them to my editor and he has published them.
Resource constraints. One task is reliant upon resources available to begin or complete other tasks. I cannot build a new house because I have not put aside enough money to buy the piece of land I want to build on and/or I haven't had the time to hire a builder.
Discretionary, or preferential. You make a choice to begin or complete one task even though you could choose to begin or complete another task without affecting the overall project. I choose to do laundry before I clean the bathroom. Both things need to be done tonight, but the order in which I do these tasks really doesn't matter, and is completely at my discretion according to my preference.

So far, dependencies, except for that tricky Start-Finish dependency (which isn't one you'll frequently run across in the wild, from everything I've read about it), seem pretty easy, right? But there are other things that affect dependencies, including lag and lead and probably other stuff I haven't even heard of yet. And sometimes, it isn't immediately apparent which kind of dependency to assign to a given task or set of tasks. If you're stuck on deciding which kind of dependency to choose, read "Choose the right dependency type" near the bottom of this page. And in the next few entries, we'll talk about other factors affecting dependencies, and about critical path PM versus critical chain PM.

The Genealogy of Project Tasks - Predecessors, Successors, & Missing Links

Pamela Flora — Tue, 24 Jul 2012 13:30:00 GMT

All your tasks have been entered into Project and you've estimated how many man-hours they'll take (Work), or how long the Duration of each task is. That's all been your computing power. Now it's time to help Project work its magic to help you. What we're going to do today is link our project tasks within Project.

But first, there's one thing I should have told you a few entries ago, back when you were first entering your tasks into Project. I didn't realize at the time just how important it was until I started linking my tasks together, so I didn't realize I needed to share it with you. Fortunately, it's an oversight that is easy to fix. You should always have a generic task called "Start" (or something similar) and a generic task called "Finish" in your task list. Start and Finish will not be action-oriented tasks; they are anchors to hold your project tasks together. Each task on your list needs a predecessor or a successor; your Start task lets your first action-oriented task have a predecessor, and your Finish task lets your ultimate action have a successor. You don't want any of your project tasks to be left hanging on their own, without both a predecessor and a successor — this will mess up the accuracy of your project calculation. Go ahead and add the Start and Finish items to your task list if you're playing along and don't have them already.

Before you start linking your tasks, you have to schedule them all. "Wait, wait," you're saying. "Didn't we just do that?" Well, we did estimates for each project task, but we have to give them all context within the general project schedule, the start date or finish date you determined when you first opened up Project.

In Project 2010, you can manually schedule each task, which offers you some flexibility if you have a hard deadline you're trying to meet on any given task, but setting hard dates for each task can make adjusting your project down the road tricky if something comes up in the course of your project (and it always will). So for the purpose of keeping it simple, today we're going to let Project fix our scheduling for us automatically. Select your whole task list and all its info by clicking the blank header cell above the row numbers and to the left of your column headers. This operates a lot like Excel does when you want to highlight an entire spreadsheet. Click that blank cell, and it should highlight (in black) all the rows and columns in the View pane.

Once you've highlighted everything, go to the Task menu item and select the Auto Schedule button on the Ribbon.

Hey, look! Once you've given the project tasks context within the whole project by scheduling them all, Project populates the Gantt chart on the right of your screen! Never mind that I feel like I need a Rosetta Stone to really get a lot of useful information out of a Gantt chart. And never mind that my Gantt chart is not really useful until I establish some dependencies.

Well, OK, let's fix that dependency issue by linking some of our tasks. There are multiple ways of doing this, as is the case for doing pretty much anything with any Microsoft product. Dux, in his video about using Project, likes switching from the Gantt Chart view (which is what we've been using this whole time) to the Network Diagram view in order to make linking projects a more visual experience. He shows you how to do that here.

I, on the other hand, am not a very visual person with regard to diagrams and charts (which is probably why I have so much trouble getting anything useful out of a Gantt chart even after it shows dependencies). I would prefer to link my tasks the non-visual way.

In order to do that, within the Gantt Chart view, select two project task rows (select one row, and then hold the CTRL button as you select the second row), and then, in the Task Menu item, select the link button in the Schedule section of the Ribbon. It's a picture of a little chain link, handily enough. If you accidentally link two tasks that shouldn't be linked, never fear - there is a little unlink button just to the right of the link button.

How do you determine which tasks are linked? Well, basically, you're establishing the order in which things need to be done. For instance, in planning my vacation, I couldn't really book tickets until I had decided what dates I was going to be there, so I linked those two items. Booking my tickets logically follows deciding when my vacation is going to be.

And while I could pack at any time (in fact, I am already packed for my next TBD vacation! But this is mostly because I am lazy and haven't completely unpacked from my last vacation), it doesn't make sense to pack until after I've booked my tickets and made any other purchases I need to make for my trip. So I will link "pack" to the task that needs to happen just before I start packing.

For my vacation, all the items on my task list occur in kind of a linear progression. I select when I'm traveling, then I book my tickets, then I pack, then I go to the airport, and then I do all the fun airport-related stuff until I board my plane, which is the milestone marking the conclusion of my project. But for some projects, your dependencies may not be as linear as my vacation project tasks are.

For example, let's say your project requires that you secure funding. Securing funding is one of your project tasks. Once you've gotten the money, though, there are several things that can happen: with that funding in place, you can hire new staff to work on the project. You can also buy equipment that you need for the project. You can also pay for a study you must perform prior to implementing the project. Those three post-funding tasks are not linear or dependent in any way on each other — they're three parallel project tasks, each dependent on the funding being secured. So, instead of each of those three tasks being linked together one after the other in a chronological fashion (though in practice, one task may follow another instead of them occurring simultaneously), each one will be linked to the "secure funding" task. "Secure funding" is the predecessor task for each of the other three tasks.

You may also have recurring tasks that aren't necessarily dependent on previous tasks to happen first, like status meetings. You'll probably want to have status meetings before you secure your funding, as well as periodically throughout the project. Your status meeting task won't be linked to "secure funding" or to "hire new staff," though you'll probably have status meetings both before and after each of those tasks. Therefore, the predecessor to your "status meeting" tasks will be your placeholder "Start" task, and the successor will be the "Finish" placeholder, to ensure that your status meeting task isn't left adrift in your task list scheduling.

There. Now you've made an important step toward creating dependencies. You have created dependencies. We'll talk more about dependencies in the next exciting installment.

Never Underestimate the Importance of Estimates in Your Project Plan

Pamela Flora — Tue, 17 Jul 2012 13:30:00 GMT

So we've taken a little side-trip into some necessary project management theory and definitions, but it's time to get back to working within Project. Where were we? Oh yeah, we'd made our WBS, determined the scheduling (pick start date or finish date) for our project-as-a-whole, and had begun entering individual project tasks into Project (in any order). We have them listed in the Project task list: now what?

You'll remember that, as I was watching Dux's crash course video about using Project, I grappled a bit with Fixed Duration estimates, Fixed Work estimates, and so forth. And then there was that frolic down Philosophy Lane that I'm not going to rehash now, but if you've been reading over the last few weeks, you'll see what I mean.

Now, we're back to estimating what it'll take to get each project task done. When you open a new project file, Microsoft Project defaults to the Gantt View, and the default estimate type (duration, work, unit) is Duration.

If you have entered a task list that is based on Work rather than on Duration, you can add a column for Work by right-clicking the column header, selecting "Insert Column," and then selecting "Work." That'll slot a Work column right in beside the Duration column. As you're scrolling to the bottom of the column types you're able to add, you'll note that there are approximately seven gazillion types of columns you can add to tweak the values of any task in your list. Here you begin to see how minute MS Project can be, and how flexible. But for now, let's follow the KISS principle and Keep It Simple. If the tasks you're using as a task case estimate Work (as opposed to Duration), go ahead and add the extra column, but don't be tempted to add the alluringly named "Ignore Warnings" column no matter how much you like living on the edge.

It's important to note when you're estimating based on Work rather than Duration that even if a project task will only take a short amount of time or hours, you also have to factor in whether it will be done in a dedicated fashion within that time frame. Sure, it only takes me twenty minutes to book a flight, but is it going to take me a week to find the chance to get online and book it? If a task takes x man-hours to complete regardless of other factors, you might calculate based on Work. But no matter how many hours it will take to complete your task, if there will be a delay in completing it because of other demands on the time of the person working on it –or other factors that affect when it'll get done– you may want to estimate based on Duration rather than Work.

Ultimately, when estimating for tasks, you want to paint as accurate a picture as possible of when a task will realistically be completed, because the completion of tasks is what brings you closer to your goal of successfully completing your project. It's up to you as the PM to determine the appropriate way to estimate each task (whether it falls into the Work column or the Duration column). The more accurate you are with your estimates, the more likely you will be to hit your target on the overall project. And that will make you a good and effective PM. You will look like the BAMF you so totally are when you keep hitting project targets like that.

Beside each task, enter the amount of time or the amount of work required to complete each task in the appropriate column. You can enter it right into the column itself. For instance, one of my tasks is to determine the dates of my trip. I want to give myself plenty of time to look at my schedule and decide, so even though picking the dates won't really take very long, I'm going to allot a week to do it. Therefore, I will enter my estimate in the Duration column. This column's default value is measured in days, or you can enter fractions of days (like .25 day). But you can also add in other measurements of time: typing 1 m will translate to Project as "1 minute." 1 mo equals "1 month." 1 w equals "1 week." And so forth. You can change these values if you slip, and a task that you meant would take "three months" is translated as taking three minutes in Project. Note that "weeks" are business weeks –five days– rather than calendar weeks.

Unlike determining trip dates, which will take little time but might take me a while to get to, most of my other vacation project tasks – booking the flight, packing, driving to the airport, checking in and running the security gauntlet– are going to take a fixed amount of work. So my estimates for those items will go into the Work column. It is entirely reasonable for some of your task estimates to fall in the Duration column while others fall in the Work column. The two columns work independently of each other, but like The Dude's rug, Microsoft Project will tie the whole thing together into a cohesive whole.

Now that everything has been entered into Project and you have your foundation built, you're going to be linking your tasks, which is part of how Project ties the whole room together. But this, too, is a little more involved than simply dumping a bunch of ideas onto a Post-it Note or typing them into a field in a piece of software. So next time, we'll talk about how to link your project tasks, and why you need to do it.

Reconciling the Way Microsoft Project Actually Works with the Theories of Project Management

Pamela Flora — Tue, 10 Jul 2012 13:30:00 GMT

As I delve into Microsoft Project, part of what I'm grappling with is marrying the theories of project management with the way the actual piece of software works, in a practical manner of speaking. Apparently, there are a number of challenges to Microsoft's scheduling algorithm from adherents of various project management principles (including PMBOK, Prince 2, Agile, and so forth).

Tim told me that Microsoft is mostly challenged on a few key fundamentals:

The Duration Equation, which is the scheduling engine I alluded to in this post.
Resource overallocation and the automated way to adjust resource overallocation.
Critical path. Many people, including Tim, do not believe Microsoft Project can do CPM (critical path management), or critical chain management. What Microsoft Project does is highlight the longest interrelated set of tasks to the end date, which is not really CPM.

Most of that made no sense to me whatsoever when Tim said it.

"Basically," I said, struggling to follow what he was telling me, "the governing bodies for the various schools of PM thought have issues with the way Microsoft has chosen to build the algorithms, but Microsoft is all, 'Hey, you want to write the software yourself? No? Well, you're just gonna hafta deal with the way we do it.'"

Tim said that what I was touching on with my line of questions happens to be a major pain point for a lot of people involved in PM but who aren't PM wonks. He said that, frankly, Microsoft Project is too difficult for novice PMs.

"So how do we make Microsoft Project usable for people like me?" I asked. Is there kind of a "Microsoft Project Lite" for us lightweights?

Well, SharePoint kind of is the lite platform. It isn't complete - it doesn't do task scheduling or calculate dependencies, for instance - but it's a step in the right direction for people who want to take their project management off sticky notes and napkins and into a more organized system. Mostly, though, making Microsoft Project usable for regular folks who aren't steeped in PM's deep cuts, is a matter of making the concepts that drive the proper use of the platform accessible to regular folks. Once people have a better understanding of the concepts, they are then empowered to "get" what's going on with the software (which isn't as thoroughly documented as SharePoint is). So that's, um, kind of the core principle behind this whole blog. It becomes much less scary and much more usable if you have an inkling of what you're doing, and why you're doing it.

We'll get back to planning my long-passed vacation using the actual software in the next entry, but for now, I wanted to share an opportunity with you so that you, too, can dive right into Microsoft Project. If you don't have access to Project, or you're afraid you'll mess something up if you play with a real installation of Microsoft Project (you wouldn't, but I know how intimidating it can be to muck around with new software), you can test drive Microsoft Project on a virtual machine hosted by one of Innovative-e's partners, Cloudshare.

Click the Innovative-e Program Management and Information System (PMIS) environment on Cloudshare's website. This environment is in the "Productivity" tab of the SharePoint Solutions Showcase.
Fill in the fields to begin your trial period for this virtual environment.
Click "View Machine" for the green Microsoft Office 2010 Pro icon to fire up your VM loaded with Microsoft Project Professional.

Now, think about what project you want to put into Microsoft Project. Your project can be your vacation, a yard sale you'd like to have to clear out your garage, or any relatively simple project that you would like to use as a test case as you follow along here. Start with your WBS, and then start playing with Project. Review Dux's screencast if, after you've mentally put together the framework for your project, you need a nudge to actually start putting it into Project.

Next week, we'll get back to my own project, planning the vacation that I've been back from for weeks now.

The Pregnancy Conundrum, or How Many Variables Can Be Fixed in a Project?

Pamela Flora — Tue, 03 Jul 2012 13:30:00 GMT

In last week's post, I elaborated on the fixed duration, fixed unit, and fixed work variables for project tasks. I don't mean to belabor the point, but man, am I having a hard time internalizing this knowledge. Also, while I was talking to Tim Cermak about it, I realized I had a question. (Well, actually, I realized I had about 17 questions, but there's one in particular that I want to discuss today.)

In talking about fixed duration tasks, Tim said that a really good example of a fixed duration task is pregnancy. He said, "No matter how many doctors or women you add to the duration, ain't no way that baby is coming out any faster, regardless of effort."

OK. Yes. As someone who has had five children, I see his point very clearly.

However, while the pregnancy example cleared up the matter of fixed duration, it also raised questions about other fixed variables. I mean, in pregnancy, isn't the unit (what I was heretofore calling "resource") also fixed? You can't share around the tasks of pregnancy among several women. Pregnancy is one woman engaged in the nine-month task of getting that baby safely out of her belly. Believe me, toward the end of each of my pregnancies, if I could have delegated some of the more onerous bits of the pregnancy to other units in order to make it easier or shorter, I would have. But no, I was the only person who could do it. There were no other units to take over. The task was fixed in duration, but the unit (the pregnant lady) was also fixed.

In Dux's screencast, he stated that you can only have one fixed thing at a time. If duration is fixed (as in pregnancy), then the work and units are not. And yet, clearly, during a pregnancy, both the duration and the units are fixed. As with magnets, you can't explain that.

Well, said Tim, real-world examples are great to serve as the bases –the foundation– and then there are deltas and deviations from that. As in the case of using pregnancy as an example of a project (or, in this case, a task).

BUT, said Tim, the takeaway from the wrinkle in the pregnancy example, besides the fact that pregnancy is, undeniably, a fixed duration task, is that it shows just how much project management equals change and flexibility, something he told me very early on. Not everything in PM is going to be perfect or work according to a crisp equation. Being a good project manager entails being able to deal with these wrinkles and wrenches, when things don't align in a flawless, textbook sort of way.

He said that, in project management, you identify the basis –call it the baseline– and then track variances to the baseline. With pregnancy, it is one resource (unit, remember) doing the work for a fixed duration. The work may vary as the expectant mother may sleep less or do more work in the nursery or whatever. THEN, you baseline that and tweak accordingly. Theoretically, the duration doesn't change –the pregnancy will be nine months, plus or minus a couple of weeks on either side for a healthy, typical pregnancy– but some of the other variables DO change. How do those changes affect the outcome? Being able to adapt to those changes and still come out with a satisfactory end-result is what project management is all about.

One of my other questions was about whether these scheduling constraints –fixed duration, fixed work, fixed units– are something that Microsoft made up for the Microsoft Project Pro, or if they're general PM principles. "Ahhhh," said Tim. "Now we crack open and peek inside Pandora's Box."

But that is another topic for another day.

Also, Dude, 'Fixed Resources' is Not the Preferred Nomenclature ... 'Fixed Units,' Please

Pamela Flora — Tue, 26 Jun 2012 13:30:00 GMT

I was preparing to dive back into Microsoft Project and get back to budgeting my task resources for my next entry, when I got an IM from Tim Cermak, who is one of my spirit guides on this "reluctant PM" journey.

He noted that, in Microsoft Project, you don't have "fixed resources," as I wrote in my last entry. You have "fixed units." It's a good thing for all of us that Tim and Dux are looking over my shoulder, or I'd be leading you astray in these pages.

I asked Tim if the concept is the same - are "units" the same thing as resources? He said yes. He told me that "fixed units" is the default setting out-of-the-box (OOTB), so unless you tell Project otherwise, it's going to count your resources - units - people working on a task - as the fixed thing. Does that make sense?

Whenever I talk to Tim about this blog project, we talk for a minimum of an hour, largely about the conceptual stuff that I find endlessly fascinating. Normally a conversation with Tim yields four or five blog entries. It's awesome.

I told Tim that I was still having trouble wrapping my head around the equations allocating units, duration, and work. He said it can be really tough for "regular" people like me who haven't been schooled in PM principles. I guess it'll just take a lot of practice projects for me to begin to assess and allocate like a real PM, and for the mindset to feel more natural and automatic.

Tim said that the Duration Equation can be especially tricky for some folks. In my last entry, I defined Task Duration as "how long each task is going to take - the starting point, the end point, and the points in between." He said that was spot-on and, if I may toot my own horn for a moment, he said it was a great explanation that some folks with more PM experience wouldn't have been able to explain as well. I would love to take credit as some kind of PM savant, but really, it's just that the duration of a task seems pretty cut-and-dried for me. Tim said to tuck into my back pocket that a number of things can make duration considerably less cut-and-dried: resource calendars, task calendars, and other things affect the scheduling algorithm within Microsoft Project, and all those things combine to make up the Duration Equation.

Tim said one really good example of a fixed duration task is baking a cake: If the instructions say you should bake it at 325 degrees F for 50 minutes, you can't increase the heat to 425 degrees for 30 minutes and expect the same results.

An example of fixed units, on the other hand, is the fresco on the ceiling of the Sistine Chapel. Michelangelo was the sole, fixed unit on the fresco task of the Sistine Chapel project. The duration was variable according to how much Michelangelo worked - he would have finished earlier had he sunk more work/effort into the task, and finished later if he'd slacked off and expended less work/effort. The work/effort and duration were fluid and dependent on each other, but the unit, Michelangelo, remained constant throughout the task of painting the ceiling of the church.

And of course, then you have fixed work, which is the effort, or man-hours that go into a task. I have recently acquired an intern to help me over the summer, and he has committed to putting in about 20 hours a week working on what I have for him. The tasks I give to him are things on which he will not work for more than 20 hours a week. Therefore, the work is the fixed variable.

I know I explained this all last week, but I got it (a little bit) wrong. And I figure that if I'm having trouble grasping the concept when you look at it in greater depth than just fixing one or another simple variable, it might behoove other people who aren't necessarily PMPs to have a review. We'll get back to working on our projects in Microsoft Project shortly, I promise. But let's make sure we have the concepts down pat so we actually know what to do with Project when we open it up and it's staring us in the face, yes?

Estimating, Not Guesstimating Using Fixed Work, Duration, and Resources

Pamela Flora — Tue, 19 Jun 2012 13:30:00 GMT

So. We've built our WBS and we've determined our project schedule. Now, finally, we're ready to start putting tasks into the View pane of Microsoft Project.

Dux recommends, in this crash course screencast, that the first task you put in is either a start task or an end task. Aside from that, though, you can put the tasks from your WBS in any order. You'll order these things later. For the moment, just list them off in whatever order you think of them (or whatever order they're in on your WBS, or whatever). Point is, you don't have to worry about the order of your tasks quite yet. Just plug them into the cells in any order in the "Task Name" column.

When I was creating my WBS, I listed things off roughly in the order I needed to do them. But as I was putting my WBS items into Project, I realized that I'd left an important item off my WBS list: selecting dates for the vacation. My impulse, when plugging these tasks into Project, was to go back and add a row so I could put "Select dates of vacation" before "Drive to airport." I don't even know if that's possible, adding a row. It looks kind of like Excel; does it behave like Excel? But I overrode my neurotic need to order my tasks properly at this point, trusting that there is a mechanism later for ordering them, and stuck "Select dates of vacation" (what would be the second item on my task list) between "Drive to airport" and "Park car in long-term parking" (considerably further down on my task list). Because Dux told me that order doesn't matter at this point. This is putting your brain dump (WBS) to paper, and is, at this moment in time, also a brain dump – just into the software rather than on paper.

Once I got all my tasks in, I saved the file with a descriptive name. Because that's just how I roll.

Now, I've got the first two steps of my project done in Microsoft Project 2010. I've defined a schedule and I've put my project tasks into the software. This has been remarkably easy. I'm sure there has to be some big bad something lurking around the corner to make this whole thing a lot more difficult than it has been so far.

Step three is entering estimates for each task. How long is each task going to take, how much work is each task going to take, and how many resources do you have at your disposal to get this task done? You're measuring three things when you put in your estimates: duration, work, and resources.

This is, obviously, a little more involved than just brainstorming all the stuff you've gotta do to make your project happen and throwing it into a table. You have to drill down into each task, and you want to carefully consider the amount of time, resources, and work you're allotting to each task, rather than throwing in some random number to fill in the cell so you can move on to the next thing. If you put in an inaccurate number just to have something, anything filling that field, it's going to throw your whole project off.

Determining the duration and work and resources can be a little bit tricky. It's a whole other way of thinking, a very specialized groove into which to fit your gray matter.

Duration is how long each task is going to take - the starting point, the end point, and the points in between. If the duration of your project task doesn't change no matter how many resources you have or how much work is going into it, this is called, handily enough, "fixed duration."

Work is how much effort goes into making your task happen. It is generally something you can estimate based on previous experience with a similar effort: you know it's going to take you about 20 minutes to shower in the morning, because you've taken countless showers in your life; the work you calculate for the "cleaning self" task is 20 minutes. Work can be varied tremendously depending on how many resources you put into a task. The work estimate is the sum of how much time your resources put into the task: man-hours. If the work is the same no matter how many people you put on a task, it's called "fixed work."

Your resources are your people working on a task. (Your resources can also be material resources, but for the purpose of this formula, your resources are the folks doing the work.) I know it's going to shock you that if you have the same number of resources assigned to a task, it's called "fixed resource."

For each task, you can only have one fixed thing. If your duration is fixed, your resources and work are fluid. If your task is fixed work, your resources and duration are likely to change as you alter the ratios. And so forth.

It should also be noted that this whole time, I have been talking about estimating for individual tasks, not for the project. When we're estimating the duration, we're estimating the duration of each task, not the duration of the project itself.

Finally ... Actually Working in Microsoft Project 2010

Pamela Flora — Tue, 12 Jun 2012 13:30:00 GMT

So in real-time, I'm back from my vacation and I had an awesome time, thanks for asking. But in blog-time, I am still planning the vacation from which I just returned. I have been watching Dux's video about how to use Microsoft Project and kind of following along as he goes. I have created my WBS, and I think I'm just about ready to actually open up and use Microsoft Project 2010.

I figured that, once I had my WBS items –the brain dump of tasks I need to complete in order to make my vacation project happen– I would put them into the task list in the "View" pane of Microsoft Project.

Apparently this isn't the case.

Let me back up for a minute, though. If you open Microsoft Project (why don't you do it now?), there are three main parts of the workspace on your screen.

On the top is the Ribbon, which is where all your menu items are.

On the left center portion of the screen is your "view" pane. It looks a lot like Excel, and is blocked off into rows and cells much as a spreadsheet is. These rows and cells comprise the table that makes up this view, and the table is customizable to work with your particular project. The Gantt chart view is the default, but again, this can be changed. There are lots of out-of-the-box (OOTB) views from which to choose.

To the right of the View is the schedule. This will give you a graphical idea of how your project is coming along in terms of timing.

Now that you know the main parts of the workspace, you're still not going to just start typing in the tasks from your WBS. Before you do that, you have to do some work with the scheduling of your project. What's the start date? What's the end date? When you've defined the scheduling for your project, go to the Project menu item in the Ribbon, select Project Information, and plug the schedule for your project into the dialog box that pops up.

My friend invited me to come visit her back in April, so my project start date begins then. Because I am a fly-by-the-seat-of-your-pants kinda gal (well, I'm trying to learn how to be spontaneous), I am not planning anything for while I'm on vacation. So my project schedule effectively ends when I step on the plane to fly up to Minnesota, on June 1. When you're plugging in the dates for your project into Microsoft Project, you can only schedule from the start date OR from the finish date, but not both.

So I've determined whether I want my project to be scheduled from my start date or my finish date. I selected "Schedule from Project Finish Date" because I've already done a lot of the early legwork for my project, and the finish date is looming. I'm not sure, at this point, if this schedule method is going to work out for me or not. I'll keep you posted. Now that I've entered the relevant dates and scheduling method, I'm ready to close that info window and start entering my tasks into the View pane of Project.

At last!

Now we're cooking with gas. And actually, it's been pretty painless so far! What in the world was I afraid of all that time I was dithering?

If You Build It (a WBS), Your Project Will Come (Together)

Pamela Flora — Tue, 05 Jun 2012 13:30:00 GMT

As this is being published, I am in the midst of enjoying the vacation that, in these blog posts, I am planning. Behold, the power of modern technology! Time travel! With any luck, I have remembered to turn work emails off on my phone and am currently enjoying the heaven that is Minnesota in June without any disturbances. I might be camping by Lake Superior even as you read this.

OK. So I know I told you in the last entry that this one would be about how proficient I suddenly am at using Microsoft Project. Alas, epic tales of my success at jumping into Project 2010 will have to wait. Apparently, I was putting the cart a little bit ahead of the horse.

As I was watching Dux's video primer on using Microsoft Project, he said that he, as a programmer, first fired up Project intending to conquer it the first time he looked at it. You know, kind of like I promised to do in my last post. He also said that Project kind of assumes that you're familiar with some of the fundamentals of the PM process. Which, as an IT guy, he was not. He says, at about 10:30 in the screencast, that once he opened up Project, he just kind of stared at it for a couple of hours, not really knowing exactly what to do with it.

Suddenly, I don't feel quite as stupid as I did before. If even Dux, who is now a PM rock star, grappled with Microsoft Project the first time he looked at it, then maybe I'm not the complete moron I was beginning to think I might be.

But I'm not avoiding my project! OK, so I'm not rolling up my sleeves and becoming an instant Microsoft Project guru, but I'm finished with philosophies and avoidance for the moment. I'm doing the thing.

Watching Dux's screencast, I realized that before I do anything with Microsoft Project, I needed to create a WBS. A WBS is a Work Breakdown Strategy, and it is one of the very first things you do when you're planning out a project. Dux discusses how to develop a WBS in a screencast called Project Planning 101. When I was chatting with him about it after realizing I needed to do this before I do anything in Project, Dux described a WBS as a "brain dump." You just throw in all the things you need to do in order to make your project happen so you can see all the various components and contingencies of your project laid out before you. You're not organizing it, you're not ordering it, you're not arranging it – you're just brainstorming all the stuff you're gonna need for your project to come together.

So I sat down with old skool pen and legal pad and drew out a basic WBS for my vacation. Once I decide to take a vacation, what steps should I take to make it happen, from conception to stepping off the plane? Dux recommends using a mind map, but for very simple projects, you can probably just make a list. Like on a napkin or something, if you don't have a legal pad handy.

My particular WBS goes a little something like this (a-one and a-two and...)

Select location
Select accommodations (for me, steps 1 and 2 go hand-in-glove: a friend in Minnesota invited me to come see her and stay with her, and thus my vacation was born)
Book flight
Send friend flight itinerary
Research and plan activities
Create packing list
Do laundry
Pack
Research airport parking (because I don't travel often, I have never used the long-term parking at the airport, and I don't know how to do it)
Research luggage limits and parameters (really, I should get out of the house more often. I know nothing about how to travel any way but by car)
Pull cash for trip
Put together documentation/paper for trip (driver's license, plastic money, paper money, itinerary)
Go to airport
Turn off work email on the phone so I am truly, blissfully disconnected from civilization
Fly off into the wild blue Minnesota
Begin an awesome week of vacation with my friend

For you, your vacation WBS might include getting a pet-sitter, stopping your newspaper, arranging to have someone drop you at the airport so you don't have to pay for long-term parking, and other items pertinent to your own vacation (project). It's vacation season, so why don't you play along, if you're new to Project 2010, too?

We are not, in fact, the only people who have used Project to plan a vacation. Arpan Shah, who used to be the Director of Microsoft Project and is now a Director on the SharePoint Project Management Team over at Microsoft, planned a three-month sabbatical using Project Professional. I am doing it for practice, because my trip is simple and I already know what few things I need to do, but Arpan's Project plan was both real and practical.

I have only just begun paying attention to my WBS, so as I watch the screencasts more, I may have more items to add to it. In fact, I almost certainly will, because I am forgetful. Some of my tasks will have sub-tasks. Some of my tasks may have dependencies (which is the relationship between the tasks and what needs to be done when, if I'm understanding correctly). I am going to finish watching Dux's screencasts and then sit back down with my WBS, add whatever squiggles it needs, and then, maybe, I'll be ready to plug some of this data into Microsoft Project.

Microsoft Project: The Adventure Begins

Pamela Flora — Tue, 29 May 2012 13:30:00 GMT

I have been undertaking a diet –well, "lifestyle change"– for a little more than a month now. I did a lot of prep-work for it. I set goals, I bought gear and apps, I researched my methodologies, and I started a blog to keep myself accountable to strangers on the Internet in preparation for my "lifestyle change." I was faithful about wearing my fancy little pedometer, logging calories into the app on my phone, and updating my blog with my weigh-in figures. I was not, however, quite ready when I launched this self-improvement project, to start with the exercise component of my "lifestyle change."

So in order to avoid actually having to do exercise, I wrote about it. I philosophized about it. I wrote about what I'd learned from my research about exercise. I wrote my rationalizations for putting off exercising. I did pretty much everything related to exercise that could possibly be done from the potato-y comfort of my couch.

Until I started doing the same thing here in regard to tackling Microsoft Project, I didn't realize that writing –producing content, doing something that, at first glance, is a productive activity– is an excellent avoidance tactic for people like me.

All these weeks, I've been avoiding Microsoft Project by writing around it. The same rationalizations, research, philosophizing that I did with the exercise on my diet blog, I've done here about Microsoft Project. For all that I've been producing what would translate to reams of written material, it hasn't really been productive at all.

Well, a few weeks ago, I decided to stop talking about exercise, get off my considerable-sized badonkadonk, and hit the trail and run. (I still hate it.) And today, I decided to stop talking about Microsoft Project and actually open the software.

When I first open it, it looks not unlike Excel, so it doesn't appear as intimidating as I made it out to be, in my mind. But when I decided to put pen to paper, so to speak, and begin entering tasks from my chosen project (planning my upcoming vacation), I didn't really know, uh, where to even begin.

It sounds ridiculous, but, like, do I just start typing my stuff in the fields? Do I have to enter it in a special place or do I start plugging info into the Excel-like rows and columns as I would with a simple little ol' spreadsheet? Once I have the tasks in, what do I do with them? What do all those buttons in the Ribbon do? Why am I looking at the Gantt Chart Tools Ribbon as a default? Why, as a reasonably intelligent person, can't I figure all this stuff out? Why, when I bravely plunge in elbow-deep on other unfamiliar tasks all the time, does this one thing make me so twitchy? Why did I agree to do this whole project management thing in the first place?

Dux to the rescue again. A couple of years ago, he did a webinar, in partnership with O'Reilly, called Plan, Track and Control Projects with Microsoft Project 2010. He said that should be my crash course for Project. That's what'll answer at least a couple of the questions in the above paragraph.

So if you'll excuse me, I have a video to watch (it comes in two parts, about an hour each, archived at the link above). The next time you hear from me, I'll have actually put some sort of information into my Vacation Project on MS Project. Who knows, by then, I might even have made a Gantt chart of it. And if I'm feeling particularly ambitious, I might have actually learned how to read a Gantt chart. Hold your breath, m'kay?

On Planning for Project Planning

Pamela Flora — Tue, 22 May 2012 13:30:00 GMT

I've been talking to Mike, the founder and President of my company, Innovative-e, about my recent PM dry spell and my nervousness about approaching Microsoft Project.

It certainly isn't that I think Microsoft Project is a bad piece of software (I've only used it once; I wouldn't know). It's that, despite what I have previously penned in these very "pages" about the apparent usefulness of Project, I am still intimidated by what is a very, very powerful piece of software. And despite the entire premise of this blog, I am still intimidated by the concept of being a Project Manager. No matter how many times in my daily life I do the same things that a PM does - planning, budgeting and allocating resources, projecting a timeline, and so forth - to give what I'm doing so lofty a name as "Project Management" changes it and makes it seem so much more A Thing.

I suppose these two particular stumbling blocks are the result of a very basic inferiority complex. I am good at what I do, but let's face it, what I do at work is not, in the grand scheme of things, tremendously important. I mean, yes, it's helpful to the company, but I'm not a Big Dog like a PM is. I'm just a peon. One of the little people. To ascribe PM-level importance to me is vastly overstating what I do and my importance to the company. Too, though I'm a reasonably intelligent person with a pretty strong tech background, Microsoft Project is so powerful and big that I'm afraid I won't be able to use it properly. I don't even know where to start once I launch it.

It's always easier to play with software if you have a few test cases, and I've found that, with only a couple of items to put on a task list, this blogging project alone isn't a robust enough test case to use Microsoft Project effectively. And I was floundering, trying to figure out what I could use as a test case that would let me face my fears and dive into Microsoft Project.

So when I was telling this to Mike, he recommended that I fire up Microsoft Project and try plotting out a project I have already completed, in order to see how the engine(s) of Microsoft Project does its thing. Further discussion of the topic with Dux had him recommending that I take something really simple, but not yet completed, to try out Project. My mindset has been that you can only use Project for something as complex as the software itself; that something you could make a checklist for on a Post-It note isn't really worthy of Microsoft Project.

I am trying to rearrange my thinking on this, or else the next umpteen posts here are going to be about my lack of inspiration and my fears of software designed to help me manage these things, and I am trying to get out of stasis here.

So I'm going to think about "projects" past and future that have required a level of planning and resource allocation, even very simple planning with very minimalist resource allocations. I have a vacation coming up that I am going to plug into Microsoft Project. That should be simple enough to manage, shouldn't it? I am in the middle of documenting the process that we, as a company, use when we present webinars to the public. That should be something I can use Project for, right? (Plus, as an ongoing process, it should actually have some useful application.) Since both of these are relatively small things, and since practice supposedly makes perfect, I'm going to try to think of a few more things, in both my personal and professional lives, which I can plug into Project so that I can overcome my nerves about it by lathering, rinsing, and repeating repeating repeating.

Assessing One's Own Project Management Skills

Pamela Flora — Tue, 15 May 2012 13:30:00 GMT

The confluence of our busy season at work and a distinct lack of inspiration lately has had me floundering for topics to cover. I haven't been doing very project manager-y things at work lately, so the wellspring from which I usually draw topics has been pretty dry.

The theory of capital-P, capital-M Project Management still fascinates me, though I haven't had the time to give it a lot of thought lately. Perhaps I'm just avoiding actually delving into the Big Bad Boogeyman that is Microsoft Project by lingering on the schools of thought that drive project management, but it seems to me that learning to be effective at managing projects requires comfort with the underlying premises and theories of project management. I don't think I'm rationalizing (and avoiding) too much with the continued contemplation of theory.

It may also be that, as well as my having been too busy at work to spend a great deal of time mucking around with project management software and thinking about the theoretical foundations of project management, part of my lack of inspiration lately is because, for all that I've been doing this blogging gig for a couple of months, I don't feel much like a project manager. It's still kind of like playing house at this point, and I'm having trouble thinking of myself in that role.

My colleague, Dux, gave me a book to read called Making Things Happen: Mastering Project Management, by Scott Berkun. Dux says it's one of the best PM primers out there. I started reading it about seventy-five years ago before actual, real, paying work intruded. The first six pages or so read very smoothly, like it was going to be a fast and informative read, but then stuff happened and I put it down. I've been meaning to pick it back up, and hope to return to it starting this week or next. I think it's going to give me a good bit of practical theory, and I hope that maybe immersing myself in that will get me back on track with this here blogging project.

In the meantime, casting about for something, anything to write about, I plugged "How to be a project manager if you're not a project manager" into Google, hoping something in the results would tickle my creative bone. One of the top results was a Mind Tools quiz on How Good are Your Project Management Skills?

Hopeful that my PM skills were better than my keeping-up-with-a-blog skills, I took the quiz. For the purposes of the quiz, since I don't have an actual project team here at work, I thought about how I manage my family. (It was, surprisingly, mostly applicable for the bulk of the questions.)

I scored a 64 on a scale of 1-100, which is very firmly middle-of-the-road. Basically, my PM skills are OK, and simple projects usually go pretty smoothly when handled the way I handle things. But more complex projects may be beyond me at my current skill level. When applying my skills to an actual, real project involving professional constraints and, you know, adults, I need to beef up my pre-planning process and ensure I prepare better for unexpected wrenches in the works.

The nice thing about this quiz, besides allowing for a quick self-assessment (though I can't speak to how accurate it is, from the standpoint of an actual PM), is that as you're reading the questions, you can kind of interpret how you should be answering them, regardless of what your actual practice is. I kind of had an idea of where I needed to hone my skills as I was going through the quiz.

So how about it - how do you measure up? Are you stuck in the middle and very average like I am? Do you need a PM intervention? Or do you have all your PM ducks in a row and you're waiting for your Nobel Prize in project management to be announced?

Real-World Collaboration in Action with SharePoint Online & Office Web Apps! (I Love It When a Plan Comes Together)

Pamela Flora — Tue, 08 May 2012 13:30:00 GMT

I recently had to step away from my test case - this blog project, which is a bit of a work-play thing for me - in order to actually do some real-world work. My company received an RFP from a major organization a week before the proposal was due. Because this was such a big project for a big organization, we couldn't rely on boilerplate proposals. So we had a week to put together a very comprehensive proposal from scratch.

Pre-SharePoint, we'd have been emailing revisions of the document back and forth, and version control would have been tricky at best and a total mess at worst, at a time when we couldn't afford anything but a streamlined authoring process. We took it one step further and used SharePoint Online, the Office 365 SharePoint offering, which puts everything on the cloud and allows for real-time collaborating and authoring by multiple persons simultaneously.

Office 365 officially launched last summer, and we, being the eager-beaver early adopters that we are, immediately created an Office 365 project site to help us corral some documentation pulled together by many hands for a SharePoint Saturday conference we were helping to host and organize. At the time, Office 365 wasn't quite yet ready for prime time - a lot of people who needed to access the project site weren't able to get in, and we fell back on the old nasty habits of files flying back and forth via email instead of being put in a central spot where all pertinent folks could access all the files.

This time, however, Office 365 performed admirably and helped us do the near-impossible and build a large proposal from scratch in a week. We put the document up on SharePoint Online, and up to four people could make changes to the document at once. We could see who else was in the document, which sections they were working on, and, with a refresh, we could see the changes each author had made. Everything was in real-time, and there was no lag between tweaking this or that section and having that new and improved version of the document available to all the team members working on the proposal. I had read the whitepaper we did for Microsoft about using Office 365 for collaboration, and even written a small piece showcasing a video of the co-authoring process, but watching a video of it is in no way nearly as cool as seeing it in action on a piece of work that matters to you.

Seeing it come together flawlessly and work exactly as it should work was... it was like watching magic happen and not knowing how it happened, but appreciating the trick as a feat deserving nothing less than utter wonderment. It was that "I love it when a plan comes together" moment than Hannibal from the A-Team referenced every episode. (There were fewer explosions involved in the coming together of our plan, though. More's the pity. That would have been a great way to spice up a workday.)

We discovered some quirks in the process, however, and knowing about them might serve you well should you decide to make your own co-authoring plan come together:

Only four people at a time can work on a document. I'm not sure if others can view it, so you can have, say, four co-authors and two people looking at it on a read-only basis, for instance. But no matter how many pairs of eyes can look at the document at a time, only four pairs of hands can be working on it. At first, the four-person limit seems, well, limiting, but then, how many hands do you really want on your document at a time, anyway? Too many cooks spoil the broth, and too many co-authors ruin the proposal.
Another user's changes will not be visible to you until they save. Likewise, nobody else will be able to see what you've done until you save your changes. Save often when co-authoring. I just got in the habit of saving every time I made a tweak.
We found in a couple of instances that the document would kind of lock if one person tried to work on the same section another person had just finished with. Again, saving is the key. Whomever last made changes to that section must save it not only to make their changes visible to other users, but also to make that section editable by other users.
You can either edit documents in your browser or open the document in Word, Excel, or OneNote. (We were using Word.) Office 365 doesn't play tremendously well with 64-bit browsers, and locating your 32-bit version of IE may be a bit of a trick, if you're running a 64-bit OS. Hopefully, Office 365 will soon work seamlessly with 64-bit browsers, but until then, fire up your 32-bit IE and use that for your co-authoring efforts. Dux also pointed me to a page discussing accessing data-sheet view with 64-bit browsers. While the issues I had used Word, and I think the data-sheet view probably refers to Excel, there is good knowledge in that link.