Next Things Next

In the trenches with Traction Teampage

2011-07-02T15:54:00.001-07:00

In my last post, I mentioned starting a long planned Oracle go live. I also mentioned that I planned to use Traction Teampage's new capabilities to control the flow of information. I consider it an experiment in the use of a new technology, which is in focused on taming information overload. In this case, it is verbal information overload. I want to see my project's status in a way that does not consume my time in meetings.

My job as the project manager at this late stage in multi-year project is to make sure that we execute the plan. I must also focus on communicating status to all project's nervous stakeholders. Determining status on a virtual team is difficult at best. At worst, we hear the story wrong because we must listen to so many different versions. This usually takes place in raucous and demanding project status meetings. I’m always on the lookout for was to solve this problem using new tech tools.

I started using Traction Teampage to manage projects over two ago. Using a Wiki-based project management tool worked for the planning phase of the project, but did not work well during the execution phase. The go-live moves to fast for a Wiki-based tool. I had almost given up on a technology solution when I discovered a hybrid approach that addressed some of my needs.

My first attempt at using the new method was during a QAD (MFG Pro) go-live in China with a geographically dispersed project team. I could write a book my experiences. We did some remarkable things. Brian Tullis and I even presented the business case at various technology conferences. I took my new system with me to my next project; a QAD go-live in Newbury Park, California. It worked well there too. I was encouraged by the results and thought I had found a bullet proof method to use on all my large-scale projects. I was not prepared for failure, but I failed just the same.

The next large project to come along was an acquisition. I had several months to prepare for it, and I used Traction to its full potential in the months leading up to the actual purchase. I arrived at the new plant on the morning of day 1 with a small army of technicians. By 4:00 pm, I had given up on using Traction to monitor the go-live process. With fully 25 people participating, the information flow was staggering and difficult to monitor. Plus, creating static Wiki entries was too much to ask people who needed to do real work. I went back to my tried and true index cards and managed by the seat of my pants for almost 6 weeks. As my head cleared, I analyzed my failure and determined that static pages will not do in a stressful minute-by-minute environment. I needed a tool that team members could use that was simple. I started looking for another tool, but then realized I had the answer right in front of me. The new release of Traction had a more capable project management interface, including an updated status capability that works like Twitter or Yammer, but in a project framework.

I put it to the test Friday morning at 12:01 am. I held a kickoff meeting for the leadership of the Oracle upgrade project. We set the plan for starting the upgrade process and discussed communication strategy. Project hand-offs were to be explicitly communicated by email. Project work journals were to be handled by a Traction Teampage status update. My test had begun.

I finally went to bed at 1:30 am. I woke up Saturday morning at 7:15 am. I reached for my iPad so that I could check my email feed before even getting out of bed. I had subscribed to the feed for the project’s workspace the day before. My inbox was full of one-line status updates. It looked like a Twitter feed. I was happy to see that most of the volume came from Traction status reports. I read for 20 minutes before starting the morning status meeting. I had a basic understanding of everything of importance on the project before the meeting started; including all of the problems. More importantly, I knew we were behind schedule.

One of the reasons I use Traction Teampage for project management is that, if used properly, it dramatically reduces the need for project status meetings. I managed the China and Newbury Park’s QAD projects using two 30-minute long meetings per day. This freed team members to focus on working instead of wasting time in meetings. Unfortunately, the acquisition project required hours of meetings per day because the information flow was cumbersome, and my system had failed me. The good news is, for the Oracle upgrade, I am using two meetings per day. One in the morning, and one in the evening.

This is how the 30-minute meeting works.

(1) Start with a review of the open issues.

Team members use status updates to identify issues. We make one issue tracking article per day, which resides in the project management workspace. The title of each issue is listed, along with a link to the task. We create a task for each issue. We track these within the go-live milestone on the Oracle upgrade project. We briefly discuss each issue. The goal is to describe the issue and its impact, and then assign who does what and by when.

(2) A five minute update:

The next step is for the project process owner. the person who has responsibility for executing the next step in the project, to give a five-minute update on the project. This normalizes project status across the team and is essential for team continuity. It also gives the team a better understanding of their comments and work schedule.

(3) New issues:

We ask each team member about potential issues. All issues are welcome, including the minutia of the project. Each issue is described accurately. We assess the potential impact and assign the issue an owner. The owner is responsible for resolving the issue or developing a plan that supports the project timeline.

We record all three steps in Traction so that a wider audience can follow the project. The first step is a static article. The second step represents the latest status posts via Traction’s project management interface. The third step updates a static page with links to tasks from Traction’s project management interface. We tie each issue to the go-live milestone.

Since this is a first attempt at using the status update capability, I’ve had to push my team to use it. It is not mandatory, but it is strongly encouraged. So far, they are exceeding my expectations. I think this is because a status update is easy to do and takes no more effort than tweeting. Plus, the post has no overhead. Team members simply write about accomplishments. It only takes few seconds.

I see one area of improvement for Traction already. Status updates need to be available via a smart phone client like Twitter or Yammer. Getting to the internal Traction site via a smart phone is possible via a browser, but anybody who tries this will not want to do it again. It takes to long. Plus, having a client that can read the activity stream for status updates would be a powerful way for a mobile manager to keep up with the project.

I’ll post another update after we are live. It is only day two of the go-live process, and there are many potential pitfalls ahead of us. I’m more at ease on this project than I was on my last project. The constant flow of status updates feeds my information addiction. After all, one eats a meal one bite at a time; even when the meal lasts for four days.

Your journal is your life

2011-06-29T18:26:00.001-07:00

I am nearing completion on a large-scale ORACLE upgrade. The project goes live in just a few days. One of my last requests to the technical team was simple and low-tech. I asked that they each keep a journal that starts when we begin the four-day to live process and ends after the production system stabilizes. I had introduced this concept to a smaller subset of the team the day before. Based on their reactions, I figured a more detailed explanation was required.

During the stress of a time constrained go-live, people make many mistakes. Investigating a mistake during a go-live is stressful. When you add stepping backward through a process and getting the chronology right, the stress level shoots up even higher. A work journal is the tool for that. It captures the little things that might not make it into the online tools. Additionally, when it is time for a postmortem, having a journal to refer to is often the difference between guessing and knowing.

The requirements are simple:

Use a notebook dedicated to the project
Write down each step
Make sure to note problems
Capture details, like time, impact, scope, and the people who worked the problem
Start each day with a new page
Write with the awareness that somebody else will read your work

Use a notebook dedicated to the project – The reason I ask each person to start a new dedicated notebook is simple. I want the notebook for the post mortem. Consider it like a school writing assignment. The notebook is the written record of you involvement in a project at its simplest level. Having one enables problem solving and the identification of ineffective processes. If disaster strikes, these notebooks often hold the key to unraveling the mystery of a failure.

Write down each step – Many of our tools required that we document our steps as we take them. This rule is different. Consider it a sequential record of time spent working on a project, but not a detailed explanation. A typical entry looks like this:

6/29/2011 1:51 PM: Started working ticket 901120.
6/29/2011 2:11 PM: Completed ticket 901120. No problems encountered.
6/29/2011 2:12 PM: Took 20-minute break.

Make sure to note problems – This may seem obvious, but keeping notes when a problem occurs is not second nature. A problem is anything that does not occur as planned. In this case, a complex upgrade, each step in the upgrade process has a baseline time estimate. If a step in the upgrade was schedule to run at 40 minutes and took 60 instead, that is a PROBLEM; note it in the journal with details.

6/29/2011 1:58 PM – step 14a was scheduled to run at 40 minutes. Actual run time was 60 minutes. The job ran in conflict with another job (No. 34356) resulting in a slow process. I contacted Martin about the delay and reported the problem to the PM. The delay will affect the overall timeline. User tests scheduled for day 3 are rescheduled from 3:00pm to approximately 3:30 pm.

Capture details, like time, impact, scope, and the people who worked the problem – This point should be obvious after reading the previous item. If you have a problem, capture enough details to jog your memory. You will need to be able to speak to this incident in 4 to 10 days. If you don’t capture details, you will not be able to remember happened. If you cannot remember what happened, it will be difficult to solve the problems to its root cause.

Start each day with a new page – Let us call this one a personal preference. I had a problem on an important project last year. I collected the journals from each team member and set the appropriate page on a big work table. I read all events before and after the problem for each person on the team (seven in all). I eventually isolated the problem and was able to do a small course correction to get things back on track. It was much easier to do this when each day was represented as a single day.

Write with the awareness that somebody else will read your work – This small piece of advice is from the emotional intelligence section of my project management toolkit. If you write with the audience in mind, you are much less likely to assign blame to a problem. A notebook filled with accusations and finger pointing will engender mistrust and undermine teamwork. Keep your entries focused on process failures.

It is funny how things work out. While I was writing this post, we had a problem on an N4000 server we are testing. It failed. The system operator came into my office, and with my team present, attempted to step backward through time describing the major events leading up to the failure on the server. These included hardware changes, configuration changes, data restores, a hard restart, plus two contractors working on the server. All of this occurred in the last 5 days. We were unable to reconstruct the chain of events. Too much had happened in the previous week. It was a miniature disaster.

I reiterated the need for a project change log, but in this case as a crutch for an imperfect memory. With a daily schedule of hundreds of discrete tasks, remembering six items in the proper time and sequence is hard for anybody. When the number approaches 15, it becomes impossible. A simple change log would have prevented this minor mishap, or at least aided in its solution.

I’ve used personal project journals for 15 years on projects big and small. With the advent of collaboration tools like Traction TeamPage, it is possible to move a project journal online. I’ve found this helpful at times, but just as often it’s a frustrating experience for all involved. It largely depends on the comfort level of the team members. Putting your journal online is more time consuming than jotting a note in a notebook. Yet the whole team benefits from access to update-to-date information. I don’t force this issue, but I strongly encourage participation.

There is also the question of utility. How important is livebloging from project team members? It’s not important if there are no problems. It becomes important when something goes wrong. It becomes vital when the team is spread across the globe. In fact, once a project moves out of the bullpen, the need for quick access to project journals increases in direct proportion to number of times zones separating team members. The farther the team is dispersed, the greater the need for immediate access to good information.

The problem that we need to solve is finding an easy way to make small entries that can be gathered and viewed by project; something that replicates the two line entries mentioned above. Twitter comes to mind as a possible solution, so does Yammer. Both come with baggage in the form of outside scrutiny. Traction TeamPage offers something called “Status” updates. These are short entries, like a tweet, that are entered without the normal wiki article structure. It is still an article, so article building techniques can be used. For example, linking to named articles work; as do using tags. It is possible to view a feed by the people who you are following, or by an individual, or by a tag. You can also create a section (or custom search) that gathers status posts using a unique tag (or even a hashtag). This seems like a viable solution for moving a personal journal online. I’ll have to give it a try on my next go live.

Technorati Tags: Traction TeamPage,Tweets,Journals,Project Management

Picking Up The Trash

2011-04-22T09:28:00.001-07:00

In honor of Earth Day, I would like to share some things that I’ve learned about trash:

It looks better in a bin than on the ground.

If you find it on your own property or in your house, you’re extremely likely to pick it up and put it in its proper place.

If you see it in a public place, it is easy to say that “someone should do something about this”, and simply walk by and do nothing about it

The more natural or “green” a place is supposed to be, the more dismayed we feel about seeing it on the ground (or in a tree, the water…).

It is easy to do something about trash in public places, if you want to.

If you pick up one piece of trash and put it in a bin or a bag, you will actually make a visible, tangible difference. You will feel good about yourself.

It turns out that disordered environments promote stereotypes and discrimination. Then there’s all that evidence about how orderly, clean streets reduce crime, increase property values, etc.

But then there’s all that other evidence about the tragedy of the commons. Oh well. The commons can be quite a tragic place, I suppose.

My take is that the picking up the trash analogy can be applied to work and life in general. If you see something that should be done but no one is doing it…do it yourself. If you can’t do it yourself, try to get some help from your friends/colleagues/boss/leader to get it done.

This flows nicely into our usage of wikis and collaboration platforms at work, but it’s a holiday, so I won’t dwell on that now. Happy Earth Day, everyone!

What’s the Vis?

2011-04-06T09:20:00.001-07:00

I enjoy scuba diving. A common concern among divers is the visibility (clarity) of the water where they will be diving. Visibility is usually measured in feet or meters, not miles or kilometers. I will state the obvious and say that higher visibility is a good thing; 100ft is better than 5ft. Here's an excerpt from an article in Scuba Diving online (and the source of this post’s title) that talks about some of the factors affecting visibility:

A rule of thumb among marine biologists is that one liter of average clear seawater contains one million single-celled creatures called phytoplankton, another million single-celled protists, a billion bacteria and 10 billion viruses. And that's only the stuff that's alive. Add sand, silt, dust, salt ions and the detritus of those 11-odd billion creatures in every liter around you.

The article points out that even expert divers are terrible at measuring exactly how far they can see underwater. Let's just say that it's hard to define, but you know it when you see it. You might not be able to say with certainty whether it is 37 feet or 52 feet or 68 feet, but you can usually say whether or not it is good, or bad. When it's bad, it's not fun.

I went wreck diving in Lake Michigan in September 2010. I could not see my fins (please don't call them flippers) as I descended, a mere 6 feet from my eyeballs. I did not enjoy that. It did not motivate me to want to do it again. Here’s what it looked like on the surface:

What does scuba diving have to do with work?

Daniel Pink and others have written extensively on the subject of intrinsic motivation. One of the main intrinsic motivators is for people to see a purpose in their work. My point is that visibility allows us to make connections to our coworkers, companies, and society at large. It is through those connections that we can find and understand our purpose. That's much more effective than a boss or CEO just telling you - most people don't believe it anyway. This is what we've been going on and on about with all of our talk about Observable Work. It goes something like this:

Activities -> Visibility -> Connections -> Purpose -> Motivation -> Engagement -> High Performance

I know that most organizations do not exist to make people purposeful and motivated. Businesses exist to make money. But if we stipulate that motivated employees will help businesses make more money, well, shouldn't we as managers find innovative ways to motivate ourselves and our colleagues? And by the way, it's not all roses in our approach. There are downsides with observable work.

If you are someone with some control over how visible the activities are within your company or your team, I have some suggestions for you to try immediately:

Post your own personal performance objectives in a public place in your organization. If your employees know what your objectives are, they might get a clue on why you are asking them to do certain things. If they know what you are being held accountable for, they can help make you successful.
If you have a strategy or some sort of annual plan, post it in a public place. That plan should make explicit references to real, tangible efforts being worked on by your team.
When you ask your employees to do something for you, or start a project that involves them, take the time to tell them why. Give them context, discuss linked initiatives, relative priorities, and show them how they are fitting into the big picture.
The next time you create an electronic document at work (or intranet page...), link it to at least one other document or page, to enrich the context of the new piece of information.
The next time you set up a workspace / collaboration site / intranet portal area or even just a file share, give the entire company access to read it. If you can't justify giving the entire company read access, just try for 2x the original number of intended readers - and then let them know that they have access to it.
Explicitly encourage and reward collaborative, visible work.

There are some obvious factors that go into your ability to implement some of these recommendations:

What does your overall company culture think about transparency?
Do incentives exist not to make your work visible, not to share?
How distributed is your own work team - as tools and technology likely have a larger role in distributed organizations.
Do you have "enemies" at work - of your department, of specific projects that you manage?

All of the above and more will impact your journey along the observable work path.

Back to the diving analogy. How would you rate the visibility, or as divers say, the "vis", where you work? Good, or bad? How would you measure it?

I find myself thinking, "What's the vis?", all of the time at work. Whether it is leading my own organization, participating on a project, or participating in some larger corporate initiative. If the vis is terrible, like it was when diving in Lake Michigan, I am not engaged.

Now at work, it's not salt ions, silt and phytoplankton that impede visibility as they do in the ocean. But many of the impediments to good visibility at work are within our control, and through a series of small actions, we can make a difference.

What do you think? Does this make sense? Thanks for your time.

Social Software For Business Performance – Some Perspective

2011-03-07T06:31:00.000-08:00

We participated in the Deloitte Center for the Edge Study, “Social Software For Business Performance: The missing link in social software: Measurable business performance improvements”.

Here’s a direct link to the PDF of the study.

The intent of this post is to give you some context and explanation of the performance improvements. I will attempt to convince you that social software really can be a key enabler to business performance. From page 4 of the PDF version of the study, we claim a 61% reduction in time spent on compliance activities through the use of Traction software.

What do we mean by compliance activities ?

For many, the word compliance means something like, doing what someone else told me that I have to do. For us, it is a bit more than that. It means having a governance framework, codified in policies and procedures, formalized in contracts with our internal customers, and tested regularly to ensure that we are meeting the expectations of the framework. Make sense?

How about...Have standards. Follow them. Improve them. Prove that you are following and improving them. Repeat.

Our internal framework also covers relevant external regulations such as Sarbanes Oxley Section 404. If you work for a public company, you know what I am talking about. In more detail, we:

have an IT governance framework - like ITIL (ours is proprietary) - that sets standards and expectations about how an internal IT organization should be managed and how it should deliver services to users (aka internal customers).
write policies / procedures / documentation to translate those standards into practice; we are supposed to continuously improve and update procedures as practices change.
establish contracts with internal customers that engage the IT department to meet certain service levels, uptime, and project delivery obligations.
work. We modify software, deliver projects, deliver support to end users. Where possible we work through the same platform where the procedures, agreements, and other documentation are stored.
test the fact that the work is being done in accordance with our procedures. For example, does our software change management practice match our procedures? If we are doing it right, we can easily document and observe via references and hyperlinks that agreement / procedure / work product are in sync.

By consolidating this work in an enterprise social software platform, we eliminated 61% of the work required to maintain documentation, do tests, and inefficient waste time spent searching for information across 7 locations. 61% equates to almost two full time resources.

We tried previously to do this consolidation through other tools, to no avail. Why were we successful with Traction? There's something about Traction and social tools like it that enable outcomes that were never before possible. If you read the study, you learn that we experimented with applications of the tool until we found some that worked in solving a real business problem.

We can spend that productivity gain on project work, software changes, user support, and all of those other customer-facing things that our colleagues expect us to do as an IT organization. Individual IT teams that have not consolidated all of their work into our central group are applying these patterns and using the same tools.

Our case study also mentioned project management, but due to time constraints we didn't have the time to fully document those benefits in the case study. You can explore our presentations from E20 Santa Clara 2010 and Catalyst San Diego 2010 for more on that use case.

What's the big deal about all of this happening in social software?

A native hypertext platform is a huge enabler. You can upload Word documents to Sharepoint and link them to each other for sure, but it's just not the right tool for the job. But we're not here to bash MS Office in this post. What I will stress is that this is not about blogs and wikis and activity streams and all of that other stuff. It is about leveraging the the original intent of the web, and applying it to work.

Policies and procedures, to be valuable, must continuously changed to reflect real world conditions. They were not frequently updated when inside of our old "controlled document" repositories. Improvements in the real world can be captured real time in the wiki so that they can be repeated by others governed by the same procedure. Open browser. Visit article. Click edit. Edit. Save. History is tracked. Revert to an older version if needed. Repeat.

When we first started, only managers could update documentation. Now everyone in the department can - going from 7 editors to over 70. Do certain people own content? Yes. Does everyone else actually modify everyone else's stuff? Not so much. But they can, and it happens. It's part of our community of trust (see speaker notes for text) observable work pattern. We strive to make updates in real time, making the procedure capture what you do, with no unnecessary management overhead to approve changes. Here’s a typical article in our IS Manual wiki – shown is the edit history of a month-end processing procedure at one of our largest locations:

Note that this is not something we update once per year…it is more like once per month. In our wiki, content is alive. If you work with policies and procedures, I challenge you to leave a comment to this post and tell me how often your procedures are updated. Do they reflect current reality, are they even used? Do you have uncontrolled annotated paper copies roaming the hallways?

But they do not update themselves, these wikis! A wiki that is never updated is just as useless as every static intranet or controlled document repository ever implemented.

A comment is an electronic signature. This is a key insight that has saved us many, many unnecessary rounds of email and paper-signing rituals. It allowed us to bypass more rigid workflow / document management applications. We do authentication through our corporate Active Directory infrastructure. This is already used as an e-signature on several other internal processes and workflows in more transaction-oriented systems. So we figured, let's try it.

We have agreements with our end users regarding the services we provide and the systems we manage. We document approval by sending a link (by email, the horror), and the customer visits the wiki page and enters a comment that says, "I approve". So among all of the things that you expect to do within social software - long threaded discussions, collaboration, and all of that, why not use it as a lightweight contract management solution as well?

Working in the same platform as our procedures and documentation allows for some interesting things to happen, again, leveraging core hypertext / linking services. For example, we are doing a major system modification project, and one deliverable is to update the documentation for that system. We can associate a task from that project to the procedure in our documentation wiki. Depending on the context, I see that something needs to be done to that procedure.

In the project context, I see a task pointing me to the procedure and calling for action.
In the procedure context, I see a task on the procedure, referencing the project.
In the user profile context, the assignee will see the task assigned to her, pointing both to the procedure itself and the project that generated the task.
It’s the same content, the same base URL, referenced in 3 different spaces but all linked together.

I was told that our approach wouldn’t work in some highly regulated industries like nuclear power generation; but most of us don’t have to worry about that. It took us over a year to figure out an approach, and it is not perfect. Implemented properly, I believe that there’s a place for social software in your business processes, too.

Everything Is A Project, Part 2

2011-01-24T06:00:00.000-08:00

This is my first post of 2011. Up to now I have been focused on planning and strategy, heads down in my work, just trying to wrap my head around our current priorities.

I would like to share some of the recent experiences and activities of my team and talk about how we are evolving our management processes this year.

In 2010 I wrote a post called Everything Is A Project. During 2009-2010 we had what we felt was a lightweight approach enabled by the use of the Traction TeamPage 4.2 product. It worked well, but we always felt that using a wiki/blog platform as a project management tool was a little clumsy. While not ideal, we were still able to scale up that approach to support 3 ERP implementations and other major internal IT processes, with great results.

Traction’s latest version 5.1 has a lightweight but scalable capability to manage projects, milestones, and tasks. This functionality is baked into the collaborative DNA of the system, opening some extremely interesting possibilities for us. Bill Ives wrote a comprehensive review of TeamPage 5.1, and I encourage you to read it for more background. The remainder of this post will give you a practitioner’s perspective on how we are using the “everything is a project” theme in our approach to IT management.

My example is based on our 2011 strategy development process. This is not a classic project per se. It is not a product launch, software implementation, or a major new business initiative. It is just the type of thing that all of us do, every day, but have inadequate tools with which to execute it. We tend not to want to "project-ize" these initiatives because the overhead is too high and most project management software is too cumbersome. And yet, this is what the lion's share of our work is these days. These are all of those complex, barely repeatable processes that defy structure and modeling in traditional software tools.

Below is an excerpt of our 2011 Strategy Process article. Highlighted are links to the milestones for this effort, as well as the wiki page in the same workspace that will contain the content for the 2011 strategy.

Here is a partial list of milestones. The numbers 0/10 for Europe show that there are 10 tasks, of which 0 are complete. Better get to work…

Some of the discrete tasks on the Europe 2011 Strategies milestone, with names erased to protect the innocent:

No big deal, you say? It is a big deal to me because these and other tasks flow through to the assignee’s profile page. It’s also a big deal because the actual content of the strategy lives in the same platform, referenced explicitly by the tasks required to produce the deliverables. Concretely, then, on our strategy article I can see inbound hyperlinks (very cool) from other content (projects, tasks, milestones) that references our strategy. The arrow points to the project mentioned above:

This helps us to align objectives across more than 20 operating units. I’m fighting the urge to go off on an Observable Work rant here…

By the way, all of those tasks are just like blog entries that can be commented on, and we can collaborate on these strategy deliverables through this action management process. It is an extremely powerful feature set that is going to make us more effective.

What I demonstrated here just scratches the surface of where we are going. I have one group internally that is using this capability to manage post go-live support activities for a CRM implementation (I’m trying to encourage a guest post there…you know who you are…). Joe is on fire implementing this approach on our “real” projects, and task assignments are multiplying like rabbits. Our main insight so far is that we can apply this lightweight action management pattern to initiatives large and small. It allows but does not require layers of complexity. For example, one project might have 10 tasks all assigned to the same person but no milestones, while another might have 50 tasks assigned to 12 different people and be broken into 10 milestones.

None of this is without its problems, but we are moving forward with deliberate speed. We have a lot yet to figure out, and we like to learn by doing.

Check back here for some more of our experiences. Thanks for your time and may you have a productive and rewarding 2011.

Naming everything

2010-12-01T05:30:00.000-08:00

I’ve always enjoyed encyclopedias. As a child I found them indispensable for explaining the world around me. The wonder I experienced as a youth when discovering new information was only surpassed by the sense of accomplishment I felt when learning by doing. I have the same sense of wonder as an adult regarding project management, although at this stage in my life, I am less inclined to learn by doing and more inclined to teach what I know.

Thinking about making an encyclopedia of project management knowledge for my work led me to a major epiphany a couple of years ago. I was on vacation at Yosemite National Park. While standing at the overlook on top of Glacier Point and looking down at Yosemite Valley, I noticed a plaque showing the major landmarks. It had landmark names etched in bronze. I located Half Dome on the map in seconds. It occurred to me that some park ranger had grown tired of answering the question, “Is that Half Dome?” So he created the equivalent of a wiki post, but etched in bronze. Each year, thousands of visitors use the Glacier Point wiki without realizing it. I quickly realized that I could create the same valuable information on our project wiki by naming everything of interest to a vistor. A visitor could find the information they were looking for by reading a series of linked posts. In effect, I would create a visitor’s map to our project community. Visitors who are interested in the duties and responsibilities of our Financial Business Analyst need only to browse a few key pages to find the information they seek. I started naming everything, although I started with something easy.

We started with people. The expectation was that any time a person’s name was used in an article, it would hyperlink to a page featuring information about that person, but in the context of a project. This is not a profile page. It is project specific content focused on helping an outsider understand what a person does on each of the different projects we have open. We call these pages Project Resource Pages. Each page shows a picture of the person, gives a brief description of their job, describes who they work for, who they work with, and who works for them. After the generic descriptive information, we add sections that display related information flows (activity streams) of their project work. These are articles, comments, and tasks owed to other projects. In just a few seconds, a visitor can gain insight into how a person is contributing to the collaborative project management experience. The visitor is often me. I find these views invaluable when conducting 1:1 meetings.

We soon learned that what is good for project resources is also good for anyone participating on the project, so we added lots more people. We started with the staff of each facility, and then we added their teams. With this advancement, I could brief in a new project team member in a few hours. We did not stop with people, we added maps, directions, recommendations for hotels, lists of all computers and printers, pages for each piece of software in use, and pages describing business processes. In short, we created wiki pages for anything that would come up while working a project. New team members need only spend a few hours on the wiki to learn the “who, what, and when” story associated with a project. We reduced the need to answer questions about the project. Each time we bring on a new team member, we realize the benefit because there are no orientation meetings. It’s takes 10 minutes to point them toward the wiki, and away they go. Work gets done.

There are hidden benefits too. New members of a project team are often given the job of describing a process as a way to teach them about our project wiki. For example, a new team member was asked to describe every report that runs in batch mode on our old HP3000. We asked the he provide the report’s code and a sample of the report’s output. This task alone would be enough to keep him busy for a few weeks, but we also asked him to meet with the users and identify the report’s business purpose and its primary owner. In fact, we encouraged him to have the users collaborate on each post, editing as necessary and posting additional content where possible. After completing the project, we will gain a valuable information resource which will serve as part of a larger project next year. We also gain a seasoned content creator who understands how to structure meaningful project information and connect with users. I call that a win, especially considering that he was afraid to use the tool.

One of the unanticipated benefits of naming things is that we now have tools for monitoring parts of the project that we never thought to manage before. For example, we have a page named “CERT”, which describes software created in-house. It’s used to make product certifications. Now that is has its own page with sections summarizing its activity stream, we can keep up-to-date on its operation by monitoring it. Plus. we can see how others are using it and adjust our planning based on news from the activity stream. Seeing how other people interact with the software translates into less time lost to unforeseen circumstances. It reduces the, “you don’t know, what you don’t know problem in project management.

In our quest to name everything we’ve discovered a few problems. The most notable problem is change. People come and go. Our wiki is old enough to hold several generations of project teams. I was just looking at a picture of a team from three years ago. Not a single member of the team is still working for us. Everyone has moved on. Besides the coming and goings of team members, people change jobs. Maintaining the information is every bit as important as creating it and you must plan for it or it will not happen. We’ve opted for a refresh at the start of every new project. It’s working so far, but I foresee problems with this as the number of articles grows. Right now we are at about 10,000 articles in our project workspace alone.

Another problem was less obvious. When we started down the path of naming everything, we tended to work within projects. We soon found that there were multiple copies of named things. We realized that we had to remove the duplicate entries and make the original entries project neutral. In other words, we need the information to be generic enough to cross multiple projects without hurting its value to a specific project. This is no small task and requires constant attention. A set of guidelines would have helped, but we did not foresee the problem.

Our successes are important too. We find that naming things helps reduce the need for meetings, emails, and training time. Plus, we want the casual user to move through the information and find meaningful content without the need to search for it, or worse, ask the PM. For example, lets say a user lands on the John Smith resource page and sees that John is working on three projects. The visitor would follow hyperlinks to each project’s home page and find a wealth of information in the form of articles each with hyperlinks to hundreds of named resources pages. If they get to a project homepage, the chances are pretty small that they will aks a PM for more information. Users, customers, managers, and project team members should be able to find important information without bothering the project manager. The PM needs to work on strategy and recovery planning. Of course, if he’s a smart park ranger he builds a useful wiki along the way.

Technorati Tags: Wiki,Project Management,Observable Work

Sensemaking For My Team, My Customers, and Me

2010-11-30T06:00:00.000-08:00

One reason why I blog is that it helps me to make sense of the world. For those of you that have everything figured out, I am envious. I do not. As to what sensemaking is, head on over to Wikipedia for citations and further research.

It is not an approach that I thought was relevant to work. Too touchy-feely. However, Joe’s recent post on Narrating Your Work inspired me to describe a recently implemented practice of targeted, strategic communications. It is blogging in a management reporting context, and shared with my core IT team as a means to help develop their leadership skills. In describing what I do, I will touch on themes of one on one communications, feedback, writing skills, and professional development.

To set the context, I have at most 30 minutes per month at our senior staff meeting to communicate on Information Technology projects and strategy. My normal approach had been to cram as much as I could into 10-15 PowerPoint slides, lay out the 3 or 4 major decisions that need input, and then thank everyone for their time.

This single PowerPoint deck was the only regular strategic “artifact” that I was sure that everyone would see (captive audience...). For those of you in management, or who must suffer through staff meetings, a question. On a scale of 1-10, how would you rate the value/relevance/quality of presentations at your company? How about the IT presentation? I thought so. It is clear to me that a pure focus on quantitative analysis enclosed in a PowerPoint deck just doesn’t cut it. It is not really helpful to anyone. And yet, we keep doing it to ourselves.

In August 2010 a trusted colleague (someone who reports to me, actually) gave me feedback that my monthly PowerPoint dog and pony show at the senior staff meeting was boring, ineffective, and mostly irrelevant to my peers and customers. Actually, he didn’t use those words exactly, but that’s what he meant.

The process of one on ones and feedback are critical to good management, and they are rare. Rarest of all is real feedback given from employee to manager. When I get this feedback, I try to take it to heart. For more on the whole process of feedback, one on ones, and good management in general, I strongly recommend Manager Tools.

After some deep thinking and brainstorming with my team, we came up with the idea that I need to make targeted communications to key peers and internal customers. These are department heads, as well as factory managers and general managers. My approach is simple. During the first week of each month, I write a personalized update. Each update should about one page, a little more if graphics are required. We work on many projects, so one common approach is to discuss same project from multiple perspectives, depending on my audience:

Finance leadership wants to know about costs/expenditures, and perhaps issues like how a new ERP system will affect our product costing methodologies.
The project sponsor needs a general overview and an update on any blocking issues.
Sales leadership may only care about how a new system will impact our ability to implement a new pricing strategy.

What this means in practice is that I have a lot of writing to do. For October, I wrote 11 strategic updates. It takes about 8-10hrs over the course of 3 business days to do the writing. Total word count is approximately 5,900 and that comes to about 18 pages in an MS Word document with all of the images/tables included.

Again, a lot of content is the same but it’s written from slightly different points of view depending on the target. While I wish that I could write one 500 word update for everyone, or do just one single PowerPoint presentation, that style didn’t work. So I changed, based on feedback. And it was the right move.

One huge benefit for me is starting to see the work of my group from the point of view of our colleagues outside of IT. It’s one way that I am becoming more customer-centric. Writing for someone forces the writer to think about the perspective of the reader. The feedback so far is mostly positive. Someone asked me if I had taken some high powered leadership training class or something. Not quite. But I know that my colleagues read these messages because I get follow-up questions from everyone that gets a message from me. And hey, it’s email everyone. I’m sorry, but that’s how they get distributed. And at the staff meetings, we spend time on strategy, and sidebar conversations are all about followups on the updates sent earlier in the month. It has been effective.

Here is where the professional development and blogging aspects enter the picture. One of my individual development plan goals for 2011 is to become a more effective communicator through developing closer relationships with my peers. Next, it is important for me that I do my work in a way that is observable to my team so that they learn the job of an IT Director as well as see strategic IT priorities from the perspective of our senior leadership team.

My targeted updates and associated follow-ups help to accomplish my development plan goal. I develop my team by consolidating all updates and posting them as a blog entry to our management workspace. This private workspace allows my team to get exposure to my job responsibilities, professional relationships, strategic commitments…and by extension they can better align their respective organizations’ activities with the overall strategy of the company. While I go offline to do these communications, I put it online for my “community of trust” and link it into our workflow.

In closing, if you are in an internal service organization (like IT), you really need to consider making targeted strategic updates to your peer leaders and major internal customers. You need to tell them in your own words what you are doing for them, and by when. It helps you to make sense of your own world, and helps them answer the “what’s in it for me?” question. I learned the hard way that 30 minutes of PowerPoint per month isn’t helpful at best, and harmful at worst. Use email if you must (I do), but if you can share that communications process with your core team, it can be great professional development opportunity.

Narrating your work

2010-11-22T06:00:00.000-08:00

I spoke the phrase “Narrating your work” at the Enterprise 2.0 Conference. I had not planned on saying it. I had not even thought of using it to describe an Observable Work concept. It simply felt right. What we ask people to do is tell the story of their work day as it relates to the projects they work on. Specifically, we ask people to write a journal entry describing the key events, risk items, accomplishments, struggles and frustrations. We want the story before the book is done. I want to emphasize that I am talking about storytelling as "sense making" in our context. Scorecards and checklists and calendars are necessary but hardly sufficient to properly make sense of the "truth" in complex projects.

What happens in the real world is that we hear the story after the fact. Or, more commonly, we hear an excuse after a small miss. For example, let’s say a deadline has passed and an important technical deliverable did not happen. We ask questions to get at a version of the truth. The Project Manager’s inquisition is designed to elicit information so that they can understand the story behind the miss, recover, and prevent future misses. The process is often painful and influenced by personal perspective. In other words, we never get the real story. Anyone who has done this knows the whole thing is a waste of time. We could prevent the miss if we had a chance at predicting it. But that means endless status meetings, which are a waste of even more time.

Narrating your work asks for the story a chapter at a time. Think of it like an old serialized novel. Each week (or day), another piece of the story is revealed to expectant readers. In this case, the expectant reader is the project manager or a member of the management team. Instead of waiting to find out if a significant future event will happen, the PM may be able to predict the outcome through monitoring the information streams created by members of the project team. It’s nice to have project leads posting a journal entry, it is better to have the whole team engaged and posting - at least it is in theory, we are not quite there yet. It's blogging, but we don't call it that. And it can be done so that it is fully integrated into the flow of work

I give simple instructions when I ask people to start a daily journal. Here is an example:

Hi Sarah

I want you to start using a new technique on this project. Well, it’s not new; I used it on another project with some success. Since you are Project Manager for this high profile effort, I want you to post a daily journal entry. It should contain a description of the previous day’s events, describe risk, and note new action items. The process took me about 15 minutes. I found the best way to do it was to create a post each morning and add to it throughout the day. I’ve got Derrick doing this for the upgrade project and I will ask Simon to do it on his projects too. Think of it as a way of communicating status without the need to sit in meetings or make phone calls. I need you to do this so that I can follow what is going on without interfering with your daily flow… Think of your audience as your team, your customers, and management.

Joe

Some people read my instructions and catch on quickly, others take coaching. What I request is a collaborative dialog about a project; I don’t want to see a simple check list of what somebody accomplished. I’ve already seen mentions of trips to the nurse and descriptions of what somebody had for lunch. I coach people toward the content we need, toward a meaningful narrative about their project work. I use collaborative commenting and examples of good work from others to show people what we desire to accomplish. The process is slow, but after a few days they normally get it. And then the magic happens. I no longer need status meetings to go over routine project business. Instead, I read and comment on areas that concern me. The worst case scenario now is actually calling a status meeting. Why waste the time?

I want to see more from my project team, but I’ve found starting small is the best way to get people writing. I ask them for the first three items, what I actually want is the full list:

Describe the previous day’s events (Or describe the current day as you work)
Describe potential risk items
Telegraph failure and potential misses
Describe new action items (thinks that were not part of the plan)
Linking to relevant deliverable or changes in scope
Comment on questions posed by readers
Anticipate what interests a reader
Keep the Program Manager informed

It’s easy to expand adoption to include the additional concepts. I use a version of the Socratic Method to encourage discussion and help with the adoption of new concepts. Simply asking the right questions will lead people down the path of observable work. For example, when a PM notes a potential miss, I post a question asking what recovery measures are in place and who is responsible for them. The next time the PM makes a post, I often find the information is included. I keep asking questions until the PM learns to narrate the story in a deep and meaningful way. I reinforce the process daily.

I write a journal too. I use it as a teaching tool for my team and to educate my boss on what is going on with a project, or in my case, all of our projects. When I started managing our PMO, the first thing my boss described was a sense of “not knowing” or “not understanding” what was going on with the 39 projects in our portfolio. I’m a big fan of using small incremental changes to tame big complex projects. Month-by-month we’ve adjusted how projects are managed. Always with an eye towards increased use of our internal wiki and on developing rich content to describe our projects. The results are not yet in, but I can tell you that managing projects is becoming easier, and our success rate is going up. I know my boss feels more connected to our projects and we are less at risk of failure. And all of this is happening because people are making a small 15 minute daily change in the way they work. They are telling the story of their project as they do the work. It’s pure Observable Work, now all we have to do is learn how to keep up with our reading.

Technorati Tags: Observable Work,Information Streams,Blogging at work,Wiki,Project Management,Narrating your work

On becoming a community manager

2010-11-17T13:08:00.001-08:00

It is an odd feeling, that “ah ha” or “oh snap” moment when you realize that you are out of sync with a larger community of people in your profession. It does not happen often, and for me it feels like discovering a hidden chapter to a well read book. I simply can’t believe I missed chapter 11, it was right there between chapters 10 and 12. I felt this odd but familiar sensation when sitting in on sessions at the recent Enterprise 2.0 Conference in Santa Clara, where I heard the term “community manager” used to describe a large part of what I do. The world shifted a little and suddenly I realized that most of the work I do to manage projects falls under the title of community manager.

Sure, my community is small and focused on complex technical projects, but it is a community all the same, and as I learned, my community has the same problems as everyone else. This led me to my next realization, I am not alone. I felt connected to larger community of people traveling the same path. I think that’s what conferences are for, that and surviving vendor sales pitches.

Naming what I do has consequences. It caused me to think of my role differently. I see that part of my responsibility is to teach. I do this now, but my focus is on teaching project management skills. What I need to teach are collaboration concepts, and reinforce them so that they become collaboration habits. It is not enough to develop a new crop of project managers, I must also develop people who will expand the use of our internal tools and, more importantly, use the tools to solve their own problems. This concept extends to our internal customers too, but teaching my geographically diverse customer base is never an easy task. Simply encouraging my team to extend collaborative participation will yield big gains, not to mention change the way we work. I need to do something more meaningful here, like conducting an internal seminar.

Collaboration habits or project management habits, call it what you want, but it is a constant theme for me. I think in part because of my exposure to the Toyota Production System which teaches the value of building constant measurable processes. Also, I know that small changes to daily habits are the key success drivers behind most large efforts. And finally, I know that an effective way to teach difficult concepts is to break things down into small pieces and teach them until they become habits. Once habits form, start the next level of training and repeat until the objective is reached.

The problem with developing habits for Enterprise 2.0 style collaboration is that we already have ingrained collaboration habits; but they are focused on the wrong tools. Collaboration is meetings, phone calls, and the use of email. Teaching people to rely less on a habit that they already use successfully is no small task. They don’t see meetings or email as bad habits so why should they change? An effective way to overcome this obstacle is to start small and develop whole new sets of habits supporting the new technology. Change will be gradual, but it will yield results.

Rachael Happe mentioned me in her Recap of the Enterprise 2.0 Conference. A casual reference I made during our presentation to the realization that I was a community manager was one of her favorite moments from the Enterprise 2.0 conference. I must admit it was one of my favorite moments too. As was ending my presentation, because speaking in public is fun, terrifying, and a gigantic relief when over.

I’m working on two concepts inspired by listening to conference speakers from the Community Development and Management Track. The first concept is to start the design of a customer centric view of the data streams generated by project activity. I was inspired by Greg Lowe of Alcatel-Lucent who demonstrated the value of customized activity streams in the E2.0 Blackbelt Practioners’ In-Depth Workshop. What struck me as profound was his insistence on the value of news feeds from the perspective of other users. The view we came up with is designed around a non-managerial employee who will be directly and profoundly affected by a large ERP project. It is their landing pad for all things related to the project and also an entry point for collaboration. It also answers basic questions and points customers to meaningful content without distracting them with project minutia. In other words, my view of a project works for me, but not for my customers. This should push more people toward collaboration.

The second process I’ve started is old school. I was inspired by Claire Flanagan and Megan Murray during their portion of the E2.0 Blackbelt Practitioners' In-Depth Workshop where Claire said, "community managers take offline action to stimulate online engagement." Any internal customer who comments on one of the many articles gets a follow-up message from me via email and possibly a phone call. Since my new ERP project has about 40 non-IS users, I’ve built a personal wiki to track progress on my follow-ups. By the time I hit the ground for the real work on the project early next year, I hope to have worked through the whole list. This task is more daunting from a collaboration standpoint. It is deliberate collaboration aimed at drawing people into a process they are not used to using. I must be careful to create content that will appeal to a wide audience for this to be successful, and I must work the process every day.

Technorati Tags: Enterprise 2.0,Wikis,Project Management,Collaboration

The risk of exposure in Observable Work

2010-11-06T12:35:00.001-07:00

Observable Work has a flaw which is difficult to overcome. The general issue involves dealing with conflict in an open forum. The specific issue is the risk of exposure resulting from an admission in a post that might lead an influential third party to conclude that the author is to blame for a failure on a project. This fear paralyzes free expression and acts as a damper on clear communication.

For example, let's say a project goes behind schedule because of a snafu on the technical track. The conversation, which is essentially a problem statement and subsequent discussion thread on possible failure modes, is theoretically visible to all 65,000 employees in the company. Once a team member posts that a possible failure mode was an improperly executed procedure, it does not take long for a third party to figure out that only two people can execute the script, and therefore one of them actually caused delay. Who are these mysterious third parties? Bosses, Bosses' Bosses, Auditors, "enemies" of particular projects, people with axes to grind. Et cetera. These people exist everywhere in organizations and it is a fact of life. It is in how we choose to deal with these facts that will make or break any project and ultimately, drive the overall performance of a company.

There is nothing you can do to compel a team member to expose their mistakes in a scenario like this. Especially when a likely outcome for a politically motivated third party is negative. As a project manager, you must provide a level of safety that ensures free collaboration and engenders trust while at the same time fosters openness in the discussion thread.

Our approach has grown more complex as adoption of observable work techniques and the use of our open wiki by team members has increased. Our initial one size fits all approach has drifted towards a one size fits most approach, with some people needing protection.

When we started, everybody is our company was capable of viewing our project wiki. The reason behind this approach is the need to involve anyone anywhere, on demand, in project work. That flexibility is key. The theoretical limit was 65,000 people, while the practical limit, those who were actually interested enough to look, was closer to 150. The actual limit, people who care about the project, may only be 25.

However, In the minds of the team, they are always writing for an audience of 65,000 people, not 25. This miscalculation greatly influences what they are willing to write about. Caution guides every decision when an employee thinks their job may be at risk, or that they might be viewed as attacking a colleague. Our job is to provide a safe but open workspace limited to the people who actually need to know about the mistake, which in practice may be limited to as few as 10 people.

My colleague (and Director) Brian Tullis recently modified our current model to include a work group level view of the main workspace. He took this action after an open discussion on a troubled project reveled that team members feel exposed if they post their myriad self-assessed mistakes in an open wiki. Understanding this concern allowed Brian to create a semi-private “open to work group” workspace as a subset of our open wiki. The combination of the two workspace views allowed for open collaboration on non-controversial issues, and protected collaboration on controversial issues. Our setup has four tiers, built on the observable work definition of "observable in context" and the core pattern of "respect organizational boundaries":

Open to all – This is where the work gets done. Every article, milestone, deliverable, and conversations starts here. In theory, any person in the company can view any file. It’s an open wiki limited only by access to the company WAN. on a percentage basis, 98% of all articles reside here.

Open to work group – this is the newly created workspace mentioned above with access limited to our group. In this case, our work group is our IS organization. Since we post most articles in the “open to all” workspace, this area is limited to items that might cause the risk of exposure to a team member. A practical example is a semi-private discussion happening on a public project deliverable. Everyone sees the deliverable, but only the project team sees the semi-private discussion and it's all happening on the same permalink URL. It is a really nice capability of our platform.

Open to Management – this is an original group created when we started the open wiki. It is a safe place to for the IS management lead team to collaborate on issues that require privacy or to support work processes that are privileged. Main articles may post in the “open to all” wiki while the collaboration takes place in the “open to management” workspace.

Private – An individual workspace is an additional layer where an individual can comment on a “open to all” article but keep the content private. A good example may be tagging an article for a follow-up with reference notes.

Something like this:

How does this work in practice? For now, which is the adoption phase, the process is guided. A project manager will create a wiki article that is in the open to all workspace and then ask team members to use the article to discuss and resolve the problem. The project manager teaches a standard lean problem solving method as part of the process. Once risky subject matter comes up, the project manager then guides the discuss towards the Open to work group workspace. After a few iterations of this method, the process becomes a work group habit and no longer require guidance.

Of course, the project manager is also obligated to guide discussions down investigative tracks that focus on process failures instead of individual failures. In our original example of a poorly executed procedure, the team looks at the procedure to remove the ambiguities which allowed human failure. One assumes that careless employees are weeded out by another process. With this in mind, the team is free to focuses on actionable steps and counter measures. These are the conversations that are driven to the limited workspace because of their inherent risk of exposure. Once resolved, the conversation and observable work migrates up to the open wiki.

We've learned that openness has a negative correlation to risk aversion. With this knowledge we limit the risk of exposure through controlled access and practice. The process works, but progress is slow.

TUG 2010 / Observable Workshop Notes

2010-11-02T13:06:00.001-07:00

I had the pleasure to attend the Traction User Group (TUG) 2010 meeting in Newport, RI.

For a general overview of the conference, I suggest that you see Greg Lloyd’s summary and agenda, which points you to relevant links with video, audio, and slide content. Even if you use another platform besides Traction, much of this is worth your time.

Elsewhere, Jack Vinson posted an excellent recap on his blog, as did Jim McGee, who was the opening keynote speaker.

In this particular post I want to make clear my motivations for attending the conference and participating in the Observable Workshop. First, I am trying to improve the performance of my team and my company, and I hoped to learn a lot from everyone at the conference. Second, I will present along with Joe Crumpler at Enterprise 2.0 Santa Clara (Wednesday, Session 30). I was hoping to sharpen my thinking on #owork, try out some ideas from our presentation, and steal shamelessly from my fellow workshop participants. I could not be happier with what I got out of this event. Everyone that I met there – you all rock. Thank you. Thank you. Thank you.

For consuming the Observable Workshop content, I recommend downloading the MP3 audio and listening as a podcast (perhaps even at 2x speed if you own an iPod/iPhone). Audio Part I, Part II.

Definition and Core Patterns

Here are two slides from our Santa Clara presentation that come directly from the workshop.

First, I have a working definition for #owork. Many thanks to Greg Lloyd for helping with that specifically:

Generic patterns that make work products more visible and the activity of work more transparent. Does that make sense?

Second, I came away with six core patterns. There are probably more, and they could be better stated, but the presentation was due on October 21…

I will explain the core patterns by pasting in the slide notes. By the way, all of this will be available on SlideShare after the conference. Here we go:

These core patterns, we think, are the basis for the people / process / technology patterns through which we have implemented observable work. They may not be the best list, and our thinking is still evolving.

First and foremost, most of us work for organizations…and where they exist, we have to respect those boundaries. Otherwise we are going to have trouble paying our mortgages. That being said, there is a lot of dysfunctional nonsense going on that we think that we can overcome.

The best technological framework to make things visible is through the web. Unless of course your audience is using IE6.

Maybe not on Twitter…but think about how you can log or narrate what you do for the benefit of yourself and your team. This is a practice used by many craft workers over the years…and it’s a practice we have lost. In its simplest, it means writing down or recording what you do, as much as possible.

Information changes all of the time. If you distribute an artifact (file, page, presentation, etc…) – link to it. Do not send the information itself unless it’s absolutely necessary.

You have a finite # of keystrokes available in your hands over your lifetime. Use them judiciously…so distribute information to the widest scope possible to be most efficient.

No matter what Google says, it is important to give search engines some help. You need to be “discoverable”, and a great route to that is through naming conventions. There is an art to naming files, articles, web pages. Think about your audience and have some discipline to how you ‘name’ things within your organization without going overboard into taxonomy hell. This topic led to some heated debate at our observable workshop, and if during Q&A anyone would like to debate it, we’re ready for you.

Now that you have seen the core principles and the core patterns…if we haven’t convinced you at this point, it is probably not worth it to continue. The naysayers will shout that the real world doesn’t work like this and that there’s no way that the CEO is going to live blog secret strategy meetings to the public, or even to most of the company – and that is not what we are proposing. Be patient and we hope to show you the practical value of how these can be applied in real world situations.

Onward to Santa Clara and Beyond

We discussed and debated other patterns and issues that did not make it into my slides. In particular, how can we TEACH the patterns to everyone else, since those of us in the workshop seem to find it quite obvious (!) ?

Other lively topics included…Version control. Which formats to use. Dealing with conflict in an observable situation (war gaming, debate). Separating notification from content. How to make email a more observable tool. Is email evil? The role of management. How to incentivize individuals/users. Downsides of transparency. The barriers to “observability” are too high and people are too busy to fundamentally change how they work. The role of good writing. Enterprise search. On and On. You should really, really go listen to those podcasts!

Our presentation in Santa Clara will focus on how we have used the core #owork patterns in the real world. For example, we will discuss specific techniques that embody the “Narrate Your Work” pattern. I hope that our use cases are convincing, and I am counting on the attendees to call us on anything that sounds too theoretical or not possible in the “real world”.

Beyond the conference and our presentation, I am energized to work with my colleagues and friends to teach and to practice these patterns everyday, and to walk the walk.

Thanks for your time.

Technorati Tags: #owork,#e2conf

Tips – The Monday habit

2010-10-18T11:16:00.001-07:00

I am a creature of habit. I try hard to keep good habits and shed the bad ones. One habit I’ve kept for the last 20 years is called the Monday list. It is a 4x6 index card with a simple list of things I must do each Monday morning in the first hour of my work day. I start work at 8:00 am. Within an hour, I’ve finished this list 90% of the time and on almost all Mondays. I would like to say I picked this habit up from Atul Gawande’s outstanding book, The Checklist Manifesto, but the truth is much more mundane. The index card is a crutch for a busy mind. I forget without it.

This is my current Monday list:

Clear potential archive items (in e-mail)
Review calendar
Make follow-up call list
Review/approve expired documents
Read contractor status reports
Scan for urgent items
Scan for next actions
Review deliverables/commitments

Why are these important?

Clear potential archive items – it’s not important but if I don’t do it my company email policy will cause me to lose valuable information. I can’t figure out how to automate this task completely, so I must do the task manually.

Review calendar – This is a vital task. I must figure out where I will be, what meetings I must prep for, and how much time I have available to support other activities. If I don’t plan my week, somebody else plans it for me.

Make follow-up call list – My primary weapon is the phone. I make a hit list each week of people I need to talk to and the topics I need to discuss. This is not a tactical list, it’s for strategic issues only. This week’s list has 7 people on 3 topics. Last week had 4 people on 2 topics. I credit this method with advancing most of my big projects.

Review/approve expired documents – This is not important to me, but it is important to my colleagues. If I don’t do my part to support the larger organization, I fail as a manager. I do my part no matter what, even if I have to schedule the time to do some deep reading of an obscure procedure. If I don’t, somebody else in the organization will take time out of their busy day to hunt me down and make me do this task, which is all wasted effort and engenders resentment.

Read contractor status reports – I must do this if I am to keep up with my managerial duties. The various contractors I work with help me manage my responsibilities across several different locations. Reading these reports are my chance to influence their activities and acknowledge their contributions. It’s time well spent.

Scan for urgent items – This is an important task in my world. I must be on top of the issues/projects in play and as they relate to the organization I support. People normally call with bad news, but this scan helps me catch items that might otherwise slip by my notice. I do the scan in three passes, my colleagues, my employees, and then the people I support. I don’t solve the problem during the scan. Instead, I mark it for follow up and make an index card (my version of a to do list). The follow-up comes later in day.

Scan for next actions – This is another important task but its focus is on projects. I’m looking for things I need to do that are holding up progress on a project. Again, I take note (by making an index card), and plan the follow-up action for later in the day. This is a GTD method. One of several I use religiously.

Review deliverables/commitments – This is perhaps the most important item on the list and one that I do by habit first (even though it is numbered at 8). A manager is judged by how well they keep commitments and deliverables. I make sure to understand what I am supposed to deliver, and plan the steps necessary to get it done.

Not bad for an hour, right? The key concept here is repetition. Know what is important or needed, and then execute your method each week until it’s a habit. You will find that the consistency it brings to your work will simplify your life and make you more effective.

I have a card for each day of the week, a card for month end, a card for year end, and a small deck of cards for each month that I make as part of my yearly planning process. It’s one reason I always hit my yearly objectives. I also have a card for another hour on Monday afternoon that I dedicate to projects. I’ll post more on that later.

And just so you don’t think I’m an anti-technology prude… I carry a picture of my card with me on my iPhone so that I always have it available.

Technorati Tags: Productivity,Tips,Hacks

Gathering My Thoughts On Observable Work

2010-09-20T08:00:00.000-07:00

I can conclude at this point in my career that the extent to which observable work patterns are deployed in organizations will have almost everything to do with psycho-socio-political concerns and almost nothing to do with technology. In this post I will start with some practical foundations and my personal motivations, and circle back to the conclusion about the role of people, politics and soft skills.

Why Observable Work?

To get very specific, here are some of the things that I worry about for my team and my company. How can we effectively:

Share what might be half-baked ideas that would benefit from outside input, but that we don’t share openly for fear of being shot down?
Document and share lessons learned on projects/audits/operational failures so that we don’t repeat the same mistakes again?
Narrate our work so that we don’t have to drag each other into status meetings and waste our collective time reporting what we did instead of letting status emerge naturally from our visible work?
Make our electronic documents come alive and be linked across an organization instead of going to die in networked file shares and content silos?
Describe exactly the heck it is we are talking about when it comes to social media being used to get work done without calling it “Wikipedia for the workplace” or “Facebook for the enterprise”?

Translation:

Promote and foster innovation
Promote best practices and continuous improvement
Narrate our work and expose it through targeted activity streams
Unlock our documents and leverage hypertext
Make it all happen without coming across to our colleagues as social-media-hyping, jargon-spewing-idiots

My personal reasons for believing that these are important come from my own core values that I share with anyone that will listen:

Transparency
Continuous improvement and learning
Narrating what I do because it helps me get work done, and hopefully helps others too
Debate and disagreement as a means for seeking truth
Exposing failures so that they are a lesson for others

I have had innumerable experiences in my professional life where failing to inject these principles into various business situations made getting anything done quite nearly impossible, so I am making it my mission to try to spread them in my own organization.

What Does It All Mean?

My goal, ultimately, is something very practical. It is not constructing a technological Panopticon from which we can spy on the inner workings of unrelated colleagues on the other side of the globe. The last thing we need are business practices and supporting information technology inspired by prison design.

I think that what I am trying to accomplish is transparency in the sense of getting as few as two people that work for the same company on the same project to be able to see and to understand explicitly what each other is doing…so that together they can create a better outcome for the organization.

And if we’re lucky, add-on benefits of in-the-flow communication, strategic alignment, and knowledge re-use all emerge from this first principle of helping teams get work done.

Perhaps this doesn’t seem like a big deal. But my experience is that in most organizations, it is, and we don’t like to talk about it.

Soft Skills

Meanwhile…for years people like me in IT ignored the psycho-social aspects of management and organizational dynamics. The process and and technology always seemed to come before the people.

So, into the boiling cauldron of my own personal views and the day to day realities of modern organizational life insert:

Web 2.0, Enterprise 2.0, and social everything
Blogs, wikis, activity streams
SharePoint, Twitter, Yammer and other tools
Blah blah blah, et cetera, ad nauseum

Eureka! I realize that at long last I have a technology platform which suits my own worldview and will allow me to empower everyone else in this new age of the transparent hyper-social workplace. Hmmm.

I am lucky to have thoughtful and experienced colleagues who help me every single day. I have had many influential teachers, even though in many cases I was their boss. If you are open to learning, it will come from places where you least expect it. Their wisdom has helped to mitigate some of my wilder idealist tendencies.

Also, I have found that when it comes to social technology that it is good to be skeptical just short of turning cynical. Failing that, I at least know where to find skeptical viewpoints. I’ve been a fan of Venkatesh Rao’s Ribbonfarm blog for over a year now, and it was through one of his blog posts that I learned about a book called, “Images of Organization” and its eight metaphors of organization.

I haven’t finished the book yet, but I’m currently working on chapter 7 called, “Exploring Plato’s Cave: Organizations as Psychic Prisons”, which should give you an idea about what you’d be getting yourself into if you read it. Be warned.

Going Forward

It is apparent that this observable work stuff will happen only in the right context, accounting for culture, bureaucracy, performance measurement mechanisms, human psychology, and certainly, politics. Duh, duh, and duh the community managers say. The lessons from this reach into all aspects of technology adoption in companies and is in no way specific to the Enterprise 2.0 era. Those of us in IT typically do not worry very much about these sorts of things. If you do, and always have, good for you.

There are deep-seated reasons why all of these things are problematic in organizations big and small. Those issues are what I hope to address as I develop my take on patterns of observable work.

So far I am concluding that the People patterns are most important; however, they are the hardest to define and replicate widely because they are so dependent upon specific organizational contexts. Of course, the Technology and Process patterns are relatively easy to convey with screenshots and slides…but I fear that they just don’t matter as much!

Obviously, patterns that have a demonstrated practical benefit are what matter most, and that is what everyone wants to hear about. Everyone wants to see concrete examples about how Enterprise 2.0 and Observable Work and Communities have been implemented in specific contexts, generating millions of dollars of revenue and accomplishing other world-saving feats of strength. However, I really do think that it is important to try to define, discuss, and develop observable work patterns even if only in theory because it really will help us all get work done.

I have presentations to prepare for the Traction User Group and Enterprise 2.0. Time to get going.

E20 Santa Clara: Patterns of Observable Work

2010-08-29T14:14:00.001-07:00

My session proposal for E20 Santa Clara was accepted. I will present along with Joe Crumpler in the community track. Now comes the hard part of putting together something coherent that hopefully imparts something useful to the attendees. Honestly, I am starting to fear that I have already told you 125% of what I know. If you can live with that possibility, by all means, read on!

Here goes: why am I presenting on this, what am I talking about, and how can it be implemented?

Why

Observable work principles implemented through enabling technology creates stronger connections with our customers and colleagues. As a result, the team and the company will perform better.

What

What is Observable Work? I'm not sure I know. By writing about it I hope to figure it out for myself.

I think that it is a more open way of working enabled by people and technology that moves away from closed silos and towards open, integrated work processes. It recognizes that there are still hierarchies and org charts and matrixed organizations and needs for security and compliance. On the other hand, it also recognizes that the only way to deal with the crushing complexity of the modern information work environment is to embrace the fact that everything is "intertwingled".

To quote from Greg Lloyd's post,

Much of what a sociologist would call "social" behavior when talking about Enterprise 2.0 would naturally center on the sociology of work: how people communicate and interact with others while dealing with questions, issues, exceptions, suggestions and the messy stuff that routine transactional systems can't handle, along with interpersonal relationships that develop in a specific context or as member of an extended enterprise (including customers, suppliers, consultants and external as well as internal stakeholders).

How

In previous work, I have outlined some principles. I now propose to talk in terms of patterns which hopefully give more of a roadmap of how to implement Observable Work in an organization. I am likely heavily borrowing from many ideas already expressed in such places as Wikipatterns; however, I hope that I am adding a bit of original thought here. If not, I would love to know.

As I see it, these patterns are implemented through a combination of people, technology and process. Commonly, any information technology-enabled solution is thought about as a combination of people, processes, and technology. Here, the idea is that through a combination of the right people, using underlying technology, you can implement processes that will make you and your team more effective.

This is based largely on my own experience, brought to life in this blog post through the help of lots of colleagues and friends that have shaped my thinking.

People Patterns

Various organizational, cultural, psycho-social, and management elements that enable an Observable Work environment.

Community of Trust
Community Manager
Openness is celebrated
In Process Culture
Learning and Teaching is Enabled and Rewarded

Technology Patterns

Specific functionality and features that when put to the proper use enable an Observable Work environment.

Hypertext allows stronger connections
Activity Streams: Filtered Please!
Email Used Smartly
Security Security Security
A Directory Stuffed Full of Files Doesn't Help
In Line Everything
User Interface and Navigation
Widgets and Mashups and Gadgets

Process Patterns

Now that you have the right people and organizational practices, along with a proper toolset, here are some generic process patterns that could work in many different situations:

Crowdsource Your Wicked Problems
Build Links Between Your Silos
Status From Visible Work
Lightweight Approvals, Surveys, and other Barely-Repeatable Processes
Open Read Access Fosters a Climate of Ambient Awareness
Integrated Personal Workspaces
Trusted Collaborative Spaces
Narrate Your Work: Worklogs and Other Techniques

That’s my brain dump. I think that is it for now. Each of these patterns could be a slide in our presentation, but I doubt that we’ll have time for that. I’m still not sure how this all fits into a PowerPoint format. Edward Tufte, any ideas?

In the meantime I will be writing my own wiki entries for these patterns, perhaps posting some details back here for feedback. Thanks for your time.

What does “done” look like?

2010-08-03T22:20:00.001-07:00

I just finished a review of about 30 projects that were sitting in the PMO and classified as in work, but not really making progress. Most of the projects shared one trait, they lacked a definition for what it takes to complete a project. The project managers, had no idea what “done” looks like.

A few projects had a specification, but being technically oriented, this was expected. A few projects had a vaguely stated goal or description. But most had nothing more than a simple one line description, like modify application X to do Y. Only, we all know that making the specified modification does not make a project “done.” There is so much more to do. The actual modification is only a piece.

Defining “done” on a project takes planning. I don’t expect project managers to define it for themselves. If a set of deliverables is defined for a project before it starts, then the project has a chance to meet its goals through planning to achieve its deliverables. For example, if an Executive Communication Plan is a deliverable, then accomplishing its discreet elements make an achievable “done” condition. The discrete elements:

Initial kickoff summary
Monthly executive summary (6)
Project go live notification
Post project review summary
Project closure notification

“Done” for the executive communication plan is 10 reports. The expectation is set. The PM must deliver or the project cannot be considered done. Taking the step of defining this for a technical PM is advised. They typically focus on the actual fix and not the supporting process. Business process owners feel abused in a situation like this, and rightly so. Make it easy for the PM. Define the deliverables. Use a wiki to do it.

When tied to a project wiki, the discrete element Initial Kickoff Summary is a well defined article with examples, training material, and links to actual successful and unsuccessful initial kickoff summaries from other projects.

When assembling a project for a PM, the list of deliverables becomes the guide for a project manager’s overall effort. The project may have a dozen deliverables in addition to the obligatory technical spec and project plan. Each deliverable is backed up by a detailed wiki entry covering a description, help files, linked examples, and community comments. The PM should be able to assemble a finished project with minimal direct supervision. Show the PM what done looks like so the PM can hit the goal.

The 30 projects I have in review will slowly be assigned deliverables. The PMs will learn about the deliverables, what good looks like for a deliverable, and, they will develop a feel for moving a project forward outside of their normal technical bubble. In just a few weeks, poorly defined projects will become structured and transparent. PMs will learn to plan and execute deliverables while at the same time moving their projects forward as if by magic. After all, it’s hard to write an executive summary if there is nothing to summarize.

A project comes together once PMs realize they can post their Executive Summary or other deliverable to their project wiki. The deliverable jumps the gap from a static document to observable work. People watching the project wiki can see progress, either on demand by viewing a project’s activity stream or as-it-happens through a subscription to email updates. The PMO can watch a project move through its deliverables and can contribute to the conversation through collaborative commenting. And preparing portfolio-wide summaries of project status can be done in minutes rather than hours and days.

Providing structure to a project via deliverables and a project wiki produces astounding results. Making the work transparent and observable propels a project toward success. But the burden is on the creative process. Someone must write the articles defining each deliverable. Someone must link in relevant content. And someone must teach a new tool and process to skeptical PMs. In my case, that someone is me.

Technorati Tags: Project Managers,Observable Work,Project Management,Wiki

Enterprise 2.0 and Observable Work: Recap and Speaker Notes

2010-07-30T14:48:00.001-07:00

Warning - this is a long post. What follows are images of the slides and our speaker notes from our presentation titled, “Enterprise 2.0 and Observable Work” from the Catalyst 2010 Conference in San Diego. This earlier post also contains a link to the SlideShare presentation.

Brian presented the opening through slide 18. Joe took over and presented the case study of the QAD implementation in Suzhou, accentuating the gains realized from reducing project status meetings. Brian closed the presentation with slides 24-27. We did not present the appendix but encouraged the attendees to download the presentation and take a look at the additional information.

The general concept of observable work seemed to resonate with the audience – although we were challenged to apply the concept to highly regulated industries such as finance or healthcare.

The time savings associated with meeting elimination was a hot topic during the Q&A and on Twitter with the #Owork tag. I think it deserves some clarification. Trust me when I say that there is nothing my colleagues hate more than status meetings with their managers.

Joe is talking about 100 hours per week savings – not 100 hours total over the life of the project. If you don’t believe us, ask Joe for clarification on his calculation. This was like a pickup of 2 full time resources through reduction of lengthy status meetings.

This starts with the title slide and notes, where applicable, appear under each slide. We did not read these notes during the big show but they should give you a pretty good idea of what we discussed.

There were no animations or audio/video. Maybe in the next version…

Today we are going to demonstrate the concept of Observable Work, and how we have implemented it within our team at Alcoa Fastening Systems.

While we think what we have to say is very interesting and useful, it does not necessarily represent the viewpoints of our employer and parent company.

So, why are we here, and why should you listen to what we have to say?

After a short background on us and our company, we will begin the discussion of "Observable Work". This is a term that has been around for a few years, and we found that it describes very well how we strive to work.

It has helped to crystallize our thinking on what we are trying to do with collaboration practices and 2.0 technologies.

Instead of trying to define Observable Work, we will list some core principles to show what it is. And I cannot promise that I will not use images of monkeys to do it.

We have one slide on enabling technologies showing some familiar "2.0" technical themes.

Finally, we hope to spend much of our time on real world examples. Joe will present a case study of how we applied these principles and technology to implement an ERP system in Suzhou, China.

We will be happy to take your questions at the end of the talk.

Our primary mission at Alcoa Fastening Systems Information Services is the delivery, operation, and enhancement of enterprise software and related services for thousands of internal customers.

My role is Director of Information Services. Joe manages our North America Aerospace Project Management Office, where he oversees and manages major system implementations and integration efforts across multiple locations.

We have about 80 IS colleagues at 20 operating locations, worldwide, and we also work hand in hand with our Corporate IS organization. It is a large, virtual team

We have the perhaps not unique situation of working for a company that grew by acquisition, leading to a complex hairball of legacy business processes and accompanying IT platforms. We work in a highly matrixed environment.

Most of us have at least two bosses; some of us more - although I don't think any of us have 8 bosses like Peter Gibbons in Office Space. We are a public company, so we have Sarbanes-Oxley to worry about.

On our team, we have a charter to deliver common IT-enabled solutions across dozens of locations, each of which is evaluated by a stand-alone P&L. The people we work for are highly focused on manufacturing and engineering, rather than the black box of IT.

We are always looking for ways to improve ourselves and our team’s performance. We cannot change the world, but there are some things squarely within our control.

We don’t like silos. They prevent work from getting done.

We must be aligned in our matrixed environment, and multiple locations. We cannot accomplish our business objectives if we are not aligned.

Almost nothing is set in stone. We plan, and re-plan, all of the time. Battle plans rarely survive first contact with the enemy.

These guys must really trust each other. In using the term silos I am thinking at all levels of organization - roles within a department, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable. In fact, I believe that managers have a responsibility to make their own silo as permeable as possible.

The real underpinning of the first four principles is trust. No one is going to feel comfortable working across silos, outside of their normal chain of command and comfort zone, without it. I don't have a formula for that, but it takes time, and you can lose it in an instant.

We are social where required, but it's not something that we dwell on.

The social aspect deserves a little more discussion. A pure focus on Information and Process Flows tends to ignore the social dimension of how we live and work as human beings. Our ability to be effective will suffer greatly if we neglect this.

Being IT guys, and introverts at heart, remembering this is not always easy - but we try to get a little better at it every day – although I don’t think that we will ever groom each other like the chimps in that slide.

We seek simple solutions to business problems, fighting a tendency to over engineer just because it is possible.

What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved.

The last slide about status is subtle, but important. We believe that working this way can reduce overhead and administration, allowing everyone to focus on doing work, not reporting on it. Joe will touch on that in his case study.

The underlying technologies of Enterprise 2.0 are key to implementing observable work practices.

Hypertext, a solid security model, advanced search, linking, aggregation, activity streams, classic wiki/blogging features are all important and we use them heavily.

Legacy productivity tools are an important part of any successful productivity/collaboration platform - we are thinking particularly about email as a universal notification and editing tool because 100% of our users are comfortable with it.

I would like to transition into some real world examples, and show you what this looks like in practice. My company is very safety conscious. I hope that our safety managers will appreciate the fact that this kid is wearing all of his personal protective equipment.

This example is a test scenario for a customer return process, part of a major system upgrade. The business analyst who created this article had some simple goals.

describe the business process that needs to be tested within the software
get feedback and approval from colleagues in Customer Service, Quality, and Finance

Notice the paragraph-level comments by Customer Service and Quality - there is a threaded discussion in the middle of this test scenario.

At the bottom of the article, there are "I approve" comments from everyone time and date stamped, with links back to their profiles.

A key takeaway is that we invent lightweight processes as required using text, tags, and comments.

We did not trade emails to collaborate and we did not use a structured workflow or business process management system to accomplish the approvals.

We strive to create and share all of our work products just like this – for projects, strategy, compliance, documentation, budget, etc.

Approximately 30,000 of my colleagues can read that hypertext article if they need to see it, and 2,500 can comment on it. If we need to show them, or pull them in for collaboration, we can.

Over to Joe.

(Joe Crumpler presented his case study on Suzhou. It went very well – here are his notes)

I’m a project manager. I’ve done it most my professional life. As a project manager, I’ve been on a continual quest for tools. I’ve used almost everything imaginable, and with varying degrees of success. A few years ago I started thinking about how to use a wiki to manage some of the complex communication processes common to technical projects. We use TeamPage. I’ve used it on a few other projects, but for the project in China, I pushed our use forward in an effort to drive more direct benefits to the project.

We did a midmarket ERP implementation of QAD to replace a failed implementation of another ERP product from a few years in the past. From experience, we knew about the language barrier. We knew about the cultural barriers, we knew about the lack of a systems culture, and most importantly, we knew the turnover rate was astoundingly high. 30% of the people we train today will be working for another company in six months.

Because we knew what to expect, we were prepared. We pushed most of the knowledge to the wiki, but we also pushed the project structure and planning process to the wiki. I used MS Project and Traction TeamPage, and it was a marriage of two diametrically opposed tools, but it worked fine.

The key concept in my effort was “build structure.”

Everything that was in my head became an article. We held nothing back. Simple things like job descriptions, roles, work schedules, travel requirements, all found a home as an article. The more complex stuff, due diligence audits, planning, scope, and the project plan… all of it became content. Each member of the team read and re-read every article. Comment threads started and grew. We linked it all together in too many ways to count. New team members came up to speed in a few hours. Learning what the project was became second nature.

Then we broke the project plan down into milestones and deliverables. Each milestone was described in detail with up and downstream dependencies, responsible parties, due dates, and a definition of what “done” was. This too was linked into the project wiki at every conceivable level. Then we translated it into Mandarin. Well, more accurately, we built it all and translated it all at the same time. It simply grew up around a core concept of building structure and defining everything.

Why do we do this? We build fasteners at AFS, waste is known by the Japanese term muda. On projects, meetings are muda. Meetings suck the life out of your team and bring progress to a halt. The more I define a project in a wiki, the less I time I consume in a meeting. We did not have project status meetings. All that meeting content was in our wiki.

Instead of project status meetings, project resources updated status on wiki articles. As the project manager, I monitored status. My time commitment did not shrink, I still worked a long hard week, but my team spent almost no time in meetings. My obligation was to keep up with the flood of information and provide direction. A daily checkpoint meeting, lasting no more than half an hour, replaced a three times a week four hour (or more) status meeting. The simple act of updating status via comments freed us from the need to meet for status. I picked up at least 80 hours of productive labor each week because of this. It resulted in a 30% labor pickup overall. I’ll never go back to the old way.

Peer pressure is a great motivator. On a project team, fear of exposing yourself to the ridicule and ribbing of your teammates keeps people focused on updating their activities. Small frequent updates telegraph problems. Everyone knows what is going on. Everyone has access to the latest files, information, and planning. The PM does not need to babysit. The PM can focus on removing the obstacles that would prevent the team from achieving its goals.

What was our goal? We went from request to live in seven months. A team of techs from the US supported a travel team of analysts. We accomplished a task that normally requires at least 2x the time and many more resources. We did it on time and under budget. The stars lined up for us on this project, but our map was in Traction.

People ask me, “What did you do differently?”When I start to tell them about our wiki, they lose interest. They want to know what it was I actually did. They want to know my secret. I tell them about our daily status meetings. We talked each day at 8:30 China time, which was the end of the day in California. I ran a tight meeting. Open issues from previous day’s articles were reviews for open items. Open items were tagged with as “to do”. Open unresolved issues were updated in the meeting if needed. A new article was created and linked to the previous day’s article. New issues were captured. Someone was assigned an action item. Things got done. Rinse and repeat.

I was afraid of losing control, but found the articles a perfect way to catch the incidentals.

The key take away from this was that the, this process cut the team free to work. They saw me from half an hour each day (if you don’t count the bus ride to work). It felt like I lived in their heads because I read every word they wrote. I worked the issues. My team worked without interruption for 8 to 10 hours a day. I had more control, more visibility, and after the project was over, an audit record without precedent. I can’t wait for our internal auditors to take a look at the project.

My customers used the wiki too. All of their training material was linked in. Each article was translated by a stateside team. There was a day or two lag in some cases, but nobody complained. My customers contributed to our discussions, learned about the project, and helped us document our process by approving key milestones and deliverables as comments to articles. My overhead went down, my productivity when up. Like I said in the beginning, I’m a tool user. We’re using this tool in the PMO now and slowing building it up to manage our portfolio of projects. I’m optimistic about the possibilities.

What we tried to demonstrate today was the concept of Observable Work and how we have implemented it on our team. I hope that we have succeeded in that. It is definitely a journey, not a destination.

We do not want to leave you with the impression that we have found the holy grail of productivity and collaboration and the application of social software to work. We have a set of principles and underlying technical solutions that work for us.

Going forward, we want to continue to learn first, and teach second. We are not sure that this approach will scale, but it works ok for us.

As this technology space evolves, it will have implications for us. We can only hope that the principles we have identified can be implemented in any platform, regardless of vendor or underlying technology. Otherwise, we are too busy getting work done to worry too much about it

These are some of the many wonderful thinkers and practitioners out there that helped us directly and indirectly, and whose ideas we have used and remixed.

In particular, I would like to thank Greg Lloyd of Traction Software for introducing me to the concept of Observable Work. I would also like to thank Jim McGee and Rick Ladd for reviewing and commenting on this presentation. Rick is responsible for the monkeys.

Please see Jon Udell's article. As best I can tell, he invented the term Observable Work. There's lots of good stuff here.

From time to time, Joe and I will continue this discussion online in our blog, where we talk about productivity, collaboration, and project management. We would love to see your feedback there.

Thank you for your time. Thanks to my colleagues as well. All of the examples you saw here are just their "Observable Work" in action.

You can connect with us on Twitter or LinkedIn.

You should get a copy of this presentation through participation in the conference. There are a few slides in the appendix with more examples as well as some statistics about our platform and other technical details.

Not presented

Technorati Tags: Observable Work,Catalyst 2010,PowerPoint,Project Management

Observable Work - Catalyst 2010 Presentation

2010-07-30T08:04:00.000-07:00

On July 29, Joe Crumpler and I presented at the Catalyst 2010 Conference in San Diego, California. We had a lot of fun and we had great interaction from the audience. You can check out the Twitter tag #OWork.

Catalyst 2010 Presentation - Enterprise 2.0 and Observable Work

View more presentations from btullis.

Observable Work: The Taming of the Flow

2010-06-25T09:53:00.001-07:00

The last week or so has seen some very insightful comments about the phenomenon of Observable Work. It was touched off by an awesome blog post by Jim McGee on the visibility of knowledge work. Further tweeting and blogging by Traction Software’s Greg Lloyd really got me to thinking. (Greg’s got a great trail going, and the Twitter hashtag #OWork is a great resource as well.)

There are some valid criticisms which focus on the "fire hose" or "waterfall" metaphors. Another one I like is a comparison to the digital rain in The Matrix. If you have ever used Twitter, you quickly realize that you cannot follow everything.

In my view, what it's really all about is going "downstream" a bit, where you can tame the torrential flow into quiet tributaries and wading pools; to wit, some prerequisites/tools/techniques:

hypertext native content
aggregation pages
topic-specific feeds
tagging and tag clouds
user profiles
advanced search

While you are at it, you will probably need a Chief Information Wrangler, Community Manager, Zen Guru Librarian, and/or other hard to find job titles in most companies.

You will need a good platform as well. Some platforms are better or worse at this, and I don’t really want to make the discussion about technology per se. Whether you are using Jive or SharePoint or something else, you should demand that your vendor give you the ability to tame the flow. And it’s not about stopping the use of email and MS Office. They are just part of the flow! Oppose them to your peril.

I have been using Traction TeamPage for the past 2 years to implement the principles of Observable Work, although I didn’t really have the vocabulary to describe what I was actually doing. Jim’s blog opened my eyes to the theory of what I am trying to do in practice. I have dozens of real world examples regarding meetings, project work logs, strategy formation, internal contracts/agreements, project management, compliance, documentation, etc. It is not all puppies and kittens, but it beats the old way.

I’m going to be thinking hard over the next weeks and months on how I can look at some of the theoretical aspects of our experiment so that I can share it more widely. I don’t pretend to have all of the answers here, but I love to share. I will try to add more as time allows.

Deliberate learning

2010-05-06T16:13:00.001-07:00

Assessing the learning needs of a team are among the first problems I focus on when starting a project. I say “learning needs” because I want to find missing skills and plan how to acquire them. Once I understand their needs, I start them on the path to learning new skills using a structured plan. They often don’t realize they are learning new skills.

I challenge people to learn in several ways. The Socratic method works best for daily interactions, but another method teaches the concept of “deliberate leaning.” I urge people to explore what they don’t know and then develop a week-by-week plan to acquire the skills they lack. If they are unwilling or unable, I develop the plan for them as part of their normal project duties.

Let’s take the skill of prioritization as an example. Knowing what to do first is much more complex than working a list. If you do not understand how a business runs, or what is important to management, or what is important to the project, how can you choose between two tasks? How can you prioritize a list of 20 tasks? What rationale would you use to make your decisions?

Breaking the learning goal down into weekly pieces will gradually teach the skill of prioritization. But first, you must understand what it takes to make a prioritization decision. What if there are 20 skills involved? It is possible. Think it through. Once you understand, make a plan.

Week 1 – Develop a high level business process flow
Week 2 – Rank business processes in order of importance
Week 3 – Develop detail business process maps
Week 4 - Rank processes
Week 5 – Match open dev tickets to high level processes and then to lower level processes
Week 6 – Start reviewing programming queue to make sure tickets show proper sequence and priority
Week 7 – Repeat the process until mastered

In this scenario, a talented team member learned to tame an out-of-control process by learning a new skill. The knowledge acquired went from a general overview of the business to specific understanding of key processes over 6 weeks. Learning was deliberate and executed per a plan. In this case they were unwilling to learn at the start, but by week 6 became rabid fans as the project started to show positive results. The trick is to get people to think about acquiring skills so that learning becomes second nature.

I’m deliberate in my approach to learning. A former boss once described me as a mile wide and a mile deep when it came to my understanding of manufacturing and systems. He knew that I developed those skills per a plan, and that I re-examined my needs each month. I ask myself, “What don’t I know?’ Then I figure out how to learn it. For example, these are my goals for this month.

Learn 10 conversational Mandarin phrases. (Needed for a working trip to China)
Lean how a progressive die machine works. (Needed to solve a costing problem in June.)
Read two books related to my job. (Needed to support a the development of our internal Wiki.)
Understand all variables in QAD’s MRP process. (Needed for a working trip to China.)
Master a newly developed application. (Needed for a project in June.)
Master and document the forecasting algorithm for an app experiencing problems. (Added at last review to help solve an unexpected problem.)

I will do every item on the list because they are skills I need to support a project. In my case, everything is a project. I’ve used this method every month for 15 years. This is what I to teach my team. I ask that they figure out what they don’t know and then develop a plan to learn it. I tell them to do it over an over again and watch as they master their environment. What this does for a project is amazing. People become highly skilled contributors who are capable of achieving more and more complex tasks. They grow as employees and feel a heighten sense of value. As a project manager, this is what you want… a team that is continually improving.

Technorati Tags: Project Management,Learning,Skills

Everything is a Project

2010-05-05T21:18:00.001-07:00

“Life is a Project”, so says project guru, fellow Next Things Next blogger and colleague Joe. David Allen and his Getting Things Done method are all about taking stuff and dealing with it in a methodical way – you know, like projects. The title Next Things Next is inspired by GTD. And just today I read a nice post from Jack Vinson on how project management discipline is making inroads in the practice of law.

I find that in today’s workplace, few of us knowledge workers arrive at 8:30, work on the same thing day after day, and then leave at 5:00 only to return the next day to do it all over again. If you do, congratulations. How much does that pay?

My work world is a boiling cauldron of vague requests, shifting priorities, an ever-changing matrix organization structure, a complex international business environment, an understaffed organization…and I could go on and on. I learned over the years that dealing with this takes discipline. Joe made an outstanding post on the value of small, where he talks about how he deals with his “mess”. Read it.

The answer, such as one exists, does not lie in trying to turn every minor request into a board-reviewed, 15 step approval, moon-shot project governed by Project Management Institute’s Project Management Body of Knowledge. I have not found that this particular approach is conducive to continued employment in my business. To paraphrase Lawrence from Office Space, “no man, you’d get your ass kicked for trying something like that around here, man”.

So what do we do about it? While I realize that bullet lists can be a bit reductive, this is a blog post and not my magnum opus. Here goes:

Use simple, repeatable processes to manage your work. Focus on process, not tools. Joe supports his own processes with index cards. No kidding.
Surround yourself with disciplined people; failing that, you must teach discipline. Teaching discipline takes time, and sometimes that wild mustang cannot be tamed. Not everyone gets to be an astronaut when they grow up.
The discipline with which you approach your work should lead you to the conclusion that this seemingly endless cacophonous stream of noise can be tamed, prioritized, and managed.
The requests are all some form of project that must be chunked out, prioritized, queued up, and delivered.
Within your span of control, you must work with your colleagues, customers, suppliers and other various stakeholders to continuously:

Plan and replan at least weekly
Communicate, communicate, communicate
Prioritize weekly
Deliver…and repeat…

…and try not to be too much of an ass when you do it because trust me, this will be revolutionary for about 95% of the people that you’ll encounter when you work like this.

Exactly what you do and how you do it and which tools you use to make this happen will all depend on your particular organization.

On the smaller end of the project scale, we have many minor efforts, which require a very lightweight approach. We try to ensure that the level of control and required processes scale to fit the need and the risk profile.

Just remember, hope is not a method. Good luck.

When advice misses the mark

2010-05-03T17:09:00.001-07:00

I read a short post called 4 Questions To Ask Before Starting Any Project by Ty Kiisel of @task this morning. By initial response was dismissive. I've read this same article in various forms and in various publications at least a dozen times in the last 10 years. The advice is generic. Whenever I hear it I have to ask, does the writer manage a portfolio of 100 projects? If not, the questions are simplistic. If so, then he misses the mark.

The questions Kiisel proposes are textbook project management Nirvana advice while most of us toil in Samsara. In the real word, complex projects have more that a simple list of considerations to consider. It is often that a mini-project is required simply to get approval for the bigger project.

Kiisel describes his desired outcome as optimized resource time. As in, let's make sure we don't waste time working on the wrong projects. The question that must be asked is missing. Read the list, do you see it?

What are the high-level objectives of the project?
What are the estimated costs of the project?
Does the potential project align with the mission, vision, and values of the organization?
What are the risks associated with pursuing the project under consideration?

With a finite pool of resources, the question to ask, the one that must be answered right at the start is, "What is the impact to other projects and our shared resources?"

Let's say we answer all four questions right up front and drop the project into the portfolio. If we don't know the potential damage to other projects, we are negligently interjecting risk, causing turmoil, and throwing a curve into the lives of our PMs and project resources. The executive team most know that if you approve project A, then project B slips two months and project C needs three new resources plus an increased budget. If your portfolio is a hundred projects, then the impact statement will be a white paper.

Consider the communication nightmare that will result once other projects are affected. Can you imagine what would happen if we failed to coordinated with affected stakeholders? They have the right to participate in the process too. You must include them up front, otherwise you pay the price later. It's portfolio management 101 and simply must be considered before a project is added to the portfolio or approved by executive managment.

We don't hear this advice often because it is hard work and difficult to do well. The other stuff, the big 4, we learn that in school or on the job. It's de rigueur for a good project manager. We learn to scope a project so that we know what to deliver. We learn to produce a budget and complete a ROI calculation so that we can secure funding. We learn about the buzzwords of mission, vision, and values so that our B School graduate leaders can understand and communicate the importance of the project. And most importantly, we learn about risk. As project managers we hate risk. We spend hours and hours on risk assessments and contingency planning. It's what we do. However, if we don't do the hard work of understanding and communicating the impact of a new project on the portfolio, the project and several other projects, are likely to fail.

Technorati Tags: Project Management,Risk

Chaos and Emergence

2010-05-02T14:46:00.000-07:00

In a previous post I explored my personal motivations for Enterprise 2.0. Here, I will give my perspective on the larger business and technological trends at play, and do my best to tie it back to a business case better for collaboration tools in the workplace.

During a staff meeting in April 2010, our president (my boss’s boss) had some comments at the end of my presentation – which at that meeting included a review of the different web conferencing and screen sharing tools available to users at my company.

Thanks; by the way, you’re going to have to sit down with me and explain all of these tools we have. You talk about Live Meeting, and that is great, but we have so many tools and systems and things to use and I just don’t understand it all. It’s chaos. You need to explain to me how this all fits together.

We introduced Microsoft Live Meeting in 2009 and hardly anyone is using it. It is supposed to supplant the old standby, Netmeeting (around since Windows 95). I went on and on about how much better Live Meeting is, and I pointed out that for those that still want to use Netmeeting (almost everyone…), it is still available.

So sure, Live Meeting is better than Netmeeting, but is it 9x better? That was the unspoken question on the lips of the 20 senior manufacturing executives and department heads in my audience. They were very polite as usual and did not throw any rotten fruit at me.

That story is illustrative of some larger themes:

Underutilization: We already have too many tools, and we don’t use enough of the capabilities of the tools that we have.
Proliferation: We introduce new tools, but the old ones rarely go away. It’s just something else to learn. It’s even hard for the IT people to keep up with it all, and it is our job to manage this stuff.
Complexity: New tools many times are more complex than old tools. They are more complex, and harder to use, even if they are more feature rich.
Complexity, Part Deux: More complex tools, when combined together, are creating a hairball of complexity. This geometrically-increasing complexity becomes less and less reactive to real-world situations. The French have a lovely expression to talk about complexity, “usine à gaz”. This picture illustrates that better than a direct translation.
Consumerization: Innovations are coming from outside of the corporate computing world, and corporate customers are slow to adopt their usage at work.
Incumbency Bias: Adoption of new technologies and new collaborative processes lags because of the incumbency bias of end users toward tools like email, as described very well by the 9x problem linked above.
Control Orientation of Corporate IT: We like to tell our users what to do and how to do it, where to put certain types of data, and we are quick to bring down the hammer on creative users that have solved problems in “inappropriate ways”. Susan Cramm’s blog is a great resource for the challenges currently facing IT departments.

Reading that list, I feel sorry for you, I feel sorry for my users, and many days, I feel sorry for myself.

So back to my president’s request. I would rather not explain to him the mess we currently find ourselves in. I do not think that I can. What I want to do is describe what my team has done as early adopters of Enterprise 2.0 concepts and tools, even though I am sure that we will not grok it on my first attempt.

I don’t have any magic red pills that can make my boss or others see reality the way that I do. However, I am starting with the premise that the current way of working is broken, and that the knot cannot be undone. I do not want to add another layer to this mess. I do not want to add wikis and blogs and communities and other social tools as extra tools where people go to collaborate after they are done doing real work with their email and desktop productivity software.

So…do we and will we use email? You bet; email is a nice notification engine and front end for posting new content or comments to our platform. Do we still use Microsoft Office? Of course; it’s hard to do a budget without Excel, but I can display an Excel file inside of a blog entry about monthly budget performance and have 40,000 users in my company get access to it through a browser.

Remember, this is about getting work done better than it’s getting done today in most places. I declare myself a strict Druckerian when it comes to social software in the workplace (thanks to Traction Software’s Greg Lloyd for that formulation; it’s brilliant).

This is all very much a work in process. It is emergent in every sense of the word, and I explored some specific applications in my post, Lightweight Something. It is not perfect and it is not without its own problems and dark sides.

Future posts will explore very real and practical aspects of what we are trying to accomplish. I suspect you will also see Joe chime in with his perspective, following up on his Using a Wiki at Work post from November 2009.

As for what exactly I’m going to tell the president, I’m still working on that…but I have a sense that showing will work better than telling.

Disengage from the team

2010-05-02T13:20:00.001-07:00

Spending social time with your team when they are not working is nice in small doses. Buying dinner or drinks at the hotel bar, that’s conduct expected, but it’s also where I draw the line. I spend a lot of time on the road managing IT projects. I’m often stuck in a hotel far from home along with my project team. Given the amount of time we spend together working on the project, and the amount of time we spend socializing after work, it is inconsiderate and selfish to extend socializing to cover the weekends. I know it gets lonely on the road. It seems natural to spend time with the people you know. Why not spend it with your team? My advice… don’t do it.

I learned this lesson the hard way. Ten years ago I caused an epic meltdown on my team by spending too much time with them on free weekends. When the meltdown happened, we were all sitting at an outdoor café after spending a Saturday touring Paris. One team member mentioned a problem, another chimed in with a snarky comment, a third appealed to me, I responded with my manager hat on, and then all hell broke loose. The meltdown was caused by stress, alcohol, and too much time together. The last thing they needed was to be reminded of the project. It took weeks to get the team got back to normal. We somehow managed to avoid becoming the entry of the week on Michael Krigsman’s IT Project Failures blog… barely.

People need time to recharge after a hard week at work. Give your team the freedom to recharge without your presence. Role power never fades. If you were the project manager on Friday, you’ll be the project manager on Sunday. Give the team its space, even if it means taking a trip to the museum alone. Make the sacrifice so that your team can relax. It will pay dividends in the end.

Technorati Tags: Project Management,Travel,Tips

The value of small

2010-04-27T21:43:00.001-07:00

I have a track record of pulling off difficult projects. I’m often asked what my secret is. New project managers want to crack my code. I give the information away freely. It’s not secret.

Rule 1 is simple. Do a small planning task repeatedly throughout the life of a project. The task must be something that moves the project forward, so a planning review to identify next actions is perfect. It must also be something that can be repeated. Keeping the duration short is important to repeatability. The key is to think of it as practice with an eye towards improving over time.

I’ll use a sports analogy here to illustrate my point. I play disc golf. In order to become a good player it is important to master putting. The concept is simple, stand 20 feet away from a pole hole and throw a specially designed disc into it (demo video). Good putting is defined as making 80% of your putts from 20 feet away. I practice putting 5 times a week. I throw over a hundred putts each practice session. It takes 15 minutes. After a year of practice, my percentage increased from 30% to 75%. I’m still working on hitting 80%.

Practice adds up:

I practice 5 times per week for 52 weeks, 15 minutes at a time. That’s 65 hours of practice. After 65 hours of intense focused practice, my putting improved dramatically.

I apply the same method to project management. Twice a week I review open deliverables to identify next actions. The process takes 20 minutes. I repeat the process each Monday and Thursday morning. I do it every week, week in, week out, until the project is finished. My follow-up percentage is near 90%. I rarely miss an issue.

Practice adds up:

I practice next action identification 2 times per week over the life of a project. Each session is 20 minutes. On a typical six-month project, I practice identifying next actions 14 hours per project. My method is deliberate and requires dedication and consistency. My identification rate is high.

What I tell new project managers who are willing to do the work is to emulate my method and gradually increase their follow up percentage through practice. How do they know their follow percentage is improving? I ask them to keep track.

Keeping track of misses is important. A miss is loosely defined as a missed deadline, failure to communicate a change in plans, a surprise, or an under/over utilized resource. When I encounter a miss, I note it for later review. When I have time, I follow-up to identify how I missed it during my 20 minute review. Over time I miss fewer issues, and so will you.

Technorati Tags: Project Management,Tips,Productivity

My Motivations For Enterprise 2.0

2010-04-22T21:06:00.001-07:00

Hopefully this provides a little more detail behind some ideas in an earlier post. Since I’m the boss, well, my motivations sort of become my team’s motivations, as long as I have the energy to see them through. Do I look like an authority figure?

I started my Enterprise 2.0 journey without really understanding my own underlying motivations. I always had the nagging feeling that managing the activities of a global group of 80+ in support of over 5,000 employees was something beyond the scope of our current toolset and mindset. Honestly, I just went for it. But now that I’ve been doing this for a while I felt it worthwhile to examine exactly why I believe that email + static intranets + network file shares just don’t work anymore.

Realizing that I lacked the vocabulary to explain myself, I read some well-regarded texts on the subject. Venkatesh Rao’s review on his ribbonfarm blog of Drive by Daniel Pink led me to check out the book from the library. Having finished Drive, its bibliography led me to Flow: The Psychology of Optimal Experience and Why We Do What We Do: Understanding Self Motivation. Along the way I had read Three Signs of a Miserable Job and The Power of Full Engagement.

Here’s what I learned, and learned about myself:

There are two kinds of motivation: intrinsic (coming from within) and extrinsic (coming from without).
Intrinsic motivation is much, much more powerful and sustaining
Once your basic needs are met, incremental extrinsic motivators (a lot more money, threat of sanction or punishment, etc) don’t help much. I’m not sure all of my colleagues would agree with that 100% , but I read about it in a book, so it must be true.
Autonomy, mastery, and connectedness are the main intrinsic motivators.
Engagement is tricky; as it turns out, we spend so much time at work that we cannot afford NOT to be engaged; but don’t look at someone else to motivate you to the point where you magically become engaged. That really has to come from within.
I’m most engaged when I’m getting stuff done without too much oversight or micromanagement, doing high quality work, and seeing how what I do and what my team does fits into the big picture.

So what does this have to do with anything?

Let’s look at the intrinsic motivators, starting with autonomy. I cannot imagine a more miserable situation than being told what to do and how to do it. But hey, I’m not everybody so perhaps I am in the minority here. My Myers-Briggs type is Introvert after all…

But autonomy does not mean alone.

Andrew McAfee's definition of Enterprise 2.0 mentions “emergent social software platforms”. I think that these tools support autonomy very well. They are not rigid; they are not prescriptive. They (should) allow some freedom in how work gets done depending on the situation. I like that. I really like that. That’s what I call autonomy. I suspect that many of you will argue that email can do some of this. Maybe this is your viewpoint of email:

I guess an email rant is out of scope for this message.

Next, let’s talk about connectedness. I could go on and on about how the existence of silos is just bad for business. Sure, we need centers of excellence and functional experts and all that…but if everyone is not working together, connected, you’re just not going to get high performance. We have outsourced, spread out, globalized, split-up, etc…but our management techniques and toolset have not kept pace. We still thrive in hierarchical, need to know cultures supported by cloistered information and antiquated supporting tools. I cannot tell you how many times I have seen decisions get stalled or made poorly because we could not connect the dots. Enough! So not only is being connected going to raise performance; as it turns out, it also motivates people.

Sounds like a win-win-win to me.

Others more eloquent than me have lots to say about this. I suggest checking out this post on Paula Thornton’s interview with Jordan Frank, Responsibility to Collaborate. You can listen for my name about halfway through…

I will be back on this channel showing some real world use cases. I also want to show off Joe’s work in managing our major projects; he is really kicking some serious butt. In the meantime, I’ll be smashing silos and collaborating and where necessary bossing people around so that they can be autonomous and connected; because in the end, they’ll thank me for it.

Post Project Reviews and Continuous Learning

2010-04-07T09:04:00.001-07:00

It is hard to believe the staggering success proclaimed by business professionals everywhere. Have you been to LinkedIn lately? Have you read the recommendations?

Apparently, the world is filled with Zen Master Jedi Guru Black-belts who have mastered every known methodology, development framework, software package, cultural issue, change management challenge, and supporting tool; all of their projects are on time and under budget, and all of their children are above average. These supreme beings have nothing but glowing references to prove it. Wait, I think I just spotted one:

Maybe that is all true and maybe I am the only manager that has experienced a less than optimal outcome at work. Here’s the truth. Some projects actually fail. Go read Michael Krigsman for some perspective on IT project failures. And even the ones that do not fail are rarely flawless. And the ones that you think are flawless? They are not.

In the past year or so Joe has helped me to drive a more disciplined project management approach in our organization. One practice that we are starting to use more and more is the post project review. We model our approach on kaizen techniques used by our manufacturing colleagues to solve operational problems. We were also inspired by after action reviews in the US military.

Very recently, we have used the technique after an internal audit (those are always fun) and after a server migration project. The internal audit example was interesting because this was not a project in the classical sense; however, the review process was very useful. And since we performed the review through our wiki/blog platform, it’s now online for tens of thousands to learn from. It won’t get that many hits but it has already been shared with dozens of colleagues throughout the company. And if we’re lucky, those same audit findings will never occur again. Avoiding future mistakes is what it is all about.

By the way, this process is not meant to be a love fest; it’s meant to solve actual problems.

Joe is much more capable of describing our technique in depth but I will try to do it justice:

Gather everyone involved in the project. If there are lots of stakeholders, you might need several meetings to accomplish this.
Focus on what went wrong or not quite right.
Everyone gets a chance to speak and give their perspective.
The moderator must elicit participation; trust me – some of your best material from some of your quietest people.
Do not focus only on technical problems and deliverables; communication, process, methodology, bureaucracy, working conditions – heck, anything is fair game for criticism.
Gather up your issues and try to distill them into separate problems that can be explored to root cause.
Explore the impact, temporary resolutions, root cause and future process corrective actions.
Assign actions and drive change. Learn!
Share your findings widely. It’s just good karma.

Here’s a sample issue from our server migration project. I’ll pick on myself here because I was assigned the action item:

Is this perfect? Not really. Is it better than pretending everything is fine? I think so. Should you use it in your project management processes? Up to you. Good luck!

Technorati Tags: Project Management,Continuous Learning

Helping team members improve relationships

2010-04-05T22:24:00.001-07:00

The post should be called helping project team members improve relationships by teaching them to change their own behaviors. But that’s too long to fit in the header.

I manage lots of projects. Each year, a few team members come to me with a common problem. They do not understand why their fellow team members hate them. The issue comes up as something like, “My peers leave me out of important conversations” or “My team members do not trust me.” or “My project manager always has <insert team member’s name here> check my work.” What they fail to realize is that it not what other people are doing that is the problem, it is what they are doing (or not doing), that is the real source of the problem.

I am not a relationship coach. I have trouble enough managing my own relationships so I do not try to help others manage theirs. It would not work anyway, in my experience, relationships are too complex to manage for other people. At best, what you can do is examine behaviors that contribute to mistrust, anger, or resentment.

I use a process that I’ve developed over the years through trial and error. Some techniques were taught to me by my original management mentor, some were lifted from books or podcasts, and some were developed through practical experience. The key concept is honesty. Looking at your relationships honestly is the hardest thing to teach. People simply do not want to look closely at their relationships. It is painful and can be humbling. It is much easier to say that “Ted does not like me.” However, if you want to improve your relationship with Ted, it is necessary to be honest.

The process I use calls for self reflection across three categories, peers, subordinates, and management. I ask, “How well do you get along with your peers, subordinates, and management?” The typical response is something like this, “My peers don’t trust me, my subordinates lie about deadlines, and management second guesses me.”

Keep in mind that you cannot really fix relationships, but you can change your own behaviors. This may seem counterintuitive, but it comes down to identifying what you can do to address the shortcomings you’ve identified in relationships with your peers, subordinates, and management. For example, to address “trust issues” with peers, one must identify behavioral changes you can make that will help build trust.

I used a simple tool to help identify problem relationships because people often do not give much thought to where they fit in on a team. I list up to 9 people across 3 categories. 9 is the magic number. More than 9 and you are overwhelmed; fewer and you are not challenged. The 9 people break down into the three categories, subordinates (4), peers (3), and management (2). To do this, make a grid with column headings: Target, Friend, Neutral, and Foe. List the subordinates, peers and management by first name in the first column under target.

Rate the status of your relationship with each person using the Friend/Foe/Neutral mode. Put a check mark in the box that correlates with the status of your relationship.

Friend – Actively supports

Foe – Actively works against

Neutral – Indifferent or passive

I ask that each group have a theme. For example, you may try to address “meeting commitments” with the subordinate group, “trust issues” with peers, and “perceived second guessing“ with project management.

Using the peer group as an example and trust as the theme, the question becomes, “does Bill trust me?” If the answer is yes, he is rated as a friend. If the answer is no, the he is rated as a foe. If the answer is uncertain, then he is rated as neutral.

The grid will end up looking something like this:

Target	Friend	Neutral	Foe
Subs
Carol	x
Ted		x
Alice		x
Ken			x
Peers
Bill		x
Ted		x
Etc…			x

The goal is to move everyone toward the friend column. How this is done is often difficult for people new to the process to understand. The focus must be on your behaviors and the specific reason your target is either neutral or a foe.

Let’s assume that Bill does not trust you. The behaviors you try to change are specifically focused on building trust. If you are honest, the result of your behavioral changes over time may be increased trust. To do this a team member must have a plan with discernable behavioral changes that will result in a positive change in the status of their relationships over time. Behavioral changes can be as simple as taking a peer to lunch once a month in an effort to build or repair a relationship or as complex as making an extra effort to acknowledge collaborative credit in meetings, or even ending gossip or holding a confidence. The behavioral changes must be specific.

I suggest as many as three behavioral changes be identified for each person in the foe category and one or two for each person in the neutral category. Continuing with Bill, the specific changes may be:

Lunch once a month to focus on building a better relationship or establishing a shared common connection.
Making sure to acknowledge Bill’s contribution in project review meetings
Making an effort to avoid gossiping about Bill’s activities.

This process is repeated for each person until each foe and neural person is addressed. When finished, actions should be scheduled across a three month calendar. If the plan calls for a monthly lunch with Bill, put it in your calendar. If the plan calls for acknowledging Bill’s contribution, add it to your PowerPoint check list. The key to success is converting the plan to actionable steps and then setting a time limit for implementing the specific behavioral changes. I normally set up a review once a quarter to go over the previous quarters plan and results. If necessary, the process is repeated.

This may seem like a simple process for mature self –aware professionals. I’ve gone through it with over 20 people in the last 10 years. In every case, it was the process of labeling a person friend or foe that prompted self reflection and then the realization that simple behavioral changes could influence the relationship. It’s simple, but it works.

I’m using this technique right now. I use a daily phone call to build a higher level of trust with a new employee . Each time we talk I am careful to ask how I can help them meet their objectives. When they identify something, I make a special effort to resolve it within 24 hours. It’s working well for me.

Technorati Tags: Project Management,Relationships

Lightweight Something

2010-04-03T12:02:00.001-07:00

Andy McAfee posted a thought-provoking article on Lightweight Workflow and how Enterprise 2.0 concepts and tools are perhaps going to make this more of a reality in 2010 and beyond. Perhaps even its own enterprise applications category.

What followed in the comments were some interesting takes on what this all means for life, the universe, and everything. While I don’t pretend to have lots of answers, my colleagues and I have been experimenting with these very concepts over the last year or so. Joe’s Using a wiki at work and my Crazy post give some background on our quest.

Anyway, there are obviously many folks out there with very insightful things to say. I added my own comment as a response to one left by Dan Keldsen – a well-reasoned and experienced voice on many subjects related to information management. Dan is challenging us (E2.0 mavens and practitioners) to get out there and just do it, just show the value how this can work in practice. I reprint the comment here just in case I’ll ever need it again for myself:

Dan - I love the comment here. In my own work life, I have tried in the last year or so to implement the "lightweight workflow" concept, or as Greg Lloyd also calls it, "lightweight coordination". There are real people in real companies trying to do what you describe. I'm one of them.

Practically speaking:
-There is a generic need to pose a problem or define some "thing" to be done
-The person who poses the problem or defines the thing, depending on the specific case, prescribes some steps or perhaps leaves it open ended.
-There is some systematic or programmatic way to define a open/closed, to do/done state, or maybe there isn't. Sometimes it doesn't matter.
-Colleagues (or heck, the Internet...) comment, modify, edit, add to, take away from, "approve" in some form. In my case, this is a wiki edit or a comment on a wiki/blog hypertext article
-The thing is done at some perhaps very arbitrary point when the defined process is consumed. The state is changed to closed or done.

This generic pattern I have applied with modest success in the following use cases:

-Project proposals
-Compliance testing
-SLA/contracts with internal customers
-Ad hoc surveys on various topics
-Project management deliverable tasks
-Wiki document collaboration
-Crowdsourcing meeting notes compilation

All of the above has been in the spirit of Cunningham's "what's the simplest thing that could possibly work"? None of the above required flow charts, modeling software, or heaven forbid armies of business analysts or programmers to implement. The workflow model is prescribed in a line or two of text, then I stand back and watch the coordination happen. Are there cases where this isn't adequate? For sure. But mostly, it just works.

It's been successful enough that the experiment will continue and I'll try to blog in some more detail later.

Alignment and Dunbar’s Number

2010-03-24T18:02:00.001-07:00

I have always been fascinated by Dunbar’s Number (and non-human primates). Basically, this concept states that the optimum size of a human group/organization is about 150 people. The number itself is derived from observation of primates, who need to:

…maintain personal contact with the other members of their social group, usually through grooming. Such social groups function as protective cliques within the physical groups in which the primates live. The number of social group members a primate can track appears to be limited by the volume of the neocortex region of their brain. This suggests that there is a species-specific index of the social group size, computable from the species' mean neocortex volume.

You know, like these baboons:

Apparently, human brain size makes us able to “keep track of” around 150 fellow homo sapiens.

There’s a lot of controversy about its applicability to human society and organization, but I would like to ask everyone for a second to think about this concept. How many people work for your company? How many of them do you know? How many do you know well? How many do you really trust? I think that this has some real implications for strategy and alignment, particularly for large organizations. Just to level-set everyone, I define alignment in a very broad sense meaning all parts of an organization working together to achieve common goals. It seems self-evident to me that the larger and more complex an organization, the harder it is to achieve true alignment. Still with me?

On one end of the spectrum we have a small organization called SimpleCorp. SimpleCorp is a small business with one building, an Owner/Operator that runs the business, a few managers, and a few worker bees. You could maybe even fit them all in the same room:

Don’t they look happy? And aligned?

On the other end of the spectrum you have MegaCorp. I work for MegaCorp. We have several thousand employees.

It is a fairly well-established fact that as organizations grow in size, alignment as I define it becomes quite difficult. If you have ever worked for a large organization, and many of us do, take some time to think about how many departments, locations, multi-location structures such as business units, corporate offices, etc are involved in making the company function. In this respect I am a bit of an acolyte of John Gall, who wrote the book Systemantics several years ago. His main thesis, which is a bit tongue in cheek, is that all systems, especially large systems, operate in failure mode.

So is it hopeless? How do we cope? How does that large organization achieve alignment? Probably not by grooming each other like baboons. As a coping mechanism, since ancient times we have implemented bureaucracy. One of the best representations of bureaucracy is the organization chart, which putatively describes how work gets done:

I am not soft-headed enough to believe that large companies should operate without bureaucracy and org charts. They are a fact of life. My team has one, and it actually has some merit. But what about how that org chart fits into the rest of the company? Hmmm. Not obvious.

In the absence of small groups of people that can truly know one another, thus developing bonds of trust and being naturally aligned, what shall we do? My small idea is to reduce the friction of knowing each other and working together. I know that my company as a whole (not just my team, department, business unit or other administrative groupings) is going to benefit if the way we work and the way we get things done resembles this:

Selfishly, I need to do things like implement collaboration tools such as wikis and blogs just for my relatively small team. What I’m hoping is that as this way of working spreads, it leads to greater opportunities for alignment throughout the company. We’ve been at it for well over a year, and while it’s not perfect, our efforts are paying off.

The only other thing I can think of is renting a ballroom so that we can all groom each other like baboons.

If Your Company Were a Body of Water…

2010-03-04T18:51:00.001-08:00

Would it look like this:

Or like this:

Perhaps it is all of the motivational / positive psychology / business literature I have read lately, but I am feeling really reflective right now about my corporation, my business, my team, and myself.

I don’t know about you, but sometimes I feel like the top picture more accurately describes the type of water I’m floating in. The metaphorical possibilities here are many. But the bottom one? Well, when that’s the water, those are really great, rewarding days.

The bottom picture is representative of my overall outlook when my team and my company are really functioning well – working in innovative new ways inside some of the Enterprise 2.0 (one definition, among many, but this is the guy that coined the term)tools and concepts we have deployed.

These are themes that I’ll explore in subsequent posts, hopefully laying a foundation for why I made this post back in December 2009 on why my team thinks I’m crazy:

Engagement
Motivation
Flow
Collaboration
Alignment

Once those posts are out, it should be obvious where I am coming from. In several posts I hope to provide some sort of cogent explanation as to why I am on a crusade to work differently, why it matters, and why it’s better than how we work now.

Expect to see references to, reviews of, and musings on the following books, articles, blogs and other media:

Thanks for your time.

In The Zone

2010-01-26T06:31:00.001-08:00

I cannot give you the depth of Project Management Jedi tips that my colleague Joe can. However, I do know a thing or two about meetings – particularly international meetings. If you are in charge of an international project or have any kind of management/coordination role in one, I have some tips to help schedule meetings across time zones. I posted this in our internal blog, and it was a big hit with some of our senior managers. Here we go.

Don’t forget: the world does not revolve around you

If a meeting is truly global, chances are that someone is going to be at home, on the way to or from work, or doing something else at the time that is probably best for you as a meeting organizer. So the first point is, show some empathy, and know that this problem exists right at the beginning.

I suggest that you and your team make this a part of your project planning process - WHEN, specifically, you will schedule meetings. And it probably helps to rotate the pain, if you know what I mean.

Productivity Tip: Use Outlook 2007’s Multiple Timezone Display

I am almost always interacting with colleagues and business partners in a different time zone. It sure does add some spice to life. Here are some screenshots that show how to enable your Outlook calendar (yes, this is a Microsoft-centric tip…). This assumes my home time is Los Angeles, CA USA, and I also want to see what time it is in China.

In your calendar, right-click on the times, add Add a timezone in addition to your standard Windows time zone. It should resemble this:

Here’s what Microsoft has to say about time zones, Outlook, and Exchange. Good luck with that.

Productivity Tip: Use a Web-Based Meeting Planner

http://www.timeanddate.com/worldclock/meeting.html

I've used a tool like this in the past. I think there are several. It would seem like it would be built into MS Outlook, but as far as I can tell you can only display two time zones simultaneously. There are lots of tools like this. This is one option. I like this meeting planner page because you can plug in multiple cities. In this example, I'll use Shanghai, Paris, Los Angeles, and New York.

As you can see in this example, it is always going to be between 10pm-6am for someone when these 4 time zones are involved. As I mentioned above, I highly recommend that you rotate your meeting time and don’t always force a very early or very late schedule for one of your cities.

And you know what? Perhaps it’s not always possible to find an elegant solution. But as a Project Manager, YOU need to bring this up in your planning process, acknowledge that an issue exists, and deal with it explicitly. Your colleagues will appreciate it. Trust me.

Thoughts on project kickoff meetings

2009-12-08T22:12:00.001-08:00

I read the Project Management Hut’s article on What to Include in Your Project Kickoff Presentation with interest today. I attended what I consider to be a good project kickoff meeting a few days ago. We met with our Chinese counterparts to discuss the implementation of an ERP system in China. The meeting was held via a video conference system, and for most of us, it was or first chance to meet each other in person. I found it interesting to compare what PMH recommended versus what we presented. To my relief, we covered most of the items listed in PMH’s article, with the exception of risks, which were covered with a different audience. What stood out was something that was not covered by the article, namely cultural considerations.

As an American project manager working on multi-national projects, I constantly encounter situations where failing to address cultural considerations causes projects to fail. There are common problems, like communicating in a language that everyone can understand, and complex problems like understanding how decisions are made. Without cultural considerations as an agenda item, the project is likely to encounter big problems. It may even fail.

Take communications for example. If language considerations are left out, difficulties will plague the project from the start. Something simple like deciding to translate all written material, is an issue that should be discussed before the project starts. Agreeing to translate written material is essential in a multi-national project. It is no small task to translate written material, but the benefits are enormous. Translating all written material requires foresight and planning. Having a translator as part of the project team helps. At a minimum, agreeing to a translation budget is mandatory. These items must be discussed up front, an additional agenda item called Language and Communications, will cover it.

Opting for the translation for all forms of project communication is desirable. After all, we want team members to understand what we are doing on the project. For email, another technique is desirable, using simplified English or its ugly cousin, plain English as the basis for email communications. For example, agreeing that emails are written in simplified English gives non-English speakers a much better chance at understanding the meaning of an email. A side benefit of using plain English is that your team leans to write better. Like in this example of plain English from the Plain English website.

Before

If there are any points on which you require explanation or further particulars we shall be glad to furnish such additional details as may be required by telephone.

After

If you have any questions, please phone.

Another area neglected in project kickoff meetings is discussing how decisions are made. In Chinese culture, reaching consensus is vitally important. A hard driving American style project managers will soon find their projects stuck in a sea of indecision. In every decision, each person’s wishes must be considered and discussed, even when picking a restaurant for dinner. Discussing how decisions are made during the kickoff meeting is a key consideration for assuring q project will succeed. Of course, if you are dealing with the French, reaching consensus is a lost cause.

It is also important that team members understand how failure will be addresses. American project managers think nothing of getting the team together to go over due dates, often renegotiating due dates on the spot. While this process is healthy and normal in most cases, in China pointing out one’s failures in a public setting will cause a loss of face which can cripple a project. If you take the time to address how failure will be addressed, like scheduling one-on-one meetings to discuss recover plans, team members will be spared the humiliation of losing face in front of their peers.

I can go on an on about cultural considerations, but other bloggers cover this in detail, so there no need. What is important is that we include cultural considerations as part of a project kickoff presentation. I cannot imagine starting a project without thoroughly addressing this subject.

Hello everyone! My Team Thinks I am Crazy

2009-12-08T05:38:00.001-08:00

My name is Brian Tullis, and I am going to be a contributor to this blog. I have the good fortune to work with this blog's owner and other contributor, Joe Crumpler. We both work for the same large manufacturing organization. I would like to think that where we work will not really matter here, and that what we'll be blogging about is of general interest to those inside and outside of manufacturing. If you care about topics such as project management, knowledge management, collaboration, international business, getting things done and using modern collaboration tools to help make it all happen - hopefully you'll find something here.

My perspective in all of this is as Director of Information Services for our Business Unit, but you won't find a lot of bits and bytes here. We're going to focus on people, culture, and business outcomes - hopefully showing how we're achieving positive change and getting things done using Enterprise 2.0. We'll share what doesn't work, too.

For my first post here on Next Things Next, I will continue a thought left by Joe on his post from November 29, 2009, titled, "Using a Wiki at Work". More specifically I would like to pick up on the very last paragraph there:

I look forward to the day when the wiki I help manage links the different factories that make up my business unit. As it stands, simply generating an awareness of each other below the executive level is a daunting task. One the requires persistence, patience and a bit of luck.

Me too! We have almost 30 operations within our 'empire'. There are huge collaboration, knowledge management, supply chain coordination, project management, and information access challenges that our IS organization is charged with helping to 'solve'. Some forward thinking members of our IS team recommended some options back in 2007 and within our IS group, we started using a wiki/blog platform help be the collaboration backbone of our company - whether our business partners wanted it or not...

And honestly, when we started on our journey using our Wiki/Blog platform, I thought that uptake and adoption would be pretty fast because it was so obviously better than any of the tools or platforms we were currently using. Wrong.

I have learned that if you build it, they won't come right away. You might have to drag some people kicking and screaming, and others you'll have to keep selling, showing, training, helping, and coaching. Maybe, just maybe then you'll have something valuable. In a sense, this is no different than any other change management effort.

I have learned that even within an IT organization - a relatively small one on the scale of many global companies at that - adopting new tools and techniques is not easy.

Back to the title of this post. When we started on this journey in late 2007 our IT team thought that this was just another place to put stuff. They didn't realize that we were changing the way that we work. After about a year, when I didn't let up, I am quite sure that there were rumblings among the troops that I had lost my mind. I was very aggressive in telling my colleagues to "put it in the wiki" or "don't email it, blog it!", and the like. I can assure you that the road to where we are today was quite bumpy. It continues to be bumpy. But it is a lot of fun. And it is worth it.

So here we are at the end of 2009 and while we are far from perfect we are really doing it. The Enterprise 2.0 way is graduating out of its incubator in the IT group, starting to spread to collaborative workspaces for senior management teams, exploration of problem solving/knowledge management platforms for engineering teams, and documentation wikis for our global finance resources. In future posts we'll explore some successful and less successful usage and adoption patterns. As Joe ended his last post, this will take "persistence, patience, and a bit of luck." Let's go!

Using a wiki at work

2009-11-29T12:07:00.001-08:00

Since I’m neck deep in deploying a wiki at work myself, I found it enlightening to read about other businesses' experiences doing the same thing. Wikis in the workplace: a practical introduction, offers a discussion of common misconceptions and problem encountered when companies like Webworks.com and Geometrica started implementing wikis. Even though the firms mentioned discussed knowledge worker based adoption issues, and I work in manufacturing, I found the article helpful.

Webworks.com discovered the truism that use of a wiki is only limited by those who use it.

Like standard websites before them, wikis have grown to be useful in any number of ways, and the potential of the wiki technology is only limited by the imagination of those who use it. But what makes a wiki so powerful for collaboration is that the "anyone can edit” capability means that the development of a wiki is typically driven by the community of people who use it, rather than being mandated and guided from on-high by a centralized IT or by company leadership.

While I find this truism accurate in some respects, I think the real story is that wiki adoption is limited by the computer skills of the user and their level of Web 2.0 maturity. In the case of a heavy manufacturing company, computer skills tend to be weak and most computer users possess limited knowledge of terms wiki or its associated growing pains. Adoption of a wiki in this environment is difficult. Innovation is practically impossible.

The article asks the question, “Are wikis secure?” It follows with an interesting discussion on Wikipedia’s open model and its well publicized content accuracy problems.

The "anyone can edit" philosophy that underpins most wiki implementations leads to the assumption that wikis are inherently insecure and open to vandalism, hacking, and other malicious behavior. This impression is reinforced by the all-too-frequent press reports about vandalism of various high-profile Wikipedia articles (the number of press reports being totally out of proportion to the actual number and frequency of attacks when compared with the actual number of pages on Wikipedia). The truth is that a wiki, like any other website, is as open or as secure as you want to make it.

Accuracy is less important than security in a corporate setting. In fact, in an environment where most users do not understand how content in Wikipedia is developed, addressing accuracy issues tends to be less important than addressing who can see a particular wiki page. Besides, once in use, wikis tend toward constant revision and are therefore accurate only to the point of last revision. People adapt and will fix inaccuracies if the environment permits. Security on the other hand, is vitally important.

The article touches on the trend in new wiki tools to provide a comprehensive security model but does not address the overhead required to administer the wiki if a complex model is adopted. Nor does it address the disconnect of a user based tool requiring oversight from the IT community. This approach tend to be a innovation killer. Experience tells me that security overhead is dramatically underestimated.

In my experience, one of the main causes of slow adoption is the fear of exposure to ones peers and the loss of control over ones ideas. In a workplace where 30-years of knowledge makes one uniquely valuable, moving ones knowledge to a wiki is a negotiated experience deeply dependant on assuring limited access to content. It is an anti Web 2.0 mindset, but a fact of life in many mature industries. Workers with unique product or process knowledge are slow adopters. A robust security model helps, but the problem is social and requires operational leadership.

Outward Bound International uses a wiki to build a community. it is a worthy goal.

Outward Bound International, the umbrella agency for the Outward Bound adventure training schools, used a wiki as a central part of their initiative to coordinate and share the resources and experience of 18 different Outward Bound entities around the globe.

Previously, each national entity acted as a separate unit with little awareness of how things worked in the other units. By sharing resources and information on a wiki, each national group could start to learn from each other. Duplication of process was eliminated, and the newer groups could learn from the more established groups, benefiting from their experience.

I must admit, this sounds good. I look forward to the day when the wiki I help manage links the different factories that make up my business unit. As it stands, simply generating an awareness of each other below the executive level is a daunting task. One the requires persistence, patience and a bit of luck.

Technorati Tags: Web 2.o,Wiki

Simple tools: Ta-da Lists

2009-11-25T16:43:00.000-08:00

I’m old-school when it comes to tools. I’ve used index cards as note taking tools for a long as I can remember. They are a reliable means of data capture but lack the immediacy of newer tools. And lately being able to communicate with my team while sitting in a meeting has become vitally important. If I need to capture a quick list of issues and communicate to my team, I use Ta-Da Lists.

Ta-da Lists are available via the web. I don’t need to lug my laptop around to every meeting I attend. A Blackberry or spare computer will suffice for updates.

Ta-da Lists can be shared with other people. Private access allows other users to see your list and check things off as the are completed. Public lists are viewable to anybody on the internet, but only the owner can update them.

Ta-da Lists are easy to update and maintain. The tool is simple to use and easy to understand. Making a new list takes only a few seconds. Updating a list is simple and intuitive.

Ta-da Lists have RSS feeds. Once a list is shared privately, a newsreader can be used to keep tabs on the results.

Ta-da Lists have a e-mail feature which supports moving lists from the web interface to your inbox. I don’t use this much, but it is handy.

Practical Application

Each month I sit in four meetings. They range from two hours to six hours in duration. I often participate in dozens of discussions during these lengthy sessions. I use Ta-da List to track major discussions and share specific action items with my larger team. I find Ta-da List a more efficient method for capturing small tasks than an email, note cards, or a notebook. For example, under the topic of User Issues I post a few quick notes on a private list that is open to my team. They know to watch the list.

User Issues

User reports slowness in the evenings at factory x
Manager wants 4 additional workstations at factory y
Boss needs to prep for call from VP on funding issue

This may seem simple, but its simplicity is its power. Instead of writing three emails and thinking about what I need to say, who it goes to, and what I want done, I simply wrote three sentences on a list available to to my team. I trust that the professionals on my team can interpret my notes and take the appropriate action. They see the entry and take action. Before long the person who manages SPC systems has ordered four new workstations and kicked off a PO for secondary equipment. If I check my email, I’ll find a status report. When finished, my team member checks off the item as complete. In my view it moves from the open list to the closed list.

I take time to collect my thoughts after these long meetings. Ta-da List helps me capture the meeting’s major themes and prompts me to take action on things that have not moved to “done” status. When finished, I delete the list and start over for the next meeting.

I don’t consider Ta-da List a good project management tool. I think of it as a good specialty tool. Something that makes simple task gathering and communication an easier core. Give it a try and let me know what you think.

Technorati Tags: Ta-da List,Tools,Tips

What’s in a name?

2009-11-25T13:30:00.001-08:00

I asked a close friend what I should name this blog. It did not take long for him to replay with Next Things Next, or as he wrote it, nextthingsnext. He said, “That’s you. That’s how you manage projects.” He was dead on. He knows me well.

I manage complex technical projects as part of my duties working for a Fortune 100 company. My experiences range from building up an IT infrastructure for a new manufacturing facility in China to installing BaaN in France and ORACLE in Mexico. I’ve recently managed the integration of two new businesses while replacing their manufacturing systems with QAD and ORACLE. In the process I started to experiment with Web 2.0 tools in an effort to turn project managed into a more social experience. I’m meeting with some success.

I’m currently using an internal project wiki as a key communication and knowledge transfer tool on a new multinational ERP software project. I find the challenge invigoration.

I presented a case study to a small audience at KMworld 2009 in San Jose. I was encouraged by some of the people who saw me speak to start writing about my experiences of trying to merge Web 2.o tools and project management. So… here we go.

Next Things Next

In the trenches with Traction Teampage

Your journal is your life

Picking Up The Trash

What’s the Vis?

Social Software For Business Performance – Some Perspective

Everything Is A Project, Part 2

Naming everything

Sensemaking For My Team, My Customers, and Me

Narrating your work

On becoming a community manager

The risk of exposure in Observable Work

TUG 2010 / Observable Workshop Notes

Definition and Core Patterns

Onward to Santa Clara and Beyond

Tips – The Monday habit

Gathering My Thoughts On Observable Work

Why Observable Work?

What Does It All Mean?

Soft Skills

Going Forward

E20 Santa Clara: Patterns of Observable Work

Why

What

How

People Patterns

Technology Patterns

Process Patterns

What does “done” look like?

Enterprise 2.0 and Observable Work: Recap and Speaker Notes

Observable Work - Catalyst 2010 Presentation

Observable Work: The Taming of the Flow

Deliberate learning

Everything is a Project

When advice misses the mark

Chaos and Emergence

Disengage from the team

The value of small

Practice adds up:

Practice adds up:

My Motivations For Enterprise 2.0

Post Project Reviews and Continuous Learning

Helping team members improve relationships

Lightweight Something

Alignment and Dunbar’s Number

If Your Company Were a Body of Water…

In The Zone

Don’t forget: the world does not revolve around you

Productivity Tip: Use Outlook 2007’s Multiple Timezone Display

Productivity Tip: Use a Web-Based Meeting Planner

Thoughts on project kickoff meetings

Before

After

Hello everyone! My Team Thinks I am Crazy

Using a wiki at work

Related articles

Simple tools: Ta-da Lists

Practical Application

What’s in a name?