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. 

Caucuses

I am working in Iowa this week. Today, Iowa is the center of the universe…or at least the US.  For those that don't follow American politics, the Iowa Caucus is the first stage in selecting the candidate that will run against President Obama in November. Winning here is a good first step on a long journey.

How is your project political campaign going? Are you on course to win the election? While a political campaign is a type of project, most project managers have to handle politics as a part of getting the project delivered. A good project manager knows to pay attention to their stakeholders and figure out how to resolve conflicts between parties. They can respond effectively to a negative campaign and win the popular vote.

Ignoring politics can be a mistake. A project can easily be derailed by someone that has the right influence with the right person. This doesn't mean you have to stoop to the level of a mudslinger, but you should at least be aware of the impact they can have on your project.

So after today, Iowa will fade as the political campaign moves on. Good luck in the elections.

Scaling Agility

I recently had a couple articles (here & here) published in Projects at Work based on some discussions I had at the Project Flow 2011 conference. I'll admit going into this conference I wasn't an expert on Critical Chain. In one of my articles, I compared Critical Chain to Agile and came to the conclusion that Critical Chain is not a form of Agile. However, that doesn't mean they can't co-exist.

For those unfamiliar with it, Critical Chain is the project management approach based on Theory of Constraints (TOC), all based on books by the late Eliyahu M. Goldratt. Goldratt's books are interesting because they are written as novels, not text books. 

The PMI Agile Community of Practice had a tweetchat last week on scaling agility with Mike Cottmeyer. One of Mike's comments was about Theory of Constraint. Mike tweeted that at the lowest level in an agile organization are small projects using Scrum. At the higher level, TOC or Kanban can come into play as the work should take on more of a flow. Mike recommended reducing the dependencies between projects and reducing bottlenecks (full Tweetchat text can be found here for PMI Agile CoP members).

So what does this mean to you? One lesson to take from all of this is that we need to constantly keep our skills up to date. Earning your CSM is good, but not enough. You need to pick up on other techniques as well, so find a conference, pick up a book or two, or get involved with the PMI Agile Community of Practice. This way you can scale up your personal skills in agile. 

You Can't Learn Jazz from Wikipedia

I've been listening to a series on Jazz from iTunes University. It's been interesting because they talk about a topic and then play some examples of what they're talking about. It makes it easier to understand the difference between Hard Bop and Modal when you are listening to the styles as they're discussed. Even then, I don't think you really learn Jazz until you pick up an instrument and start playing.

This got me thinking about how people learn. I often go to Wikipedia to look up some fact. This is often the case when I'm researching an article that I'm writing. As helpful as Wikipedia is, it's not a place where someone can learn a skill.

I'm starting an engagement in which I'm playing the role of mentor. I'll provide the client some basic knowledge about running agile projects, the kind of stuff you might find in Wikipedia or a good book on the topic. But then I'll observe and provide coaching. I'll share experiences from my past that are relevant. At this point it is a true learning experience.

Passing a certification exam doesn't mean we have the experience to perform a job, it means we have the knowledge. It is by applying the knowledge that we gain the experience. Sometimes we have the ability to try a new technique in the office and see how it works, sometimes a new skill is forced upon us, and sometimes we need to seek help from a coach or mentor. 

As this year draws to an end, think about the skills you've developed and the experiences you've had. Has it been enough? Are starting to think about what skills you want to build next year?