projhugger

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.

###

See You At the Project Conference

This March I plan to attend the Microsoft Project Conference 2012 in Phoenix, Arizona. I'm now preparing a talk I'll give there. Here are some details.

The conference website is here. There are three tracks:

• Business Value & Insights
• Deployment Administration & Developer
• Product Sessions

So regardless of your connection to Project, there's likely something for you.  

 Here's the title and abstract of my talk:

Care and Feeding of the Zealots: Why Project users are disproportionately invested in their product, and how you can help spread the love.

Have you ever noticed how Microsoft Project users tend to be much more invested in their use of Project than are most users of word processors, spreadsheets and e-mail programs? It's a fact: per person, Project users will invest far more time, money and sweat (and occasional tears) mastering Project as compared to most users of, say, Word or Outlook. In his role as coauthor of the bestselling Project Step by Step self-paced tutorials, Carl has spent well over a decade studying the mysterious Project user. Carl's conclusion is that Project users really are special. The more successful they are with Project, the greater their career success. This is true for professional project managers (many of whom are equally invested in formal certifications such as the PMP) and people who'd never identify themselves as project managers yet deal with many core principles from this field. Once you understand what motivates Project users (including yourself), you can then develop a strategy to tie your Project and project management skills to the business value generators that matter most to you and your organization.

Hope to see you there!

###

The Predicament of Problem-Solvers

One smart writer I follow makes a compelling distinction between problems and predicaments (here). Some people might think these two terms are interchangeable, but they are not. The difference is best shown through illustration.

First, let's look at a problem:

 

The climber has a problem to solve (or more likely a set of smaller problems). The resolution will see him arrive safely up with his buddy. Then he and his buddy face another set of problems to descend. The key point is that these are solvable problems. The climber can reach his goal. He might not be successful, but success is possible.

Contrast this with this illustration of a predicament:

 

This adventurous lad finds himself in an predicament we can call freefall. No matter what else our diver might want to happen, he soon will deal with the issue of landing safely in water (we'll assume there's water below). No set of risk management skills, no amount of prepping can change the expected outcome of his situation at this moment: "I'm in the air, headed for the water below at high velocity."

While a problem is solvable, a predicament is not. While a problem might have many possible outcomes, a predicament has essentially one, and try as you might you can't change it. You can think of a predicament as the surrounding environment in which we may find ourselves and basically we have to work within the constraints of the environment. The midair diver cannot change the laws of physics or alter gravity to avoid falling into the water. The climber on the sheer wall however can (we'll assume) apply specific skills and techniques to move himself up (and later back down) the mountain. Do you see the difference?

Now in both examples I've chosen, both the climber is working within some predicaments and the diver is applying some problem-solving. Notice our diver is pinching his nostrils closed, for example. This will prevent water from shooting up his sinuses (problem avoided) when he inevitably reaches the water (his inevitable outcome).

Our climber likewise is working within the predicament as he applies his problem-solving skills. In this case his predicament is established by the conditions of the mountain he's on, the weather, and even his own prior training and skills development. If he discovers that he forgot to bring an essential piece of equipment with him that he'll need in two seconds, that too is part of his predicament and not a solvable problem.

Now, let's consider this predicament/problem distinction as it applies to project management and knowledge worker teams. I believe this is worth exploring because I sometimes see smart people try to apply their considerable problem-solving skills to what are at the end of the day predicaments.

Predicaments are, essentially, constraints that the project manager or team must work within. I don't mean "constraint" here in the narrow technical sense that Project users may be familiar with, such as a "Start No Earlier Than" (SNET) constraint. Instead, I mean the broader aspects of the project's environment that the project manager cannot fundamentally change.

In my own projects, I usually find that I am resource- and time-constrained. My budgets are defined by others, and generally do not increase (but can decrease) in the short term. My most critical deadlines are likewise usually externally imposed, and not flexible. If I try to apply my resource and time management skills in problem-solving mode, I will at best optimize the situation but cannot fundamentally change these constraining aspects of the project's environment.

If I think that I ought to be able to "solve" a predicament in the same sense that I might solve a problem, the likely result is what we call frustration. I frequently see very smart people mistake a predicament for a problem, then burn themselves out applying problem-solving strategies to these non-problems.

Conversely, I might instead mistake a very solvable problem as a predicament and fail to properly address it. This can be just as bad. In fact, it's worse because it leaves potentially solvable problems unaddressed.

The next time you're working through the defining issues of a complex project, give some thought to this question: What here is a solvable problem, and what is a predicament?

 

(My thanks to financial blogger Chris Martenson for illustrating the problem/predicament distinction so well.)

 

###

Hope You Have the Merriest of Holidays!

See more fine artwork by George Wise here.

I'll be back in January 2012 with more tips, tricks, musings and even a few gripes about Microsoft Project and knowledge worker teams.

###

Inactivate Tasks, Revisited

Recently I  had reason to use one of the cooler new features in Project 2010, Inactivate Tasks. I briefly explored the Inactivate Tasks feature back in April 2010, here. I liked the feature then, and I like it even more now. This feature is available in Project Professional 2010 only, and not in Project Standard 2010.

I was looking at a fairly simple schedule created by a team manager who had a small number of resources, a small number of tasks, and just two phases into which he needed to organize the work.

The tricky bit was that the manager was trying to size the phases to end by some externally-driven dates that were not yet stable. He wanted an easy way of representing two possible schedules, depending on when the first summary task might need to end. Here's a simplified view of the schedule we started with:

 TIP  Click the screenshot image to see a larger view.

The question we could not answer is exactly when the first summary task, which I've labeled "Sprint 1," would have to be completed to meet an externally-driven deadline. We did know that it would likely be some time in the first half of February, however. In fact we could see that if we could move the task "work package D" to Sprint 2 if needed, we'd have an easy way of adjusting the duration of Sprint 1 to end earlier if needed.

The most obvious way to accomplish this would be to just move (cut and paste) the task "work package D" from the first to the second summary task, and then relink it correctly. However I saw this as an opportunity to use the Inactivate Task feature to good effect. First, I copied (not moved) work package D to appear in both summary tasks (tasks 5 and 7 below):

This is clearly not correct, but hold on we're not done yet. Next, I inactivated the second occurance of the task "work package D" (task 7) so only one active occurrence of it remained (task 5):

By inactivating the task, I've kept its information in the project plan but the task has absolutely no impact on the overall schedule. As I reported back in April 2010, inactivating tasks lets me "line out" tasks and leave them right in the project plan. Inactivated tasks are visible in the plan but have no scheduling effect on the plan, including critical path, cost, or resource availability.

In this use of the feature, I've created a simple little toggle to represent work package D either in Sprint 1 or in Sprint 2. Here it is inactivated (task 5) in sprint 1 but now activated in sprint 2 (task 7):

I've used a simple example here to illustrate how representing a task in one summary task or another affects the summary task's duration. I could use the same technique to account for some variable budget or resource capacity as well. The key thing is that I think of the pair of duplicate tasks ("work package D" in this example) as a toggle--if one is active, the other sould be inactive. This is quickeer and perhaps a little less error prone than physically moving the task from one summary task to another or back again.

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.

Inactivate tasks

Project 2010 Step by Step:  "Inactivating Tasks," pg. 175 and "Troubleshooting Scope-of-Work Problems," pg. 311.

Project 2007 Step by Step: None! This feature is new in 2010 Professional.

 ###

Could Your Team Survive Total Honesty?

Imagine a discourse community where all communication is open to everyone, and nobody can communicate anonymously. Everyone in the community is identified by an "alias," but everyone else in the community has the means of looking up anyone's real name (and even their home or mailing address) based on their alias.

Now imagine your knowledge worker team operating with this level of open, attributable discourse. How would that work out for you?

Lately I have been studying just such a community. It's the "Ham" radio crowd--the licensed amateurs who operate transceiver stations and communicate with each other literally around the world. Here are some rules of amateur radio:

• You must be licensed to transmit.
• Your transmission cannot take the form of a secret code. Morse code (or "CW" for Continuous Wave, as the Hams call it) is fine but Morse code is of course an open code.
• You must include your call sign in your transmissions, and the holders of all call signs are listed in a publically accessible FCC database. Consequently nobody can legally transmit anonymously.
• Volunteer members of the Ham community can and do enforce the rules and norms.

When I learned all this about amateur radio,  I thought about teams of knowledge workers and how they communicate. Some observations:

• One-to-one e-mail is for all practical purposes private communication.
• Posting comments to a team bulletin board or similar online collaborative tool, however, is an example of one-to-all open communication.
• Anonymous communication is not normally allowed in most knowledge worker teams I know of, but it might happen.

I wonder if too much openness and honesty within a team of knowledge workers could ever be a bad thing? Do the hierarchies and specialized roles one typically finds within knowledge worker teams  make a truly open discourse community possible, or even desirable?

The Ham radio community and knowledge worker teams have rather different goals in mind, of course. Nonetheless I find it compelling that the Ham community is able to follow such practices for open communication and accountability. What do you think? Let us know in a comment (and preferably not anonymously).

###

Response to Paul Giammalvo's Provocative Question "Is Project Management a Profession?"

Recently I came across a thoughtful article on MPUG that merits some thought and a response. Here's mine.

The article is titled "Is Project Management a Profession?" and was published on the Project User Group (MPUG) site here. You should be able to access it whether you are an MPUG member or not (although I encourage MPUG membership).

What I really like about this question is that it's bound to stir up strong responses, especially from those whose professional identity may be wrapped in the title "Project Manager." I'll disclose now that I agree with Giammalvo's answer--no, project management is not a true profession. Here's why I believe this.

Project management is clearly a role that requires the thoughtful application of a body of knowledge. One view of that body of knowledge is indeed documented in a generic (or industry-agnostic) form by the Project Management Institute (PMI), and is referred to as A Guide to the Project Management Body of Knowledge, or PMBOK (briefly described here).

That's a general framing of project management. When I observe project management more specifically in my world, here's what I observe:

• Project management goes on within larger organizational activities that are not primarily focused on project management in and of itself. In other words, project management is a means to an end.
• In my field, project management is not a formal job title or long-term career path.
• In my organization, project management is defined as an engineering competency (on par with, for example, interpersonal awareness).

When I think of project management as a competency rather than a career path, it fits better with my professional identity. I bring this competency (and others) to my job, and apply it (and others) to add business value. Or, to illustrate this in a way specific to my role:

 

Most readers could substitute my specific "content development" above with their own focus and the diagram would probably still work.

For my job, project management includes what you would expect: project initiation, schedule management, and risk management, among other focus areas. Where project management overlaps with general business skills (point "A" above) my focus includes staff recruiting, vending out discreet activities, budget management, and so on.

One could argue that cost management is a knowledge area of the PMBOK, and one would be correct. But my focus on budget management is tied not to specific projects, but to fiscal calendars that have no relationship to project timeframes. In other words, my budget is part of the ocean in which my projects swim.

Where project management and content development overlap (point "B" above), I take a sharper focus on issues like managing the scope of content deliverables (typically managed in topic count or word count, and various levels of editorial quality and accuracy) with constraining factors like resource capacity or fixed deadlines. Broadly speaking, I think of content development as the domain focus of my work, and technical content development for software applications, web services, etc. as the specific domain on which I focus my work.

Where it all comes together (point "C" above) is me at work on a good day (and C stands for Carl, how about that). To go back to my fish in the ocean analogy, if I'm now the fish, I'm swimming along doing my work and might not even consciously recognize the boundaries between project management, general business skills and the content development domain. I have some expertise in all three areas (and believe me it's an unequal distribution!) but I don't identify myself as being primarily any one of these things.

If you asked me what my profession was, I'd probably reply "technical communicator." This role has even less of a case for being regarded as a profession than project management does. (I'm no doubt sentimental about this because my time in a Technical Communication graduate program was highly formative, and I happened to meet my wife there.)  A long-term interest of mine is to do the type of exploration for technical communication as a profession as Paul Giammalvo has done for project management.

###

Risk Management, Oh My!

Risk management is, oddly, my favorite project management subject. In conversations with others I sometimes find myself drawing distinctions between subjects like adverse risk avoidance versus mitigation. Let's dig deeper.

First let me begin with the broad subject of risk management. I've written previously about the general subject of risk management (here), and specific tools in Microsoft Project you can apply with risk management in mind (here). As I said previously:

Risk management is a knowledge area of PMI's Project Management Body of Knowledge (PMBOK) and one of the most value-added areas of professional project management. I have found though that different industries and even different teams within the same organization can take widely divergent views of the value of risk management as a project manager's focus.

I think PMI's nine knowledge areas defined in the Guide to the Project Management Body of Knowledge (aka the PMBOK Guide), including project risk management, is an awesome model  and learning tool (you can get an introductory explanation of the PMBOK here, or order it here). Do the nine knowledge areas really describe project management as we experience it daily? Probably not, but like all great learning tools the knowledge areas give us a workable framework to help us make sense of a complex world.

I had a thoughtful discussion with a colleague recently about our organization's risk management maturity. As you may know I work in an area of Microsoft that focuses almost exclusively on "v.1" products and services. In the fairly high-risk world of software development, version 1 releases are especially risky endeavors. My colleague's point was that given the frequency of risky endeavors we were in, and the seemingly frequent crisis management interventions, we seemed not to be very mature risk management-wise.

On this point I disagreed with my colleague. I draw a distinction between risk avoidance as a general business strategy and risk management as a more granular tactic.  Certain industries such as energy and pharmaceuticals seem to be inherently risky endeavors--if you're in such an industry, you are going to face high-risk projects and activities. Other industries, such as commercial and civil construction, seem to be highly risk-averse by their nature. We don't normally allow buildings and structures like bridges to be built, for example, that don't have many years (if not decades or even centuries) of proven real-world stability.

I see the organization where my colleague and I  work as a naturally high-risk environment, so the question of avoiding risks (e.g. in our project selection) is not our main focus (at least not at my level). Given that we are in a high-risk environment, how we plan for and manage risk events that manifest themselves is a big focus though. In other words, if we're not going to avoid risky work up front, then we'd better be good at mitigating the risk impacts that confront us. 

###

Vacation Tasks: The Lazy Project Manager's Alternative to Resource Calendars

 

This week I introduce a simple way of accounting for people resources' time away from work. Project has some great features just for this need, but sometimes an even simpler approach is "good enough."

First, let's consider the "by the book" way of accounting for nonworking time per resource. The main feature for this is the resource calendar, defined as the working and nonworking days and times of an individual work resource. The calendar features in general in Project are powerful features. In previous posts I covered this subject here and here.

When I really need to account for individual resource's nonworking time and how it can affect the scheduling of tasks to which the resources are assigned, the resource calendar is my go-to feature. For some simpler projects, though, I use a simpler approach that gives resource nonworking time enough visibility to be managed. Strictly speaking this approach violates some key usage guidelines of Project, so buyer beware.

What I do is this: I create a summary task called something like "Resource time away from work." Below the summary task I then add subtasks for the known out-of-office times of resoruces who will have assignments in the plan. Here's what it looks like: 

TIP Click the screenshot image to see a larger view.

As you can see, this are really just tasks with the resources assigned with start dates and durations set to align with the resources' planned times away from work.

With this quick-and-dirty approach, I then filter the view to show tasks assigned to a specific resource. I can easily spot any cases where the resource has a task assignment that conflicts with their "vacation" task. Here for example is the Gantt Chart view filtered for Carole Poland:

No problem here with Carole's planned vacation. Jane Dow, however, does have a problem:

I can easily see in the Gantt Chart view that one day of Jane's planned vacation time (task 10) conflicts with one of her assignments (task 13). Now that I am aware of the issue I can remedy it, perhaps by delaying the start of task 13 by one day, or if it cannot be moved, discussing the issue with Jane.

Long-time Project users might now be asking what's the benefit of this approach instead of just using the resource calendar feature as it was intended to be used? I have found a couple of benefits:

• Anyone who has access to the plan can easily see (and if allowed, edit) the vacation task details. Getting to real resource calendar details is a bit more complex.
• The vacation task has no impact on other tasks in the plan. Contrast this with an edit to a resource calendar. In Jane's case with task 13, if I had set her January 16-18 time away from work in her resource calendar, then task 13 would have been automatically rescheduled to start on the next working day (unless prevented by a constraint). That's exactly what the feature should do. However, for a simpler project plan, I actually might prefer having a manual means of resolving such issues myself, and rescheduling the affected task might not be my first preference.

I mentioned above that this approach violates a key usage rule of Project. I'll explain myself now. The usage rule is this: generally, avoid creating tasks in a plan that describe something other than work to be completed. Clearly my vacation tasks violate this guideline. In fact, the vacation tasks represent the opposite: the expected absence of work for the named resource during the specified timespan. However there's no harm in breaking a rule if I know and can live with the consequences.

Some other consequences of this approach: If I'm using resource pay rates to calculate project costs, I may need to make some adjustments to account for any unpaid vacation time incurred by the vacation tasks. I also need to be careful with automatic leveling and my vacation tasks.

Overall though I find this approach to be perfectly adequate for simpler projects where I can eyeball the potential schedule conflicts between resources' time away from work and scheduled tasks. When I have more rigorous needs, I'll go to the resource calendars.

 

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.

Customizing resource calendars

• Project 2010 Step by Step: "Adjusting Working Time for Individual Resources," pg.63.

• Project 2007 Step by Step: "Adjusting Working Time for Individual Resources," pg.70.

###

Project 2010 SP1 Available, Recommended

The "service pack 1" (commonly called "SP1") release for Project 2010 is available now and I recommend installing it.

Long-term Windows and Office users are familiar with service pack releases. These are incrementally denoted as "SP1," "SP2" and so on. You can get Project 2010's SP1 release here.

As Microsoft says:

This service pack includes two main categories of fixes:

• Previously unreleased fixes that were made specifically for this service pack. In addition to general product fixes, these fixes include improvements in stability, performance, and in security.
• All the public updates that were released through June 2011, and all the cumulative updates that were released through April 2011.

Service packs normally contain bug fixes and performance enhancements, but generally don't introduce major new features. In my experience, I've never regretted installing a service pack for my apps or OS when it becomes available.

In the Project 2010 SP1, the major change to my eye is how Project Professional (sorry Project standard users) and SharePoint synchronize tasks for SharePoint task lists. The SP1 fixes what I had previously regarded as a big limitation to using Project and SharePoint for team-level collaboration without wading into the complexity of Project Server. We described the Project/SharePoint synchronization feature on page 391 of Project 2010 Step by Step. Here's how we described the feature:

You can store Project 2010 (Standard and Professional) data files in a Microsoft SharePoint 2010 document library. In addition, with Project Professional 2010 you can synchronize tasks between Project and a new type of list in SharePoint called a Project Tasks list. You can either create the initial task list in Project and then synchronize it to the list in SharePoint, or create the initial task list in SharePoint and then create a new project plan based on the task list.

In both cases, the tasks in SharePoint behave like manually scheduled tasks; you can enter a start date and deadline for the tasks, but no active scheduling occurs. When a SharePoint task list is then synchronized with Project, the resulting tasks in Project are manually scheduled tasks. In Project, you can convert them to automatic scheduling and perform whatever task scheduling activities you wish, such as linking tasks, changing durations, and so on.

The idea behind this feature is great--start a simple task lists and a Gantt Chart view in SharePoint, and invite team members to fill in details like task durations. This is classic bottom-up scheduling. Then, when the task list is relatively stable, synchronize the SharePoint list to Project and party on it as a project manager in Project. Or, take the reverse route: build an initial task list in Project, then share that with the team via SharePoint for broad visibility.

The issue I did not like in Project 2010 (and is addressed by the SP1) is this: whenever you synchronize tasks from Project to SharePoint, the tasks would be converted from automatically scheduled to manually scheduled tasks in Project.

Tip  Need an introduction to the new 2010 feature manually scheduled tasks? Click here.

Now I'll be honest about this--it's taken me a while to warm up to manually scheduled tasks. Until  I saw a demo delivered by Project guru Sam Huffman at a recent local Project User's Group meeting, I didn't fully see the value of this feature. Sam presented some compelling uses of manually scheduled tasks that I had not previously considered.

In any case, the SP1 update changes the task syncing behavior. Now, tasks that were previously automatically scheduled and synced with SharePoint remain automatically scheduled. I think this is a great fix because it preserves the Project user's intent. We're now in the process of getting the SP1 behavior updated in the next reprint of Project 2010 Step by Step.

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.

 Using manually scheduled tasks

Project 2010 Step by Step:  "Entering Durations," pg.30.

Project 2007 Step by Step: None! This is a new feature in Project 2010 (Professional and Standard).

Task synchronization with SharePoint

Project 2010 Step by Step: "Guided Tour: Synchronizing Task Lists Between Project and SharePoint (Project Professional only)," pg.391.

Project 2007 Step by Step: None! This is a new feature in Project 2010 (Professional only).

###