How in the world do you get MS Project to show you the calendar-day duration of a task when the "working calendar" of the project is a 5-day work week (or a two-shift, 5-day week; or a three-shift, 7-day week)?  It can't be that I have to calculate in my head from the projected start and end dates of a given task.

Amazingly, of the zillions of data elements in MS Project, there is no data column that gives you this information directly.  I asked around some colleagues and someone finally pointed that you can do calculations in some of the columns by using a Customized Field and adding a formula.  Unfortunately, you can't do a simple Excel-like calculation.  It's a function - but the basic idea is that you need to know the number of calendar days between the start and end of the task.  Simple, no?

Here are the steps to do this in MS Project 2007.

1. In the project Gantt Chart view, right click on the column headers and select the Insert Column option. 
   
2. In the dialog that appears, select Field Name "Number1," set the title to "Calendar Days," and pick your desired alignment, and click OK. This will insert a column with this name. 
   
3. Now we need to add the formula.  Right click on the header area again, and this time select Customize Fields.  A dialog box will appear for customization.  Select the radio button next to Formula under "Custom attributes."  (And then respond OK to the warning that the values will be reset in the column.)  Then click on the Formula button.
4. Add the formula below to the text area and click OK to close both dialogs.

   int(DateDiff("n",[Start],[Finish])/(24*60)+0.9)

   
5. Now tweak the display of the column to remind you that this is a field that you can't type into.  Once again, right click on the column header and pick Font.  I chose to display the text in italics and Gray color.  The result should look something like this.
   

Note: While CCPM generally eschews a focus on dates and hard durations and dates that this Tech Tip suggests, there are some types of activities which must fall along the lines of hard-and-fast durations.  A big example is interactions with government bodies who tell you exactly the durations of their review times.

Here's the piece that jumped out at me with just two small changes to apply to projects in general, rather than software specifically (highlight mine):

Whether the ... organization is [running projects] for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business.

There are always more good ideas than we have resources to execute those ideas. 

The most common response to a good (project) idea is to start working on it right away.  After all, the sooner you start, the sooner it will finish, right?  Sadly, this doesn't work very well.  Under this mode of behavior, you get the vicious cycle of more and more work being delayed more and more, as I described during the Project Flow 2009 conference. 

The rules that I mention there, apply here as well: evaluate the capacity of your project system, based on your constraint (the most heavily loaded resource), and release work into the system to keep your constraint active.  Along with this staggering, you have to acknowledge the stack of good ideas.  This is where the portfolio evaluation group comes to play.  Based on what can be known about a project idea, what is its potential value relative to all the other good ideas?  When resources are freed by the completion of one project, which project should be the next one to pop off the list? 

By the way, Dennis' article focuses on how Agile deals with this problem with a nice example of competing interests of the project team and the larger business.  In this case - and all cases - it is the business that needs to decide priority of the projects.

[Photo: "good idea lightboard" by techne]

There are a lot of interesting comments about industry and the market and the latest industrial revolution, but the big thing Luis picked up on and the thing that rang loudest for me was the comments about how people should live their lives in the new market.  Here are two:

"You can spend a lot of time getting your ducks in a row, but it's way more important to do something with the duck."

"You can do 50 things to 80% and you never get anything done." 

For me, these speak to the imperative to do something as well as the imperative to finish.  Finish it and move on.  So what if it fails or doesn't work perfectly.  You won't know that until you get to the end.  And you had better learn something from it - even if you don't know what that was going to be when you started.

It is not enough to just deploy the latest collaboration tools, whether that is Microsoft SharePoint; Office Communications Server; Google Apps; a corporate VoIP telephony system; mobile devices like the BlackBerry or iPhone; or the latest online collaboration tool reviewed on WebWorkerDaily. The challenge is getting people using them — and for that you need a collaborative corporate culture.

What are those elements of corporate culture that Will Kelly links to collaboration? 

1. Flexible schedules
2. No knowledge archipelagoes
3. Presence beyond the office (and regular office hours)
4. Technically savvy employees
5. Supportive management

Of these, it is clear to me that #5 is the most important, but I would go further and say that management (and leadership in general) need to model the behaviors desired in the organization.  As has been discussed recently, a key element in creating any culture is what does the leadership do?  Do the leaders demonstrate "collaborative" behaviors?  Do they expect people to work together to accomplish a task, and at the same time demonstrate this with their staff?

What about those other elements?  Number 1 and 2 are good evidence that collaboration might exist.  I'm not so sure about #3, particularly in the way it is described.  And I disagree with #4 - collaboration has been happening long before technology appeared on the scene.  What you need are employees who are willing to work together.  Granted, employees that are spread all over the planet need to connect with one another on the phone and other technologies.  But the behavior I would expect is that they are actively working together, not merely sending each other emails and then waiting for a response.  There is an element where the technology comes into play: if someone comes into the project and is uncomfortable with the technologies at play, then the group must work together to help them come up to speed. 

Actually, this (bringing someone new into the project) is a struggle in many respects.  They need to understand the technical details of the project, of course.  But they also need to come up to speed quickly with what has happened and what is expected to happen.  Having an ability to step back and review this together is another one of those important elements of being able to work together successfully (double loop learning anyone?).

Jim McGee pointed back to a /message article by Stowe Boyd from August, The War On Flow, 2009: Why Studies About Multitasking Are Missing The Point.  Stowe is referencing yet another study (that I happened to reference recently) on personal multitasking and the impact on the individual.

So, I maintain that studies like this continue to miss the point. If you use industrial era yardsticks based on personal productivity to try to figure out what is going on in our heads, here, in the web of flow, you will simply think we are defective. We'll have to learn how to measure the larger scope -- the first and second closure of our networks -- and distill from our media-based interactions how we influence and support each other. Get away from counting the calories, and get into how it all tastes.

I really like Stowe's perspective here.  People who are consuming multiple inputs aren't necessarily trying to get one specific thing done.  They are operating in the world, deal with it.  The discussion also reminded me of one of the anecdotes of the knowledge management world.  Is the woman sitting at her desk and staring out the window being "productive?"  All depends on your perspective, right?

The Critical Chain mailing list is discussing (again) this topic, and amongst the variety of topics was the comment that there are different types of multitasking that individuals find themselves doing.  A frustration about articles and discussions around multitasking don't clarify what they mean.

Task switching: switching from one active task to another without getting any of them done.  This is not switching because the first task hit a stopping point: it's switching for some other reason (like someone called for help on another task), and is generally considered ineffective because nothing gets to a stopping point or a hand off.  Nothing gets "done."  This is the stuff that project managers worry about the most (and that hamstring most organizations).  It looks like "progress" is made in many areas, but nothing ever gets done.

Backgrounding: doing one primary thing while some other things are going on in the background.  Listening to music and reading a book.  Listening to a podcast and perusing the news.  These generally use different parts of the brain and one can argue whether the primary task suffers or not.

And then there is what Stowe Boyd was discussing, it's not really either of these.  It's juggling: a bunch of activities that come together for a larger purpose.  He talks about doing many different things over time that keep him connected to the world in which he operates and gives him fodder for thoughts that might gel today or next week.  It's research.  Classic "knowledge worker" activity.  Self-directed and oriented towards goals that aren't so hard and fast.

[Photo: "Club Juggling" by GraphicReality.]

In the first five minutes or so of the interview, Ethan Yarbrough gives an excellent description of his "Ah hah!" moment of understanding the value of blogging in his organization.  The short form (paraphrased)

I was at a conference and preparing notes (on paper) to write up and send to some selected people when I got home.  What I discovered was people posting their notes live via their blogs and Twitter and getting immediate responses from their self-selected readers, rather than those specific people I think might be interested in the topic.

For Yarbrough, it is no longer a question of "is this a good idea," it's a question of how best to do this and make it happen well.  I really liked how he spoke about this and how it sounds like they are going about making it happen.  Allyis already had a fairly open culture, it was just a question of how best to help that culture grow to the 200+ employees they have.  This has me thinking about my colleagues in a company of fewer than 10 - plus our many clients and their own collaboration environments.

Here is Dan's description of the interview.  Go have a listen.

A brief 20 minute video interview on the journey that a mid-sized company, Allyis, has taken in moving from a 1.0 to mindset, and where the journey will be CONTINUING to go from here on out. For them, 2008 was the watershed year when many previous efforts clicked into place and sent their 2.0 efforts into high gear.

[Photo: "99/365 Realization" by Marcus McBride.]

Personal knowledge management (PKM) is something that we all do all the time, but often take for granted. I suppose, in that respect, it’s not unlike the other 2 KMs, Big KM and Little KM. There is always (has always been) some kind of KM going around, but until it was brought into the foreground as a distinct topic we did not approach it intentionally. Intentionally, at a gross level, PKM is about the tools that we use and strategies we employ that make it easier for us to identify, locate, and process knowledge.

Patti covers about five years worth of research and writing in her extensive summary, referencing many of the same people I would use as sources for this kind of discussion.  This should be excellent fodder for anyone attending next week's Boston KM Forum on Personal Knowledge Management - Professional Know-How.  Patti is going to be there, in case you need another motivation to attend.  Unfortunately, I am going to miss it (fun) business travel.

Here are the broad topics she touches on:

• Distinguish Skills from Tools
• Tool Selection is a Matter of Personal Preference
• People are not Born Knowing How to Use Tools
• Distinguish the Private from the Social
• The Leader’s Net Work and Personal Net Work

For me, the key to PKM is that I need to have good processes around my connections to people and information.  These processes are a big part of my "getting stuff done" work flow.  I have "trusted systems" (David Allen's phrase) that help me ensure I can get back to people or find stuff or meet my commitments.  And not only do I need to find my local stuff, I need good processes for reaching out to my network and discovering answers (or questions) that I don't necessarily have at my fingertips.  In my world, a big element of this is being willing to put myself out in front of people via my blog or Twitter and ask for help. 

A lot of PKM has to do with knowing what I know and where my knowledge stops and that of friends, family and the network can expand my own knowledge.

[Photo: "Hipster PDA and mini USB cable" by Teo.]

Abstract: To maximize the potential of Critical Chain (CC) to enrich project management practice, I discuss Eliyahu Goldratt's work in the context of his entrepreneurial career. I show that PERT/CPM had been an instance of Goldratt's "Theory of Constraints" (TOC) before Goldratt had articulated it. I also highlight errors and questionable recommendations he made. Nonetheless, CC provides a more holistic approach than the typical practice before. I (1) discuss CC and TOC, including strengths and weaknesses, in the relevant context; (2) provide earlier sources for the major so- called Goldratt innovations; (3) identify opportunities for immediate improvement and future research highlighted by Goldratt's work.

While the title and publication suggest it is about the TOC project management solution (Critical Chain Project Management - CCPM), Trietsch covers much of the basics of Theory of Constraints in his criticism before getting to the main points about CCPM.

This article points to research from the 1960's by Wiest on "the critical sequence" that also showed up in discussion the Critical Chain mailing list in the past few months.  Based on the discussion, Wiest's idea is the same as the Critical Chain as described in the TOC community.  But I am fairly sure it doesn't touch on the other elements of making TOC work, which are the management changes that are needed for a business to successfully change their operating mode.  What are those things?  Avoiding multitasking; buffers; and abolishing focus on task-level due dates.  All of these have elements discussed in the academic literature. 

While much of what is embedded in the CCPM world has been known academically, the simple problem is that most people do not practice project management according to these ideas.  Even at the larger scale of "constraints management" as discussed in the Operations Research community, I believe many of the principles are well understood but not applied in the business world.  This is the greatest frustration of all, no matter what you call it. 

The value I find in the Theory of Constraints community is that there are practitioners who are trying to apply these ideas both in their own businesses as well as with their customers.  That said, it's interesting to learn more of the academic underpinnings and to listen to the larger community of people who work in this area.  There are always things to learn in working with human beings.

From the tone of the article, it sounds as if Trietsch has had a long-standing complaint about Goldratt and TOC.  I've heard this in general in the TOC community: that the focus is much more on figuring out how to make the concepts work in practice than it is on rigorous proofs and thorough literature reviews.

* I am mostly a dyed-in-the-wool TOC promoter.

[Photo: "Stack of Dyed Wool" by Alistair Dunning.]

I have been a member of the Association of Computing Machinery (ACM) for a couple years, but I am letting the membership lapse as there is much less connection to my current work - though not my interests.  One of things I will miss is the monthly Communications of the ACM and things like Phillip G. Armour's "The business of software" column.  His Oct 2009 entry, Contagious craziness, spreading sanity, is no different.  (Sadly, full text only available by subscription.)

What he discusses is the nature of people in groups.  There are people (often leaders of some sort) whose behavior sets the tone for the whole group.  If no one questions "odd" behavior, then the group somehow develops a mental tick that makes the "odd" behavior acceptable.  Similarly, as soon as the behavior is questioned, then others in the group suddenly realize that they can push back on the behavior.  As I write this, I am reminded of the Abilene Paradox.

I loved Armour's take on Newton's first laws as applied to behavior: "Every behavior will continue until acted upon by another behavior." 

Armour also does a nice job of making this real with some examples and reality checks.  If you never say "no" to a pile driver of a boss / customer, then they will keep asking you for more. 

[Photo: "February 10th 2008 - This might be contagious" by Stephen Poff.]

This is a PhD thesis, so it's not like I would recommend or not this book to read.  But if you are interested in blogging and the connection to personal knowledge management, this is a good consolidation of the research in this area.  That said, I think it is more readable than my thesis.

What I do have are thoughts about personal connections to the ideas presented in the blog thesis.

I wonder what it would have been like to blog my PhD work in chemical engineering.  Granted, it wouldn't be quite so self-reflective as Lilia's work, but the opportunity to push out my thoughts, ideas and questions would be interesting.  That said, it was 1995 when I finished, and while I had a website, the idea of blogging wasn't anywhere near yet.  And, even today, there aren't a whole lot of chemical engineers in the blogosphere.

Lilia observes that her blogging frequency dropped off while other life events gained importance.  I've found the same.  But I am also fairly sure there is a larger effect going on.  I still subscribe to several hundred blogs, but now if I skip reading for a week there are a few hundred unread posts, according to Google Reader.  Three years ago, that would easily have been more than one thousand posts to read.  So, everyone has gotten into the same mode.  Many of my reading list have jumped into Twitter, where they post the simple, small snippets that might have ended up on their blogs in the past.  And I suppose Facebook and other social network services have drawn some of the blogging away.  (I certainly see less of the "what character are you?" or random personal surveys show up in blogs any longer.)

Along with this observation around frequency of posts is the clear change of blogging from part of my personal knowledge management practice to something where I keep in loose contact with my extended network of peers, friends, colleagues.  I find I do much less bouncing of ideas from other blogs into this one and then back out.  (With the exception of the previous post on the discussion between Luis Suarez and Andrew McAfee.)

Looking forward to continued reading.

[Photo: Cover art for Lilia's thesis, as posted to Flickr]

On one side, we have people like Luis Suarez promoting an admittedly radical approach of eliminating work email altogether.  His suggestion (hope?) is to replace with tools better suited to the type of collaboration, whether wikis, forums, social networks, etc.  On the other side, there are the realists, voiced by Andrew McAfee, who says (paraphrasing) "How can we expect busy professionals to invest their time in more environments for collaboration?"

I particularly liked Andrew's hypothesis about collaboration technologies:

McAfee’s hypothesis: Within organizations, collaboration technologies are dictated by the most powerful person involved in the collaboration.

If these people use something other than e-mail, so will everyone else.  If they don't, then all the experiments will eventually die off if the leaders ever need to be involved in the collaboration - they will choose their default platform (typically e-mail).  This makes a lot of sense to me.  Why else would every project along these lines include "management buy-in" as a key element for success.  And even closer, many of the social software discussions have described people who "get it" only once they actually try using the technology. 

I have attempted to fight this battle myself, encouraging and setting the example of using SharePoint to share files.  But the setup was far too clumsy and nearly everyone at the company laughed when you would say "it's in SharePoint."  Like that was going to do them any good.  Please email me a copy.

A thought on my part: Everyone gets dragged at least into e-mail.  McAfee uses the phrase that email, while not perfect, is usually considered "good enough" for most forms of collaboration.  What if there were a better center of gravity to begin with?  What if the leader decided that "good enough" was no longer acceptable?

Collaboration (working together) really can't be done in an asynchronous environment like email.  There has to be a shared space around which we work, whether that is the phone or a meeting room or a "collaboration space" of shared documents / conversations.  However, many of the technologies covered under the Web 2.0 / Enterprise 2.0 umbrella are about different modes of interaction.  I wonder if the discussion should be focused on interactions instead of collaboration.

Interestingly, right after Luis' post in my reader was an from Amy Gahran on why she really wants Google Wave.  Google Wave: I want it because I hate e-mail for doing things like "coordination (like setting meetings) or collaboration (like working together on projects) or tasks (like answering people’s questions) or ongoing conversations (like discussion groups)."

[Photo: "St Wenceslas Riding A Dead Horse (David Cerny) 02" by that_james]

In reviewing articles about folksonomies and taxonomies, I found that while there were some interesting experiments in combining the two, most writings repeated the same myths, folktales and misconceptions.

A fundamental flaw in the vast majority of articles on folksonomies and taxonomies is the almost universal use of the Dewey Decimal System (or Library of Congress Subject Headings) as the example taxonomy. Using the Dewey Decimal System as your example taxonomy shows that you have no understanding of taxonomy creation and use in today’s world.

It’s as if you did an analysis of boats and picked the Titanic as your example. It’s really big and cumbersome, and it’s made of brittle steel held together with bad rivets. It costs too much and is too difficult to build. It’s slow and hard to steer, runs into icebergs and kills lots of people.

Reamy covers many of the common myths promoted about folksonomies and taxonomies by the pro-folksonomy crowd, essentially suggesting that better taxonomy implementations can handle most of the standard complaints (such as the ubiquitous, "they are unchanging").  He also acknowledges some benefit of the folksonomy perspective: from his view you need the managed taxonomy, and the user-added element might be a nice addition.

Feel free to have a look yourself, if you are interested in the topic.

[Photo: "the assignment: describe the difference between a taxonomy and a folksonomy" by little green froggy.]

Think you can talk on the phone, send an instant message and read your e-mail all at once? Stanford researchers say even trying may impair your cognitive control.

In case it isn't obvious, this is multitasking in the form of walking and chewing gum at the same time.  Or in the high-tech world, reading and listening to your iPod and watching TV and .... 

The article describes the researchers as being puzzled: On one hand, all the literature says multitasking doesn't work, but on the other hand there are people all over doing exactly what appears to be multitasking.  My guess is that much of the "multitasking" isn't actually that.  Some of it is just alternate inputs.  Have you tried working in a coffee shop?  If you don't have your iPod rolling, then you are subject to conversations at the table next to you or the musical selections of the coffee shop staff - sometimes a worse distraction than what you have under your control.

The real question is, "What is the solution?" or maybe "Is this a real problem?"  Do you tell people they are more effective at studying / working when they don't have the distractions?  Do you give up and design activities to account for the multi-input nature of the world?  On a more important note: what about research that looks at the daily stream of interruptions people face and strategies for overcoming them - particularly in the context of an organization.

[Photo: The hilarious photo montage "9/365 - Multitasking Monday" by nheeton]

What Gladwell does is debunk the common myth of success: that an individual who works really hard and has talent can do anything they wish.  Sure, it requires talent and effort to succeed, but those aren't the only requirements: he shows that in abundance.  The examples of IQ were great:  Many studies have shown that there are IQ barriers to succeeding in college or graduate school, but beyond those barriers there are few academic differences that can be correlated to IQ.

So what is needed to succeed, beyond the base-level talent and interest in a given field?  Bill Gates would call it luck, Gladwell calls it good timing and a good situation.  Gates was born at just the right time (the early 1950's) to be there as the PC revolution was striking.  Gates' high school parents association bought the high school a CRT terminal in 1969!  Gates and the school were able to arrange CPU time at the local university and another company.  And then, here comes the effort part, Gates spent nearly every waking moment at his school's computer or at the university lab or at the local company.  When a job required someone who could do some programming, the guy who ran the computer lab thought of Gates (and Paul Allen).  Yowza!  Gates - and many other Outlier examples were all in the right place to take advantage of the great opportunity that came to them.  Some of those opportunities are by fortune of his family situation, but there are other opportunities that came to him by dint of his birth and location - something over which we have much less control.

The notion of opportunity is only half of the book.  The other element of success that Gladwell discusses is the notion of cultural legacy: how the cultural norms that surround a person affect how they interact with the world.  Some of those norms are very powerful aids to success.  Several examples have to do with the notion of hard work or industriousness: offspring of the New York, Jewish garment workers or offspring of cultures of rice farming -- two areas where the effort one puts into their field bears directly on their success.  Kids that come out of that mindset and move into other fields tend to have a higher tolerance for tedious work.  And that high ability often translates into success in many fields.  How else are you going to get 10,000 hours of practice?  Interestingly, some of those norms can be challenged and changed, but they have to be identified and addressed directly, and Gladwell discusses several examples along these lines too.

The biggest question I have upon reading this book is, how I can apply these idea in my life -- particularly in the life of my children.  I believe that they will "do well" in school, given both of our academic interests.  But how do we translate that innate talent into something that gives them what they need to succeed?  Gladwell doesn't offer an answer to that question.

[Photo: "Synoptic: Meteorological Data Visualization" by pushandplay]

One of the forgotten aspects of knowledge management relates to clarity.  Wikipedia defines clarity as referring “to one’s ability to clearly visualize an object or concept, as in thought, (and) understanding”.  Without providing clarity, can we have successful knowledge management?

This sounds similar to the idea of Context that I've written about in relation to knowledge management.  I've often thought that the goal behind knowledge management is to help the people in the organization build a better sense of context around their work.  And the way Brad is talking about clarity sounds like a similar view of the goals, though the perspective may be slight different.

An example.  I was watching Michael Clayton with my wife the other day, and there is a scene where someone asks George Clooney who amongst the law firm's 700 attorneys in an expert in a topic.  George knew off the top of his head.  Unfortunately, that expert was missing.  My wife thought it a funny KM problem.  But if the KM effort revolves around the one element of having experts and knowing who they are, there will be trouble.  The need to develop understanding of the topic is there beyond the fact of having some experts.  Even before I know that an expert exists, I need to have the means to learn about a topic enough that I can ask sensible questions.  This process can be iterative if the topic is of any complexity.

Embedded in this are education and training, business processes, business environment, and maybe some software.  So why is it that KM still focuses so heavily on the software end of things?

[Photo: "Claret" by Bert 2332]