Image courtesy of the Oakland Public Library

Blind wandering is the kind of thing that happens when you don’t have a plan, even a short-term plan, like the two-week sprints that are often the norm in Agile shops. Krulwich reports that we are somehow constitutionally incapable of sticking to a straight line if we can’t see a major landmark such as a mountain top, or a celestial marker like the sun or moon. Researchers have yet to determine why this is. They’ve run repeated tests, and the results are consistent. Left to our own devices, it turns out that we spiral back to our starting point.

Needless to say, from a project management perspective, this is no way to get work done. Of course, it is true that many good project plans are not strictly linear, or perhaps more accurately, not single-path-linear. Indeed, the more complex the project, the more parallel paths are required between beginning and completion. Usually, in software and interface design development, there is even an iterative loop (or two or three) along the way.

But I think we do have landmarks, in effect. These would be the milestones on a waterfall project plan, and the sprint backlog in the agile world. I’m calling them landmarks, because they are the pointers that keep us going in a forward direction, even if the path has some twists and turns.

Let me say that I have experienced group processes without landmarks: ones in which the participants go over and over the same material, making and un-making the same decisions. It can be tremendously unpleasant, not to mention costly. Perhaps you recognize this shapeless landscape too. Now we know that it’s our nature to act this way, and unless we intervene and impose some mountains (or celestial orbs) we will wander back to the beginning, again and again. It’s clear that having (and using) even a simple plan with high level milestones is far better than having no plan at all.

A post-mortem is generally conducted at the end of the entire project, but it is also useful at the end of each phase of a multi-phase project. The agile development method uses a brief post-mortem at the end of each short phase or “sprint” to improve the success of the next sprint.

An honest post-mortem takes a certain amount of trust among the project team members, so you’ll want to work throughout the project to ensure that people’s concerns are heard and they feel they are owners of the project success.

9 Steps for Holding a Successful Post-Mortem

1. Ensure the project post-mortem is listed as a task on your project plan. When you review the project plan with the team at the beginning of the project, explain the concept so everyone knows what to expect at the end.
2. Think about the outcomes of a successful post-mortem and work backwards to plan the meeting. Who should be invited? What are the “rules of engagement?” How will the results be used?
3. Develop a set of possible questions as a guideline. These questions might refer to different phases of the project or different topic areas such as communication, planning, vendor management, or user feedback. Reading these questions gives participants a structure to help them think through the issues they want to bring up, so no key project areas are missed. See these Project Post-Mortem Review Questions.
4. Engage a facilitator and a scribe if possible. Especially for a large project, this provides a neutral presence so that everyone is on equal footing and in the same role as a participant.
5. Invite the participants. Remind them of the purpose of the post-mortem and send the questions in advance. The goal is to make everyone feel comfortable, so provide enough information beforehand so participants know what to expect.
6. State the “rules of engagement” either in your invitation or at the outset of the meeting. The goal is to maintain trust throughout the exercise; you may want to change these guidelines based on how well the team has worked together throughout the project. Sample guidelines:

• We all understand that the goal is improving the next project, so we’ll try to be as honest as we can.
• Everyone gets a chance to talk and all perceptions are equally valuable.
• Respectful listening is key. This is not the place for rebuttal or push-back.
• We’ll start each discussion section with “what went well” before we analyze what we could do better next time.

7. Conduct the post-mortem. Make sure the room is comfortable and that participants won’t be disturbed. If possible, ask them not to multi-task or use laptops during the process, so everyone is equally engaged. Make sure you have flip charts and pens (or the high tech equivalent) to record key concepts.
8. Compile the report. It’s helpful to have a summary section where you discuss the process, share major findings, and list the lessons the team can apply to the next project. In the appendix, you can share the details. Be sure to send all the participants a draft of the report to make sure their ideas were heard. Once the report is final, store it in a place that is easily accessible to everyone.
9. Share the “lessons learned” with your organization. This kind of sharing helps all the project teams to do a better job — to learn from your successes and avoid some of your missteps.

“A project is complete when it starts working for you, rather than you working for it.” — Scott Allen

Now It’s Your Turn

1. Read more about conducting a successful post-mortem:

• Conducting Effective Post-Mortem Meetings (Part 1 of 2)
• Conducting Effective Post-Mortem Meetings (Part 2 of 2)
• Looking Back, Looking Ahead (The Project Retrospective)

2. Ensure you’ve included a post-mortem in your current project plan.

3. Go back to the notes from your last project. What were the lessons learned? What can you apply to your next project? This is particularly valuable for software upgrades, since the lessons from the last upgrade may be directly applicable to the next upgrade.

Read more posts from Your Life@Work.

This was an epiphany to me. Everyone on the team needs to understand the goal of the project in simple terms so they can care and be energized. Until this time, I had always insisted on stating clear goals for projects, but I hadn’t gone this extra step and distilled the goal to its essence for the benefit of the team.

A project objective statement should be:

• SMART (specific, measurable, agreed-upon, realistic, time-based)
• Short (25 words or less)
• Energizing (simple, easy to remember)

Here’s an example of a good project objective statement:

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.“— President Kennedy, May 25, 1961

The goal (highlighted in bold text) is nineteen words. It’s memorable and audacious, and it inspired a nation.

On the other hand, here’s an example of a weak project objective statement:

“We will demonstrate the viability of the test system to produce increased outputs with minimal effort, thus reducing our dependency on the existing system.”

The goal is vague and overly complex. Are you inspired — or asleep? This is a bit of an exaggeration, but unfortunately many project goals read like this. The only thing this goal has going for it is it’s fewer than twenty-five words. Worse yet, it would likely be the preamble of a much lengthier and arcane goal statement.

Don’t let this happen to your project. Whether you are the project manager or a team member, insist on a brief energizing goal for your next project.

photo credit: NASA/courtesy of nasaimages.org

Read more posts from Your Life@Work.

These questions came up at a meeting here. Some felt that bringing certain projects to successful conclusion was, indeed, heroic. They thought it took special determination, that something had been saved by the project manager’s actions. It might have been the team’s reputation, or the organization’s resources, or a deliverable that another team was depending upon.

Others believed that, if heroics were called for, then the project manager had not been doing a good job in the first place. These folks expected good project management to result in regular schedules, adrenaline-free Fridays, and a basic lack of unforeseen circumstances. No silver capes required.

I don’t think things are quite this cut and dried, myself. Project managers don’t always have the luxury of starting from scratch, picking a dream team, or even picking the team at all. Sometimes, the project manager joins the project mid-stream, or even toward the end. Depending on the state of affairs left by the previous project manager, the new guy or gal may not have such a good set of maps from which to start working. That means getting a handle on the project, managing the team, and delivering the service or product is an uphill battle. If that person helps the team succeed, is he or she a hero? Or simply doing a good job?

Let’s think too about the loneliness of the long-distance project manager. When I started that sentence, I intended it to be about the project manager tackling a multi-year project, the kind of thing that requires a sustaining of momentum through institutional budget cycles, staff turnover, software upgrades, and more. But it seems to me that it also applies to the project manager who is located in one city while the project team is located in at least one other place. There is energy expended to sustain momentum there as well, and there is a multiplier factor when the distance is greater than two timezones away.

You begin to get a sense that “doing a good job” in project management is actually a shifting notion, and something that’s gotten quite a bit more complicated in the last ten or fifteen years, with the increasing speed of software development changes and the ever-widening geographic scope of project teams.

In a world where a librarian can become an action figure, maybe it’s time to revisit what it means to be a hero.

Since then, I’ve been thinking more about patterns in the kind of work we do, and I think there are several different ways that patterns enable inventiveness.

Patterns can act like building blocks upon which, or from which, we create something entirely new. An example of this is modular or component development, such as the Merritt Micro Services launched recently by CDL’s UC3 team. These are discrete services that can stand alone or plug in together to create exactly the curation system needed for a local solution. The UC3 components are open and can also interface with components created by other developers, and so, in this very real way, they are a basis for innovation.

Image courtesy of the Allis-Chalmers (Oxnard Plant) Archives, Oxnard Public Library Photograph Collection

In a slightly altered manner, patterned processes can also enable innovation. That is, by codifying some procedures and techniques, it’s possible to analyze work flows, which can then lead (sometimes) to innovations in the way work gets done. It can also (sometimes) free up resources. This kind of work has to be undertaken by those who truly understand the domain, or the results can be counter productive.

An example of this kind of process analysis is work that the Next Generation Technical Services Task Force groups have been considering. Their collective charge has been, in effect, to look for places in the UC Libraries’ technical services where common and repeatable processes can be done once and not 10 times, so that scarce resources can be allocated to the special and innovative work that wouldn’t otherwise be possible.

In this case, there is a double dose of creativity. The solutions being proposed are, in many cases, innovative. And, if they are adopted, and succeed, then they will release resources for other creative work.

In project management, we use patterns too. When assessing risk, we are looking out at the road ahead and identifying patterns we’ve seen before, hoping to avoid the potholes. When we use proven techniques and templates, we hope to capitalize on knowledge we’ve gained through experience, freeing ourselves to focus on unusual situations that may arise.

The trick in using patterns, and this is as true in the world of design as it is in the world of project management, is to know when to apply the rule and when to depart from it. You have to know when to adapt, to look around and see that the place you’re in is a specific place that demands creativity from you and offers you the promise of new discoveries.

In this third installment in our series on the power of visuals, we’ll dive deeper into using visuals specifically for strategic planning. The real challenge is not creating the infographic chart; it’s making sure your strategic plan has all the right elements to keep you focused.  First, let’s consider why a visual representation of your strategic plan is worth the effort.

Why Is A Visual Strategic Plan Good?

• Clarity. Creating a visual map of your strategic plan offers another way to ensure your plan makes sense. I was surprised by how many questions I had about Leslie’s and my blog marketing plan when I was translating it into a visual.  It’s better to clarify your plan sooner rather than later.
• Quick reference. Your chart is basically a cheat-sheet to your plan; it’s everything you need to know in one easy-to-print 8 1/2 by 11 inch sheet of standard letter-size paper.  Making it easy to print makes it more useful — you can pin it on your bulletin board or keep it in a project folder for quick reference.
• Easy to show relationships. A written strategic plan with hierarchical numbering can be daunting to read with its jumble of numbers, letters, and roman numerals. It’s often more difficult to show the various connections among the goals, objectives, strategies and tactics.

Leslie and I were impressed with Ben McConnell’s one-page strategic plan infographic on the Church of the Customer Blog. It inspired us to create a strategic plan infographic for Your Life@Work so we could try out this visualization technique (see below).  For simplicity’s sake, our chart has only one objective and one strategy for each goal.

Here’s how to build your own chart:

• First row: Goals. List your top goals for the period — no more than five goals and three is better — across the top of the page (e.g., “Attract more readers”).
• Second row: Objectives. Position your objectives under the first row to match them with the appropriate goal (“1% of readers comment”).
• Third row: Strategies. Detail the strategies you’ll use  to reach those objectives (“Encourage readers to comment”).
• Fourth row: Tactics. List your tactics to implement those strategies (“Publish our email address on our posts”).
• Draw arrows to connect everything (e.g., match objectives to their goal and strategies with their objectives).

Finally, don’t let your lack of Adobe Illustrator or other specialized design software stop you.  Many commonly-available software packages have easy-to-use drawing tools including Microsoft Word and PowerPoint.  Moreover, a simple hand-drawn chart is just as effective — and it might even be more compelling.

Goals vs. Objectives and Strategies vs. Tactics – What’s The Difference?

You may have noticed that our marketing plan chart (above) has goals at the top while the Church of the Customer example has objectives at the top. Your plan will not implode if you call a goal an objective or vice versa. The important point is to have a desired outcome that you are seeking and to outline the progressive steps that will get you there.  Before you get started, reach an agreement with your team about which terms you will use and how you will define them — it’s vital to your plan.

Do I Really Need All Four?

Our impulse is often to set a goal and jump right to tactics (the detailed “how” part of executing the plan). So? We miss the chance to consider several possible strategies; more importantly, we neglect to state a measurable objective (asking “what does success look like” to develop a desired outcome.) For more on defining desired outcomes, see our post on Envisioning Successful Outcomes. Bottom line: You will have a stronger plan if you cover all four bases — goals, objectives, strategies, and tactics.

“Setting a goal is not the main thing. It is deciding how you will go about achieving it and staying with that plan.” — Tom Landry

Now, It’s Your Turn

1. Find out more about Ben McConnell’s Church of the Customer one-page strategic plan infographic (link above) and read his previous post on defining goal, objective, strategy, and tactic and why it’s important to agree what they mean.

2. If you have a strategic plan, turn it into a visual infographic (see instructions above) and share it with your team.

3. Read this brief article on strategy vs. tactics from BrandInsightBlog.

4. For more tips on using visuals, see our previous posts: Use the Power of Visuals to Get Your Point Across and Going Beyond Pie Charts: More Ways to Use Visuals.

Read more posts from Your Life@Work.

But, I do think there is one project “back door” through which perfectionism rears its perfectly coiffed head. And that is the delicate situation, common in smaller shops, where the project manager is playing two roles on the project: project manager and also key participant.

Image courtesy of the Riverside Public Library, Citrus Label Collection

With the participant hat on, the temptation to put in “just one more feature” means that the project manager him or herself becomes a stealth-like source of scope creep. What’s especially pernicious is that the suggestions for new (out-of-scope) features come out of the mouth of the person who is supposedly guarding against this very thing!

In June, my colleague Leslie Wolf wrote about how damaging the pursuit of perfection can be. Leslie pinpointed these problem areas in the professional realm:

• loss of efficiency,
• loss of effectiveness,
• procrastination,
• inability to see the big picture, and
• allocation of attention to nonexistent problems.

When the perfectionist is driving a project team, several of these problems turn into serious sources of scope creep. The temptation is great to look for new areas to improve, new things to add, even new issues to resolve.

Having the project manager caught up in “chasing the dream” can lead to real consequences for the project in question: patron or customer disengagement (or worse), stakeholder irritation (or worse), and team morale degradation. If the project manager doesn’t wake up and assess the situation objectively, the project sponsor will need to intervene for the good of the project. In some cases, the sponsor’s attention is sufficient to prompt the necessary assessment.

If push comes to shove, the drastic measure is to force a break up of those two roles. In other words, the perfectionist may need to give up either the project manager or project participant role. If you think that you can’t afford this division of labor, consider the alternatives listed above. Can you afford to let the project and its stakeholders suffer?

I think this is a great asset. It enables you to approach the task of adjusting your priorities and negotiating the scope with energy and enthusiasm, which you can communicate to your team. Absent this characteristic, you have to spend precious time adjusting your own expectations while the rest of the team wonders what to do. This adversely affects morale, which is of course the last thing you need heading into a shortened work program.

Image courtesy of Eastman's Originals Collection, Group 119, University of California, Davis.

I’ve written before about serving on a task force about project management skills, once regarding time management and once in connection with skills training.  I noticed, while working on our final report, that even though we had covered all the basic and even the advanced skills and techniques, we did not address this kind of inner drive.

I don’t really see much about this topic generally in the project management community. We talk and write a lot about process, and order, charts, time-frames, and inter-dependencies. But what about the juice, the spark that gets us across the finish line, especially when it’s been moved?

I think this is one reason why Agile has grabbed so much of our attention: it’s the idea of the sprint itself. I’ve worked with this model, and I have found that the 30-day rhythm , even when artificially imposed, can be an exhilarating challenge.

It’s always been the case that schedules get upended. But when budgets are as tight as they are now, and senior management is asking for transformation, not just revision, hairpin turns are more common in the project roadway.  To put it another way: you could say we are living through a new kind of environmental risk factor.

I’m arguing that the person who brings to that reality his or her own reservoir of energy is ahead of someone who is just applying good project management principles. What do you think?

DataCite Member Countries

Our task has been to complete the work on a Metadata Kernel document to prepare it for community comment in August and early September.

Fortunately for me, I have the able assistance of a Swiss DataCite member librarian. She and I meet weekly on Thursdays. It’s late afternoon for her and very early in the morning for me. We use Adobe Connect, a service hosted by the German National Library of Science and Technology (TIB) on behalf of DataCite. Most of the time, this works really well for us, although I have been known to appear inadvertently as an alien avatar from time to time.

In order to move the work along, I split the Metadata Kernel document into pieces and turned these into wiki-based documents, so that they could be worked on asynchronously. Meanwhile, I encouraged the members of the Working Group to form subgroups and “adopt” a portion of the document for authoring or revision. I did this because I felt that our efforts to coordinate large group teleconferences had not been very successful prior to the Hannover meeting. I had hoped that smaller teams with less of a geographic stretch might succeed in a shorter time-frame.

The heightened schedule was formed by a start date beginning in mid-June, and something my Swiss colleague warned me about when we returned from Hannover: virtually all the Europeans (herself excepted) would be going on vacation for the month of August.

Here are a few things I’ve picked up as the weeks have zoomed by:

• Information exchanges between California and Continental Europe have a one-way trip of one day, meaning that joint decisions take at least two days.
• It’s helpful to watch all the wiki pages. It gives me an idea about which sub-groups are active or inactive, and that lets me know when to send reminders and encouragements.
• I asked the TIB to install a group calendar plug-in, and then I asked the members to indicate planned absences of longer than one week. This has helped me keep those long upcoming vacations in mind as I choreograph the due dates of various pieces of work.

I’m certain I have more to learn about this process, and I have the best teachers: my colleagues on the DataCite Metadata Working Group.

In practice, like any other organization, we have limited bandwidth for puttering with tools, so teams tend to piggyback on the experimentation of others. Two tools for bug tracking are currently used most widely: Trac and RedMine. So naturally my project team looked most closely at these. They are both free open-source solutions that have been stable for about 4 years.

Image courtesy of San Diego State University; © 2009 Lee Passmore Family

There are, of course, many other bug tracking solutions. There are even many other free open source bug tracking solutions. Bug tracking is the kind of itch that lots of people think they can scratch better than the next guy. The kinds of features that developers and managers find especially helpful include:

• email integration–so that people don’t have to go to the tracker unless it’s absolutely necessary.
• access control–the more nuanced the permission structure, the better.
• custom fields–the opportunity to make the tool conform to your organization’s use, and not the other way around.
• reports–what some people call “dynamic documentation.” Also important is the ability to sort by custom fields.
• customizable workflows–fancier tools allow for ticket routing choices, reminders, escalations, and vacation or time-away re-routing.
• integration with the version control system of choice.

Other considerations might be internationalization (Unicode support), the difference between a hosted or installed solution, and what costs might masked by the label “free open source” tool. That is to say, when is free not so free? I recall Karen Schneider highlighting that question a few years ago at Code4Lib by putting up a slide showing free cats vs. free beer. (I see she’s been talking about it again more recently.)

A final factor may have more influence than many of the others, and that is the weight of inertia: the sheer reluctance to allocate precious project time to converting from one tool to another. Even though there are often automated ways to migrate tickets from some systems to another, many of us dislike this process.

So, I was surprised by the response I got at a recent demo of RedMine to a group of Trac users. The main thrust was that RedMine did everything Trac did, and then some. They liked the Gantt chart and calendar views that come with RedMine, for example. And, we are in the process of adopting Mercurial source control management software as a standard tool, and RedMine has native support for this, whereas Trac support requires a plug-in.

The bottom line is that it looks like some Trac-to-RedMine conversions are in the offing, and my team is adopting RedMine. Perhaps we will move toward a defacto standard after all!