Vacation

I was out on vacation last week. My son and I traveled to Utah for a week of climbing and hiking. It was a week away from email, conference calls, and status reports…very refreshing. The picture is from Lake Blanche in the Wasatch range.

I'm continuing to read The Five Keys to Mindful Communication. I came across the idea that in order to be open to listening to others, we first have to be able to listen to our self through meditation. "Relaxation is the key to mindfulness practice…" 

When someone comes to you, are you ready to listen to them? Can you stop what you're doing and focus on them? One practice I developed back when I worked in an office was if someone came into my office, I would stop what I was doing and focus on them. I wouldn't continue to type on the computer. I'd put my magazine or report down. I'd listen.

Listening is an active process. By taking time to meditate, we learn to quiet our own mind and listen to ourself. That gives us the ability to quiet our mind and listen to someone else when they come to us. A good vacation can do the same thing, bring you back to the office ready to listen. Have you meditated or taken vacation lately? Maybe you're overdue.

A Dog and a Polar Bear

I recently started reading the book the five keys to mindful communication by Susan Gillis Chapman. In the beginning, she tells the story that goes with the pictures that you can find here. As she tells it, Churchill the dog was tied to a stake outside a cabin somewhere in the Arctic. The owner (National Geographic photographer Norbert Rosing) spotted a polar bear coming towards his dog. The owner knew he was already to late to do anything, so he grabbed his camera. What came next surprised him. Churchill didn't get defensive; he started wagging his tail playfully as the bear approached. The bear didn't act aggressively either, he responded to Churchill's behavior and started playing with him. As the story goes, the bear came back on several occasions to play with Churchill. 

This story is a great lesson for how we communicate. If we get defensive, putting up a wall, our conversation will be different than if we are open and engaging when someone approaches us. Early in the book, Chapman talks about how we need to pay attention to how we respond and have an open mind. She talks about moving away from "Me-First" to "We-First" in our relationships.

This last idea started me thinking about Servant-Leadership. A project manager that practices Servant-Leadership thinks in terms of how they can help the team before they think about themselves. They are aware of their team's needs and they listen.

So next time you are in a conversation, stop and be aware of how you are communicating. Are you really paying attention to what the other person is saying or are you going on the defensive and preparing your next response? 

Mobility and the Project Manager

I read a blog post today about mobile BPM (business process management) written by a colleague of mine, Scott Francis. Scott and I have worked together on BPM projects over the past few years. Having recently purchased the latest iPad, his post got me thinking about how mobile technology is changing the world of project management, or is it?

I am taking over a program after the first release went to production. The user stories are all in a cloud-based PM tool, organized in iterations and releases. So when I created a card board and put the user stories on post-it notes and stuck them up there, my developers made fun of me…but they have been keeping it updated without any prompting. So the question is, how much technology do we need? Can a project be successfully run with just a white board and a stack of post-it notes?

I will always take the simplest solution. When it comes to managing a co-located team, a cardboard is very effective. You can take a quick look and know exactly the status of the iteration. If you have 2 days left in the iteration and a bunch of cards in the column for waiting user acceptance, you know where you need to focus you time. One of the principals of Kanban is to make your process visible, and a cardboard does this very effectively, even if you're not using Kanban.

However, in a program like I'm running, with multiple iterations and releases, you need something more comprehensive to keep track of everything. We planned our next iteration this week. We were using our on-line tool to have a view into all of the stories. As we whittled down the stories for the next iteration, it let us know how many points we had selected, so we knew when we were within our velocity.

Going back to Scott's article, from a mobility standpoint, I carry my iPad around with me all day. I use it to capture notes in meetings, rather than using pen/paper. With Evernote, my notes are available on my laptop when I get back; or even my iPhone if necessary. I can also access our PM tool thru the iPad, so I have our plan at my fingertips, regardless of where I am. It's this instant access to information that makes the mobile tool valuable.

So, what's your favorite approach/application for managing projects?

Are You Invaluable?

I just finished reading the book Invaluable by Dave Crenshaw, who also wrote the book The Myth of Multi-tasking. At first, I thought the book was kind of light. Like Critical Chain, it's told as a story with characters learning as they go. I realized after I was about half way through the book what I was looking for. Unlike something like Drive by Daniel Pink (another favorite of mine), this book doesn't go into a lot of theory. It gets right into some practical steps to help you become more valuable in your work.

For example, Jason, the main character, develops a chart of his activities and identifies those that are his strengths and areas where he would be hard to replace. The full exercise is available in the appendix for the reader to go through. The book continues to provide exercises to help the reader focus in on how they can make themselves invaluable at work.

So if you're looking for a book with a lot of theory that you can use to impress your client or discuss over drinks, this isn't the book for you. However, if you are looking for some straight forward exercises to help you be a more valuable contributor at work, I recommend it.

Resource Flexibility

I had a conversation with Yoaz Ziv, Director of Marketing for Realization the other week on using Critical Chain at the program level. I was gathering some information for an internal project, but one concept, Resource Flexibility, struck with me. I'll admit, I don't like referring to team members as "resources" but I'll stick with Yoaz's terminology.

To use resource flexibility, you first plan out each project in the program assuming full staffing. Then you pull 10% of the resources and put them in a pool that isn’t assigned to any one project yet. By watching the consumption of buffers on each project, you can predict which project may be running into trouble. You can then throw your extra resources at this project to help get it on track.

Be using Resource Flexibility, you take some of the politics out of staffing decisions. Each project manager knows that if their project goes critical to the point of impacting the overall program, they will get resources to help them recover. It's like having a SWAT team around to come in and save the day on the critical project. They come and help out, then go help the next project that needs assistance.







I know there's one school of thought that says putting additional resources on a late project will make it later. It increases complexity, complicates communications, and the new team members have to be "brought up to speed" - taking someone else away from doing their job. But in this case, you start the project deliberately lean and by adding the additional people, you are only bringing the team up to its full size. I think this is better than starting a project with to many people. I've experienced over-staffed, bloated projects that just don't seem to move very fast.

Will this approach only work with Critical Chain? Probably not, but if you don't have buffers, you will need some other indicator to show if a project is getting behind. It could be a burn-down chart. It should be more than just a hunch by the program manager. But regardless of what project management methodology you are using, Resource Flexibility may be a good program level tool for you.

Critical Chain, Agile, and Program Management

I've been doing some research for a project at work on Critical Chain (a result of my articles <here and here> for Projects at Work being noticed within the company). I started by re-reading Goldratt's book Critical Chain. If you haven't read it, I recommend it. It's written as a novel and is an easy read, but still has some good content.

What I've been pondering is how to use Critical Chain in Program Management. I've come across some agilist talking about Critical Chain and Theory of Constraints (TOC-Goldratt's work in manufacturing). Dave Prior recently wrote an article for Projects at Work on transforming to agile where Drum-Buffer-Rope (part of TOC) was mentioned. There was also Mike Cottmeyer's mention of Theory of Constraints I mentioned in a previous post.

So is Critical Chain the answer to scaling agility? When Mike talked about scaling agility at the PMI North America Global Congress last year, he argued that Scrum isn't the answer to scaling agility. Some other tool that can address constraints needs to be used. I think many of us have experienced resources being the big constraint in a program. Critical Chain provides an answer to this.

When using Critical Chain, your first step is to identify the constraint. Let's say it's the number of U/I designers you have. You can't run four projects in parallel because your two designers will be constantly pulled back and forth, and we all know multi-tasking is bad! Critical Chain would say that you need to delay some of your projects to address this constraint, even if this means other resources are idle.

It sounds simple, but will it work? How else can you address constraints across a program? Do we also need to be concerned with buffers? Goldratt spends a lot of time talking about buffers on the project level, including resource buffers. But how does this scale to the program level? Do we need program schedules with resource buffers? I'm going to keep digging in. If you have any suggestions, let me know.

Afraid of Falling

I was out climbing with my son earlier this week. He's home from college on break; he got serious about climbing last year and dragged me into it. My first route was pretty technical (for me) and there were a couple points when I was about to stop but I pushed through and made it to the top. When I got down, my son had some wise advice. He said I will improve if I don't worry about falling and If I'm not falling, I'm not pushing myself hard enough. 

I came across a set of videos on Yahoo; The Failure Club. This was created as a reality TV show that never got picked up by a network, but it's along the same lines as my climbing; go do something without fear of failure…even expect failure…and see what happens.

It's easy to play it safe at work. We don't want to stand out as a trouble maker or risk taker, especially during an economic slowdown. But is that the best choice? If we knew our boss wouldn't penalize us if we failed, how much risk would we take? What could we achieve? 

If you're like a lot of people, you came up with some resolutions at New Years. How many risky items are on your list? How many new things are you going to try? How many things that you could fail at? When I'm climbing and not having a good day, it usually isn't because I'm falling; it's usually because I'm afraid to try and I convince myself that I can't do it. So get rid of the self-doubt and don't be afraid.