Mapping the Whole Elephant

Make Project Meetings Collaborative with Discussions and Tasks

2011-12-22T16:46:00.000-08:00

Project meetings are a fact of life. But who has time to write up and email minutes after the call? Save time and make your team more accountable, self-directed, and productive with a few simple steps for collaboration in a teamsite.
NOTE: This post gives detailed instructions using Microsoft SharePoint and LiveMeeting, but the team process will work with any web-based collaboration and conferencing tools.

One-Time Setup

1. In your discussion board:

a. Create a view Minutes for Subject contains Minutes. This will filter any post with the word "Minutes" in the title, including "Minutes of Meeting" or Meeting Minutes" (since both are in common use).

b. Choose Actions>Alert Me to set an alert for each team member to send a daily summary of new items in the Minutes view.

c. Choose Settings>Create New Column and create a Lookup column called Related Tasks to the title field of the Discussion Board (multiple items). When the Scribe records or the Facilitator reviews minutes, you can select one or more action items as reference.

d. Choose Settings>Create New Column and create a Choice column called Status with values Open/Resolved/Closed. Use this to review prior minutes for open action items, and ensure all issues are resolved.

2. In your Task list:

a. Choose Settings>List Settings>Advanced and select Send e-mail when ownership is assigned.

b. Choose Actions>Alert Me to set an alert for the project manager to send a daily summary of all changes to the Task list.

c. Choose Settings>Create New Column and create a Lookup column called Related Discussions to the title field of the Discussion Board (multiple items). When team members record tasks, you can select one or more meeting minutes as reference.

Roles for Team Collaboration

1. Your team will need two designated roles for a meeting:

a. Facilitator, who will run the meeting (not always the project manager!)

b. Scribe, who will update the discussion board during the meeting to take notes for the meeting minutes. This should be a different person than the facilitator.

c. The scribe can rotate among the team, someone can volunteer, or the manager can appoint one, but both Facilitator and Scribe should be recognized roles.

2. Your team will also need a peer-to-peer process for Take an Action Item using tasks.

a. To take an action item, you create a task in the Task list and assign it to yourself as the owner.

b. To request an action item, any team member may create a task and assign it to any other team member (peer to peer). Project managers can model this behavior by inviting team members to assign you a task (and completing it promptly!).

c. To report on an action item, the owner updates the comments and either marks the task Completed, or assigns it to the next person who can take action.

d. Task ownership can change several times before completion. Team members are encouraged to share tasks by reassigning, or by updating a task they’re collaborating on, rather than creating a new task with each new owner.

During the Call

1. The Facilitator includes the teamsite URL in the meeting invite, along with the LiveMeeting URL.

2. All members log in to the teamsite (where they can contribute) as well as to the LiveMeeting.

3. The Facilitator reviews active tasks, new documents, and open issues, and other agenda items.

4. The Scribe opens a new discussion item and takes notes directly in the teamsite during the meeting. You can save a discussion item, reopen it, and add updates so team members will see minutes in real time.

5. The Facilitator asks the team to take action items, which the Scribe may note in the minutes.

6. During or immediately after the meeting, each member records their action items in the Tasks list and self-assigns them. Once the Scribe has created the Minutes discussion, it will appear in the Related Discussions column, and team members can link to the meeting minutes for reference.

7. As the team becomes more familiar with the teamsite, you may need the LiveMeeting less. For informal sessions, team members can collaborate directly in the teamsite while on the phone. For formal project meetings, it’s a good idea for the PM to use LiveMeeting to demonstrate the teamsite and use it hands-on during the call.

Catching the Rhythm

1. The first 2-3 weeks, the project manager can expect to take the lead as team members settle in to the project. One key to collaboration is the mindshift around tasks: from something the PM “gives” to something the team “takes.”

2. Change your language to change team mindset. During calls, kickstart your project with “I’ll take that action item” and replace “I’ll send you a link” with “I’ll post that to the teamsite.”

3. Publicly praise team members who show initiative as site contributors, and privately reassure those who may feel that they may do something wrong or “break” the site. Reinforce the message that the site belongs to the team as a collaboration space, and that all team members are peers who may contribute as equals.

4. At each meeting, review all open tasks and discussions on the teamsite, including the Created/Created By and Modified/Modified By fields. Set an expectation and a weekly cadence: before each weekly meeting, each task owner should modify (update or close) active tasks, and the Scribe/Facilitator should modify (reply, resolve, or close) any open discussions.

5. Within a month, your team will have a strong sense of accomplishment and confidence: visible task progress, meetings on the record, and everyone on the same page. And everyone should have noticed that the typical new-project flurry of emails has been replaced by orderly daily digests.

6. At this stage, the PM should take a checkpoint with Site Actions>Site Usage Summary to see if there are team members who are not yet using the site. Reach out to them by phone or face to face to resolve any technical issues. Including the teamsite URL in your signature can help with “I lost the link.”

Summary

Free your PM from meeting minutes, and your team from email storms, by using your team discussion board for meeting minutes and your task list as a peer-to-peer tracking system. Your team will be more accountable, gain self-confidence and trust in the team, and spend less time managing your inbox and more time getting work done.

The Blind Teams and the Enterprise

2011-06-10T12:45:00.000-07:00

With apologies to John Godfrey Saxe's ( 1816-1887) version of the famous Indian legend

It was six teams of Industry
To learning much inclined,
Who went to see the Enterprise
(Though all of them were blind),
That each by observation
Might satisfy his mind.

The First approach'd the Enterprise,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
"God bless me! but the Enterprise
Is very like a wall!"

The Second, feeling of the tusk,
Cried, -"Ho! what have we here
So very round and smooth and sharp?
To me 'tis mighty clear
This wonder of an Enterprise
Is very like a spear!"

The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
"I see," quoth he, "the Enterprise
Is very like a snake!"

The Fourth reached out his eager hand,
And felt about the knee.
"What most this wondrous beast is like
Is mighty plain," quoth he,
"'Tis clear enough the Enterprise
Is very like a tree!"

The Fifth, who chanced to touch the ear,
Said: "E'en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Enterprise
Is very like a fan!"

The Sixth no sooner had begun
About the beast to grope,
Then, seizing on the swinging tail
That fell within his scope,
"I see," quoth he, "the Enterprise
Is very like a rope!"

And so these teams of Industry
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
Yet all were in the wrong!

MORAL.
So oft in technologic wars,
Does every project team,
Rail on in utter ignorance
Of what each other mean,
And build and lead an Enterprise
Not one of them has seen!

Collaboration for Business Success

2011-06-10T09:21:00.000-07:00

2008-05-28T23:05:00.000-07:00

Lessons Learned

I'm about to embark on my third internal content management system (CMS) since 2001. Content management has come a long way since then, when our VP of Engineering hired a consultant to deploy the free SharePoint Team Services 1.0 as part of Windows XP, and hoped the group would use it. Within a month, the single document library looked like the front hall table where an entire dormitory had dumped their mail. That's how I became a SharePoint admin. Four years later, a systems integrator recruited me for my SharePoint experience as a full-time Process Manager for a large state project administered entirely (that was the goal) through SharePoint--again, free and out of the box. This time round, my current company will be using an open-source alternative, Confluence, and I'll be one of several Subject Matter Experts (SMEs) on the deployment team.

Most deployments start with a tool, and the technical questions about what the tool does and how to make it do what you need it to do. As SharePoint has emerged as a tool worthy of an acronym (MOSS, which is nicer to say than WSS), discussions seem to center on how to deploy, customize, enhance, extend, add-on, and otherwise engineer SharePoint as a software solution.

My own lessons learned focus less on these techie questions, which are satisfying because they have clean answers (even if they're not the answers you want). Our deployments were never intended to be customized, and the desired investment was zero money and near-zero IT time. Even when a third-party solution would have solved a business problem, as the BA admin I had no access to the SharePoint server itself, which was administered by our IT group in each case. When you're working with an "out-of-the-box" solution, you don't get to think out of the box. I got quite good at devising creative solutions "inside the box" that leveraged SharePoint to satisfy exceptionally demanding business users without touching the server or writing a single line of code. That, as they say, is another story.

The most important lesson I learned, and that I teach, is that building a library involves more than shelves and bookbinders. You need authors, readers, and--promises of search engines and collaboration systems to the contrary--you DO still need librarians. The part I play with would-be CMS engineers is to repeat, early and often: "Computers do not create content. People create content. Producers used to be called writers. Consumers used to be called readers. Librarians help writers and readers find each other." And, when faced with the intense and well-meaning frustration of a content producer at needing to get the words right: "Yes. If we all lived in your head, we'd be better off. But other people need to understand it too."

So, in recalling seven years on the front lines, here are some lessons learned. Each has a story behind it, and some vivid and/or bitter experience: but writing for the web needs to be concise and crisp. So, here you go.

About Users

Content Management Systems (CMS) and Knowledge Management (KM) are projects undertaken only when it hurts. The people it hurts the most are not necessarily the ones who will get the most use out of a well-designed CMS.
Do not forget to communicate to the end users of the CMS what problems the new system is designed to solve. If you are really proactive, you will ask them what problems they would like it to solve. These will be different than the pain points identified by those who started the project in the first place.
No one likes to make someone else's job easier at the expense of more work on their part.
Don't bother fixing what isn't broken. If your users are sharing content in a way that works for them, leverage and improve on that before telling them why they could be doing better.
Managers may want users to collaborate far more than users want to collaborate, or vice versa. These expectations are implicit requirements in a CMS, and may surface only when rollout does not meet expectations.
Collaboration and content ownership are both important, not the same, and can be, but are not necessarily, in conflict.
Content producers have obligations as content owners that may create limits and disincentives to true "collaboration."
Producers do not like to share content that "isn't finished." The CMS needs to provide tools that the producer will accept as alternatives to keeping drafts and notes on their personal hard drive.
Content producers are The Few power users and vocal stakeholders, while content consumers are The Many who often do not even consider themselves stakeholders.
The Few will insist on creating the CMS to serve their needs, which are usually far more complex and can be confusing to consumers.
Turning consumers into producers creates a higher signal-to-noise ratio that often backfires and creates resistance to the CMS.
"Collaboration" can and will expose differences of opinion, factual inconsistencies, power struggles, and unmade decisions. Consumers do not want to know all this. They want authoritative information--even when they disagree with it and then want to "collaborate" to change it.
Managers and team leads are generally more interested in sending than receiving.
The same person will behave differently as a consumer than as a producer.
Producers want consumers to pull, while consumers want producers to push.
Lots of producers will create overlapping, inconsistent, outdated content that needs a SME/KM to ratify. This person was once known as a writer.
Consumers want to know what The Answer is, Now. They don't want to do research and analysis, they'd rather ask a person (their de facto KM).
As long as it's faster to ask a person, consumers won't go to the CMS. Producers must leverage the CMS to provide answers.
Most content producers actively enjoy the sense of urgency and importance that comes from answering questions and knowing the answers. Promoting self-service knowledge transfer takes away that sense of personal fulfilment and is a disincentive for producers, even when they are overwhelmed with questions and acting as a bandwidth bottleneck.
As long as it's faster and more accurate to send an email or an IM than to do a search, users will ask questions before searching for answers.
Especially in software environments, many users have much stronger facility with spoken than with written English. This makes tacit verbal knowledge transfer (asking questions face to face) more attractive than explicit formal knowledge transfer (go look it up).
CMS is best for asynchronous communication and will never replace synchronous communication. Users will always need face-to-face, phone, email, and IM.
Users in search of answers often do not know how to frame the question. They may not know how to recognize the answer when they find it, especially if it's not the answer they are expecting.
Users like to browse. Users like to search. Some users are Browsers or Searchers by nature, but eventually all users will want and need both. Don't make them choose by designing your CMS to prefer one or the other. If you have a dedicated Browser or Searcher dominating your requirements team (especially if that person is a senior manager or tech lead), try to enlist users of different approaches and experience levels to balance the team.
Once you have invested all that time in producing written content, be gentle but firm with consumers who are overwhelmed at "I have to read all this?!" Be even firmer with producers who don't want to keep it up to date "because no one wants to read all this." They will usually short-circuit the CMS to share more current knowledge one-on-one. This will make your CMS fall even further into disrepair. Librarians must encourage, cajole, demonstrate, help, and insist that writers write, and that readers read.

About the KM Role

No one will call you a knowledge manager. You won't know you are one. How do you tell? Here's a useful metric: you are answering questions more often than you ask them.
It's a personal discipline to go to the CMS instead of answering from your own knowledge. Shooting from the hip reinforces tacit knowledge transfer and guarantees distrust in the CMS.
If your own knowledge is out of date and you discover this through a question, UPDATE THE CMS AT ONCE so the explicit knowledge is accurate.
Think of the CMS as your reuse repository for answering questions.
Seize the teachable moment. When someone comes to you with a question, show them how you find the answer in the CMS. Next time, walk them back to their cube and talk them through the search themselves. Invest your time in teaching your users to fish. Of course they would rather you serve them fresh fish and chips to order. This will not scale. (Pun intended.)
Keep track of all the questions you get asked in a given time period and how you answered them. This will make the ROI of KM very visible to your manager.
Find ways to add and update content daily, in small doses. Building a KM system is something that will always fall into the "when we get to it" category. It's your job to get to it, since you're the one who needs it the most.
Integrate email into your CMS!!!! If you can't pull AND push content via email, your system is doomed.
Users can and will insist on personal and customized, just-what-I-need-to-know content. Explaining that you cannot send each and every QA person a daily list of only the bugs they need to review is often fruitless and may result in your manager ordering you to do just that and work extra hours to do it. Invest your extra hours in building an automated system to do it for you.
Give your CMS a face. Be the Knowledge Manager and the Go-To Person. Then, and only then, send them links to answers as your first line of defense.
Remember that asking good questions is a learned skill. If it's easy for you, it's probably transparent and you wonder why others can't just go find the answer themselves. Notice what questions your users are NOT asking before they come to you.
Elicit expectations actively and up front. Pay careful attention to what The Few stakeholders expect, especially what they expect you to know without telling you. These are the most difficult expectations to manage, and you may have limited choice in mitigating risk.
You will never stamp out the process of emailing attachments, but you can damp it down by sending links instead.
If you are serious about cutting down on attachments, enlist your IT department to place a limit on mailbox size. This will make your users scream bloody murder. Let IT be the bad cop so that you can be the good cop by promoting links as an alternative.
Be polite but firm with people who email you documents to post for them on the CMS. You may have to provide that service, especially for your manager. If this practice is choking your inbox, reexamine your navigation structure and ask why it's hard for your users.
Do not expect your users to memorize your directory structure. If they ever do, they will not let you change it. Be gentle with people who post things in "the wrong place." Make sure your CMS can handle the manual routine filing that you will need to do behind the scenes.

The Elephant Being Mapped

2008-04-22T21:21:00.001-07:00

I tell this story so often in requirements management, it's a joy to see The Blind Men and the Elephant so (carto)graphically illustrated!

Source: greatmap.blogspot.com

Domain Modeling in Plain English

2008-04-10T09:26:00.000-07:00

The Whole Elephant's Theories of Everything: String Theory, Software Process, Knowledge Management and the UML

2007-01-17T22:07:00.000-08:00

For no particular reason, I've run across a driving idea in many disparate areas in the last few weeks, and find myself mulling over why this might be so. Why do people strive toward one single unified Theory of Everything?

String Theory

At home, I watched the NOVA PBS series The Elegant Universe by Brian Green, who "explains why string theory might hold the key to unifying the four forces of nature" in a "Theory of Everything." Now, I'm the first to admit that I'm no scientist, let alone a particle physicist. But I am, or at least have been, a social scientist and an educator of environmental science and history. And a cartographer, studying and creating visual representations of data. So I adored this series, that has both phenomenal visualizations of relativity and particle physics, and a narrator with the clarity and passion that makes for great history of science.

But I was left wondering why it was so important to have one theory. Just one. For everything. And why Everything went from the universe to the atom, but seemed to skip over the earth and its inhabitants, at the tangible scale where humans live daily lives. My first and favorite definition of geography, after all, was "the study of the earth as the home of human beings." As an educator, I adored Brian Green's vision, facility, and depth. As a visual modeler, I was blown away. As a humanist, I got a kick out of the skeptics who classed string theory as a philosophy (with the implication that it bordered on religion). As a social scientist, I felt left out. The elegant Everything of the string theorists, in short, is beautiful and satisfying: but it isn't my Everything. I feel a vague guilt about this, but the feeling persists. After all, the ancient Buddhist story tells us that enlightenment means seeing the whole elephant.

Software Process

At work, I experienced one of my periodic surges in requests for data, analytics, and daily advice from clients and consultants struggling to get their arms, heads, and workloads around a huge ($5M, 90-person, 2-3 year) project to build a web application for the MA Dept. of Public Health. Everyone desires a clean, current, and ordered master view: all the documents, all the defects, all the use cases, all the problem spaces, all the requirements, &c. They want and need to see the whole elephant. But then again, they don't. Each wants it all customized, data-cleaned, and reported on so they can see THEIR view of the elephant. Which is, of course, their truth.

They want the entire version history of a document: but they want the most current one, now, with a guarantee that no one has a newer one somewhere else. They want the Statement of Work: but only because they want to know the one contractual line item that will make a developer code something he's declined to code. They want the scope of all the bugs: but they want to see just the ones that are going to cost the most to fix, and the client's #1 top priorities, ranked in order. They want to know, for all workers and all documents: for three days of meetings, one session per hour (some concurrent), they want who must attend, which 2-3 documents they must review, what issues they must address, and what action items they must take. Only for their group. Just the trunk, the tail, the leg. But for them, it's their whole elephant.

Since I am the project's process manager, SharePoint admin, and project librarian, all this comes to me. I synchronize, I synthesize, I update and clean data, I strive for version control, I run gap analyses, I report, I estimate and forecast, I prepare agendas and minutes, and I do all this work (by and large) invisibly until someone wants its output. Now. In two sentences. Summarized. And while I've made significant strides in promoting and implementing self-service and best practices, as a "truth broker" I continue to meet with resistance to the curious idea that one person's truth may be different from another's. So, I'm a short-order cook, slicing elephant into single servings to order. Order up!

Knowledge Management

In my head, I model the elephant. To be pragmatic, I have to have a highly abstract mental model so I can respond to all these requests for The Truth without falling into the data pit with the rest of the team. More formally, the project has several explicit models for knowledge management: a use case model, a process model, and an information architecture. They were designed at the beginning of the project, then abandoned as artifacts. Day to day, my users don't learn those models: they come to me. I am--my work is--the model. Not in the sense of a role model, heaven knows, but in the practical sense of the Dewey Decimal System.

In order to know where everything is, I have to know not just where I put it, not just where person B might have put it, but where persons C-Z might think to look for it. And what's in it. And the kicker: whether the idea they're looking for really is in the thing they think it's in. That's meta-requirements gathering in spades. Why memorize the Dewey Decimal System when you can ask a librarian? They just Google me on IM or email. Obviously, to them I'm more effective than Google (!). I am the Oracle of their Theory of Everything. That's my job.

Yet drowning in data is nothing new. When I earned my master's in geography in 1987, the most famous aphorism of my advisor Yi-Fu Tuan was, in my paraphrase from memory, "The greatest fallacy of the modern age is the presumption that information (data) leads to knowledge, and that knowledge leads to wisdom." Twenty years later, we have personal computers, the Internet, Google, and the semantic web. Information management is a mainstream career. Knowledge management is a recognized discipline. What, then, might wisdom management be? I wonder if I might be doing it.

Modeling, Metamodeling, and the Unified Modeling Language

In my personal research, I surf the web looking for how other people solve these problems. Not always so that I'll find a solution I can apply (though I often do), but so as not to feel so alone, an atom of ideas in a vast universe of information. Sometimes, especially late at night, it's an intuitive, associative, gut-level search for that shock of recognition, the cosmic YES! to an elegant solution or problem expression.

I seem to be looking for a Theory of Everything that fits my experience. I wonder about the string theorists, here, and how and why their Theory of Everything fits them. I certainly share their gut-level pleasure in an elegant solution.

Some particularly fertile and provocative search results have come from the disparate keywords of web 2.0, maps, modeling and metamodeling, knowledge management, business intelligence, process whether agile or no, metadata, and the semantic web. This article frames a problem set to guide my exploration of these terms and their relationships to a Web Theory of Everything as seen from (or by) my elephant.

The Whole Elephant

The moral of the Blind Men and the Elephant says that seeing the whole elephant is a Good Thing.

"The Buddha compared this [quarrel] to the scholars and preachers holding various blind views, framed by their own ignorance, fighting among themselves, each one arguing that reality is such and such. All too often in history, revolutionary ideas and understandings by great thinkers have gone unacknowledged and even irrationally persecuted by those with different beliefs and values."

I certainly experience this in my daily work. But the moral seems a bit arrogant at times. Can all my coworkers be so unenlightened? Or perhaps could there just be lots of elephants?

Maybe, says my inner geographer, your view of the elephant is a matter of scale. Maybe the key to a Theory of Everything is to choose the right scale(s) for your given Everything. Imagine a Google Earth model of knowledge management that zooms seamlessly from the tail to the elephant to the herd. Now that would be a Model of Everything.

Hands-On del.icio.us

2007-01-06T22:08:00.000-08:00

http://del.icio.us/noelegance

Been using it about three months now and love the way I can organize bookmarks on the fly. I also love using the tag cloud as a cartogram of my collected interests.

Features I thirst for:

Batch delete bookmarks by tag set (del.icio.us will strip the tag without deleting the bookmark)
Batch share/hide by tag set (share or hide all within a found set)
Full Boolean search/filter within tag sets (today it will do AND but not OR or NOT)
Hierarchies of meaning within tags and bundles: today you get three levels of account, bundle, tag.
Visual management tools for drag-and-drop organizing of bookmarks, tags, and bundles. Imagine organizing your tags with FreeMind and having changes reflected directly in your bookmark set.
Visual and syntactical "relationship exploring" among tags, expandable to show the links in each tag set. Check out this extraordinary "audiomap" visualizer for music, TuneGlue. Now imagine a dynamic space where your tags show their relationships to each other by word stem (map, mapping, maps are all close together in a cloud) and by meaning (this cloud is near cartography and geography).
Word stem searching of tags, so that related terms show up in the same search.

Perhaps someone already does these things and I haven't found how. If you discover this blog, then post back and let me know!

Web Maps are Where It's At

2007-01-02T22:19:00.000-08:00

2006 has been the Year of the Web Map. As a geographer by training and a traveler by vocation, I'm inspired and delighted by the cool tools now available to put place back into the once place-free Internet.

I've been collecting some of the truly amazing tools, and the maps made with them, here:
http://del.icio.us/noelegance/maps+web2.0

Take a look at the Notes in each one for a mini-review.