Drinking from a fire hydrant

So I started a new project this week and am in the middle of figuring everything out. I am reminded of when I was starting nuclear power school with the Navy and was told the training was like drinking from a fire hydrant, a lot would be coming out and it was my job to catch as much as I could.

I’m working with a company in financial services, so it isn’t completely alien, but I am finding there is a lot of terminology I am trying to pick up. Add to that the aspect of meeting new people, learning their roles, and how the organization functions. Then there’s the specific aspects of the process that is the subject of the process improvement/BPM project. There are a lot of moving parts.

So how does someone jump into a project and “hit the ground running?” There are a couple of things I’ve learned along the way. The first thing is to get your hands on any documentation and read it. I find that I read everything once, and then go back a couple days later after I have a bit more context and read it again.

Next, ask questions. With a little bit of context, you can ask questions that make it sound like you aren’t completely clueless. I’m usually quiet for the first day or two as I gather that context so I can ask better questions. The questions you ask say a lot about you, or as a t-shirt my daughter has says, “There are no stupid questions, just a lot of inquisitive idiots.”

Finally, you need to relate what you’re doing to what you’ve done before. During some of my conversations with my client in the last day I was able to do this. I could relate some specific requirements they have to what I’ve delivered in past projects. This is when, as a consultant, you show that your experience is worth the money they are paying you to be there.

Sunk Costs

Are you a good decision maker? Do you consider the facts? Explore the options? Look at the big picture are well as the details?

How do sunk costs play into your decisions. If you've invested a lot of time and money into a project, does that influence your decision on whether or not you should kill the project?

Sunk costs is what has already gone into a project that you can't recover. At one telecommunications company I worked for, sunk cost played into decisions. They didn't want to kill a project that they've already spent so much on.

Sunk costs should not influence your decision. You need to look at the current situation and decide if the investment from today forward will result in the benefits you are aiming for. It doesn't matter if you've already dropped $2 million on a project, what matters is what it will take to complete the project and what your benefits will be. What this can mean is that if you are behind on schedule, over budget, and it's going to take a lot more to finish the project, then maybe you need to kill it even if you already spent a bunch of money.

Disconnecting

If you've been following my blog, you'll notice I haven't made a post in over a week. I just got back from a week cruise to Alaska. During the cruise, I was completely cut off from the rest of the world. I wasn't looking at the paper, wasn't checking email, or even using my Blackberry. Now that I'm back, I realize the world didn't stop without me.

It was good to get away, not only from work but really from everything including volunteer work, writing, chores around the house etc. The only regular activity I kept up was working out. Instead, I was taking a lot of pictures, getting to know Aperture better, and enjoying nice meals with my family. Now I feel re-charged and ready to get back into the projects I have going on.

Making Lessons Learned Work

I had a project go live this week, always a good thing. I mentioned that we ran our retrospective last week. Today I came full circle with that discussion. I pulled together the other PMs in the company for an internal discussion of the results of the retrospective.

We did find one common theme that extended to other projects we've executed. And while we discussed how to address the issue, that isn't the point here (but maybe for a future blog post). Today I wanted to discuss knowledge management.

Knowledge management is about changing behavior. If I conduct a lessons learned session and in the future review those notes as I'm preparing for a future project, that's a step in the right direction. It beats putting the notes in a shared drive and never looking at them again. If I pull together my community to discuss the outcomes, that's even better.

So what have you learned lately and who have you shared it with? Do you have an internal team to share with? Would it be a good blog post? Maybe an article for a magazine. Don't just keep it to yourself.

Scrum and the Dalai Lama

I believe truth will ultimately prevail. No system can subdue truth forever.

- The Dalai Lama

Scrum is all about truth. In waterfall, you can hide behind project estimates and big requirement documents, but not with Scrum. I've heard a number of experts say that Scrum will make your problems visible.

One tactic that I've heard with bidding for a project is to bid low and then make up for it with changes. Is that being truthful? Maybe it's the only way to get business.

I do a lot of project estimates, and I always tell people I can give an accurate estimate on the last day of the project. The further we are from that day, the less accurate my estimate is. I don't try to pretend I can finish in a certain amount of time when I know it can't be done. I've moved toward this approach as I've become more agile. I think agile is about getting away from a system that hides the truth.

PM Network

I was quoted a couple of times in the recent issue of PMI's PM Network magazine, talking about portfolio management. You can find the article on p. 46 here.

I like to use Stephen Covey's analogy when I talk about portfolio management. Having good project management in place is like climbing the ladder effectively. Having a good portfolio management process is making sure the ladder is leaning against the right wall.

I still see organizations that struggle with balancing the portfolio. Selecting the right projects to execute can be challenging. This involves having some good selection criteria, which should tie to the organization's strategy.

I had a client that changed selection criteria in the past year. The change in the economy caused them to change organizational strategy and they re-evaluated the projects that were important to them. On the flip side, I've seen organizations that aren't sure which projects should be implemented. Sometimes it comes down to the sponsor that makes the most noise gets their way. With resources tight, this isn't the way to manage a portfolio.

Today's Lesson Learned

I am wrapping up a project this week, and yesterday I brought the team together for our retrospective. One topic that came up was also brought up at my presentation at the PMI EMEA Congress in Amsterdam last week. The topic was how agile teams fit into a non-agile environment.

On this project, I brought my team in with me, agile and ready to go. My client said they were starting to use agile, but it wasn't widely adapted yet. The problem we had was at the intersection between our team and non-agile teams that were doing some of the development work for our project.

Since these other tasks were not complicated, I didn't take into account how long they could take. I also didn't account for the fact that these other resources were not dedicated to my project and had conflicting priorities. You can probably guess the results, we were held up waiting for delivery from these other teams.

So what do you do in this situation? In the future, I will be more actively engaged with these teams and not depend other group's managers to oversee delivery of their components. I'll make sure timelines are understood and deadlines are set. I know I need to engage these other groups sooner in the project and understand what their delivery approach is so I can follow any procedure I need to in order to meet my schedule. In addition, I'll think about contingencies in case there are delays with other groups.

Agile & non-agile can work together, but don't forget that everyone may not be moving at the same speed or the focus your team has on the project may not be the same as other groups that are supporting multiple projects.