My New Tribe

I was re-listening to part of Seth Godin's Tribes again today. To make a tribe takes 2 things; a shared interest and a way to communicate.

So my new tribe is a community that's forming within PMI to focus on agile project management. We have a group of volunteers on the steering committee, working with PMI to launch the community. Communication is easy among us, done mostly through a Yahoo group, but also with conference calls.

The shared interest aspect is definitely there, a bunch of folks willing to put in the time to make this happen. There was an interesting comment on a call today from our PMI representative. She said some of the other groups going through this were having difficulty with some of the planning, things that we've done well at. The thought that occurred to me was how strong was that shared interest in the other groups. I'd venture to say the formation of these other tribes was being challenged because that shared interest wasn't as strong.

So is there a tribe out there waiting for you to lead? It doesn't take much to get started.

Disobedience

Are there times when you shouldn't follow procedures, when you should go against the rules? Probably.

In the military, we could refuse a direct order from a senior person under certain situations. It didn't happen much (as it shouldn't or military order would fall apart) but sometimes you should just say no.

I've been on projects where stakeholders were asking for features that I had to push back on. In some cases, the requests weren't in line with the vision of the project. In some cases, the time line would be effected. Sometimes they were just bad ideas. As the project manager, I had to tactfully refuse and point out to my stakeholder why I was doing so. In most cases, a compromise could be found.

On a similar note, we should know when project procedures should be modified. A good example is templates. I have a number of colleagues that think templates are a bad idea in general. When they are used, they can be used without thought. Since every project by definition is unique, we shouldn't just fill in templates without thinking about how they apply to our projects, or if they apply at all. They may be boxing us in, preventing us from being creative in our approach to the project.

So next time you're working on your project and some process, procedure, or template doesn't seem right, maybe you should just say no.

Mash-ups

Dave Prior has a good blog post about mash-ups for project management here.

I was thinking about Dave's post in church today. Our church does what they call a
white stone ceremony on the first Sunday of each year. The idea is 2000 years old and comes from when prisoners were release; they were given a white stone to show they've been freed. There's a verse in Revelations that talks about "on the white stone is written a new name" (Rev Ch 2 V 17). So during our church ceremony we write down a word that represents our new self for the new year.

So the word I came up with today was "mashup." The reason was based on Dave's blog. It's more than pulling in different ideas at work. I want to pull the different parts of my life together. I want to take what I learn in my volunteer work with PMI and bring it to work, I want to do presentations that are based on my blog and how my philosophy can be applied to running projects. So here's to a year of mash-ups.

Top Six

What are your top 6-12 goals for next year? Have you thought them through? If you're like a lot of people, one goal is to lose weight. But is that it?

On my list is to get more speaking engagements. I'm going to do more active marketing, submit more proposals to big events such as PMI's global congresses, and then make sure I'm thoroughly prepared so I give good presentations and can get references. I have 1 confirmed even on my calendar and 3 tentative events. My target is 6 events for the year.

So having a set of goals is more than just a list of high level things. For each goal, you should plan out a set of actions to accomplish that goal, complete with dates. Then throughout the year, on a weekly and monthly basis, identify what actions you have to achieve your goals. Don't be one of the crowd that joins the health club in January and by the end of March is no longer going (but still paying the membership fees).

If you're interested in some of my other New Years Planning activities, refer back to last year's post here.

The World's Oldest Government

I had the opportunity to meet with the Minister of Administrative Development for Egypt while I was there delivering a project management conference this week. The minister has a clear vision of where he wants to take project management in order to improve his organization's performance. He's looking beyond just certification to mentoring/coaching and training to help build a project management competency.

Egypt is the site of the first big projects, they pyramids. Ironically, they built in an iterative fashion, starting with a smaller one, learning from their mistakes, and building bigger/better ones.

Egypt is also home to another important project management tool - beer! I know I've sat around with the team after a hard day to unwind and bond over a couple cold ones.

Enshaallah

This is a phrase I've been hearing here in Egypt. It means "God willing." It's used when people make plans to say this is what we want to do, but it isn't completely up to us.

It's like project management. We can make all our plans but things can still go the wrong way. Those are the times we can take the Egyptian attitude and accept the situation and go from there.

I had a project one time where we were doing a data conversion. About a month out, we found out some hardware wasn't going to be ready in time. There wasn't anything we could do about the situation, so we ended up doing the conversion in 2 steps, the second step happening when our hardware got in place. It took a little while to get people past the issue and on the solution, but we did it.

Estimating

I was working today with a client on estimating how many man-hours their project was going to take. It was a pretty straightforward exercise; estimate the number and complexity of all the components of the project and apply benchmark data we’ve collected and add it all up to come up with a total. At this early stage in the project, there is some margin of error in what we refer to as a budgetary estimate. It’s more refined than a level of effort but not a detailed estimate.

The resulting answer was pretty big and the client thought it was much bigger than the project would actually be, and he might be right. Under ideal conditions, the project may take much less time. However, having done projects before, I know this perfect state for project execution is rare. Things often come up. There’s some requirement that didn’t get identified but is a must-have. Problems creep up. People get pulled of the project for something else, or quite or get married. Some features take longer than the benchmark would indicate.

For now we’ll keep an eye on this estimate while we start our first iteration. After we complete that, we’ll see if our estimates for those features match reality. Then we can adjust the overall estimate as necessary.