From the Founder

We're all too busy, with long lists to accomplish every day, so many things that clamor for our attention. How do we know we're getting results vs. just lots of effort? Do we ever step back from our to-do lists, our task lists, our action item lists, our tools, and ask ourselves: Are we focusing on the things that will really matter to the success of this project? I am feeling crotchety about this subject, and sometimes I like to make bold opinionated statements for effect—to wake myself and others up, and shake ourselves out of blind acceptance of sub-optimal situations. So…

I maintain that we do not give ourselves enough time to think. About anything.

Our days at work on our projects can be one uninterrupted flit from place to place, an unending skim of the surface. Oh, I guess we get lots done. But did we get it done well? Did we design a product that hangs together? Did we come up with a truly extensible architecture for that system? Did we really think through all the potential customers and meet their needs? Did we catch all the dependencies on the project? Did we catch all the cross-implications of the decisions someone just made on their particular deliverable? Overall, did we allow enough time for true creative thought plus sufficient synthesizing, to take in every aspect of the challenge at hand and find subtle issues way before they have time to really bite us? I know we don't, from what I experience, the stories others tell me about the things that unexpectedly go wrong on projects.

So my focus in this newsletter is on knowing where our time and attention are really going, and whether we're truly achieving high-quality "thinking time"—specifically via how we plan out parallel work, manage the time of our collective organization, do meaningful reviews, go to new depths on risk assessment, and make sure to include time for personal learning.

Featured Article

Kollaboration is Killing Me!
Another noggin' floggin' by Kimberly M. Wiefling, M.S.

Each New Year's Day I choose a theme to guide and inspire me throughout the year, or at least distract me from whatever ills are plaguing the planet (most recently the "doom and gloom" economy). When January 1 rolled around last time, I was still swooning from the aftereffects of reading Wikinomics: How Mass Collaboration Changes Everything, Don Tapscott's spellbinding book. As a result, I chose "Wacky for Wikis and Crazy for Collaboration" as my theme for 2009. (If you've read my previous ProjectConnections article on this topic, you'll notice that my views in this article have become slightly more tarnished than last time, based on the past year's experience.)

Alas, after a year of what I'm now calling "the collective consciousness conspiracy experiment," I can honestly say, "Kollaboration is killing me!" If you are struggling to harness the hydra of the group genius in your project team, I'm sure you'll be able to relate to some of what I've experienced with these three wiki experiments. It's just a tad painful, but press on if you're curious. Kimberly's lessons learned »

Want to hear from Kimberly in person? She's in Japan again this week and next, where even her iPhone is scrappily jetting about the island. Once she wraps up her Global Leader Development programs there, she's heading home for the holidays. You can keep track of her globetrotting schedule on her website.

Executive View

Spending Time on What Really Matters, Part 1
Giving Ourselves Time to Think, by Cinda Voegtli

Again I say—we do not give ourselves enough time to think! I met an exec at a conference who asked me what I liked about running a business. The first thing that came to mind is "it's creative in all kinds of unexpected ways." But he caught me on a good day, a day when I had time for creative thought, because I was off at a conference with my phone off. My most frustrating times are when so many things are flying around that I'm back in flit mode and creativity feels very far away. And along with the creativity, I also lose the focus I firmly believe we need for sound assessments and problem solving.

Team members complain about lack of thinking time too. Developers need enough time in the schedule to work on complex architectural issues. Instead, how often do they get, "oh, we can spare x weeks for you to work on the architecture for the new platform." Some teams have told me they don't get explicit architecture time at all. Support people can't get free from operational work long enough to contribute to design reviews in a thoughtful, thorough way. And on it goes.

I know directors and VPs who recognize that neither they nor their people have time to really think. Meeting after meeting, email after email… We have to get everything done, coordinate, make sure we're communicating! But they admit to a nagging feeling that something is being missed, a better solution might be a few hours of deep thought away, a new leverage point is just under that surface we never have time to break, a nasty dependency is hiding an hour or so of systematic thought away. They wistfully talk about how great it would be to sit down and really get to think through a strategy, a design, a problem, an upcoming review, development plans for their staff…

Wait a minute, you say… They're the executives; can't they decide to fix the problem? Yes, I think they can, but there's generally a business-driven mindset—plenty of pressure, a complex organization, and a bunch of good intentions at work every time—so fixing this problem is not simple. I believe it takes a combination of "impact awareness," honest acknowledgment of how much we are and aren't getting done when we take on lots in parallel, collaboration to come up with workable solutions, and constant vigilance to stay on track.

To read the rest of my thoughts on thinking time, including some techniques to combat the lack of it, click to the blog page.

PLUS: Below I've also pulled together additional resources on the site on this theme of what really matters most for the success of a project, specifically in the area of "thinking."

Site Highlights

Burning Questions

Q: We identified the risk and worked hard on mitigation actions, but now we've hit the target mitigation date and the problem still hasn't been solved.

A: The first step is to immediately try to learn from this experience: why was there a surprise right at the target date and not before? The point of a mitigation plan is to define a path for addressing the issue and monitoring progress all along the way. So for next time, consider whether there should have been interim checkpoints in the mitigation plan to assess progress, rather than assuming the mitigation plan would automatically work, or simply assuming that the functional group handling the risk would let you know when it was done. Given where the project is now—with an outstanding risk that hasn't been resolved by the target date—what's next?

Q: Should I spend a lot of time developing an early detailed schedule?

A: This question has many elements: Who is developing the schedule input? What is the right level of detail? We've all heard statistics indicating that lack of planning is one of the biggest causes of project issues, but are there issues with doing too planning much too soon? ProjectConnections founder Cinda Voegtli once said: "I'm still amazed that there are groups out there that let the project manager do detailed scheduling, then expect any team member to be committed to that schedule. I'm all for the planning, and I favor the workshop approach...."

From the Blogs

Niel Nickolaisen ponders why other people assume the worst about our projects, and who should get to decide your project's communication approach, in order to ward off fear-induced angst and suspicion-driven productivity hits.

Cinda Voegtli shares what she thinks makes the difference for being trusted by our customers, stakeholders, and reward-deciding bosses, based on how we well we "serve them" through our project work.

Alfonso Bucero explains why the responsibility is on us as project managers to truly get along with all our team members, as a prerequisite to being able to lead them—and what that means in very specific (and possibly unexpected) detail.

Kent McDonald wants us to make sure we identify who really has the extreme interest in your project and the implications: What should you depend on them for? (Or not!) Plus, he shares his take on what "domain knowledge" project managers do and don't need, and why.

Margaret de Haan enters an impassioned plea for sanity on quoting project plan dates, so we don't waste time and energy—and reputations—fighting over exactness that doesn't matter.

Tom Ferguson has a warning to fellow project managers about the dangers of micro-managing our project team members and how to behave instead.

Corporate Subscriptions and Licensing

Not sure if corporate terms apply to you? Check out our licensing terms at the top of our Terms of Service page, in refreshingly ordinary, everyday English.