My New Year's Resolution
A few weeks ago I was at P2P in Cairo, speaking with Philip Diab, the 2008 Chair of PMI. We were both about to give brief speeches at a conference and he brought up the idea of developing a consistent theme and using it as a sort of guiding idea when preparing for presentations over a period of time. It was great advice, and I have decided that I am going to start off by applying it to the blog.

Remix
In Lawrence Lessig's new book "Remix", he devotes a fair amount of time early on, to explaining how kids today are creating mashups with music and he goes on to detail what the legal ramifications are with this and the book goes on from there. If you like Lessig's work, or are at all into reading up on copyright law and intellectual property rights, I highly recommend it.

While I was reading it, I found that I kept drifting back to the idea of mashups and other places that they occur in modern life. The basic premise is that you take two existing things and push them together to create something new and (ideally) better. The site Mashuptown.com has a great video explanation of it in the upper right corner of their homepage.

Depending on your taste in music, this could be a good or a bad thing. But, in coming back to it, I started to think more about the other places in my life that this takes place - especially work.

So, jumping back to the whole consistent theme thing... for 2009 my focus is going to be on PM Mashups, or, bringing different (pm related or not) ideas and practices, etc., together in one's approach to project management with the end goal of coming up with a more cohesive, adaptive and ideally, creative way of managing work. My plan is to develop a series on the idea and hopefully, I'll be able to find a bunch of folks along the way who are also mixing their chocolate and peanut butter and don't mind talking about it.

PM Mashup #1 

For about 18 months I have been primarily using Scrum to manage my projects. For most of what I do, it works very well. It's adaptive, lightweight, and is great for developing trust with the clients. However, I have found that it for it to work best, I need to add some components from other approaches.

Traditional PMBOK type documentation is something I tend to get lazy about, so I am always trying to find ways to make it easier to get through. I do, however, think it is critical to have those artifacts and I am a very firm believer in keeping a historical record so that you can learn from your mistakes. It would be easy to get away without doing this in Scrum, but, as I mentioned above, I think that historical artifacts are critical and, even if there are no defined requirements at Go, I do think that they need to be locked down by the end of the project. (Always leave the room nicer than you found it.)

So now, when I'm working on Scrum projects, I generally try to make sure we have a wiki set up so that we can provide the client with documentation that will be current by the time we leave and which they will hopefully maintain as a living, organic version of the requirements doc. Now, I know that the requirements doc should be created up front, but the simple fact is that most of the time, what is being asked for initially, is not entirely definable and will probably change during development. I also know that once we create the initial requirements that I, as the PM am responsible for keeping it current. Unfortunately, in practice, what I've found is that the requirements doc becomes something that is either A) gathering dust the moment it leaves the printer or B) something I work furiously on updating so that it can gather dust the moment it leaves the printer.

My goal is to have a place to capture whatever we initially know in an informal, plain language manner and then build on it as we move forward. We usually start out by entering whatever use cases we have and we work with the product owner until they reach a level of comfort entering directly into the wiki themselves. Over the development cycle, the use cases are updated by the team as they evolve into a sort of post development explanation of what is in place. We evolve, with the product owner, from the initial need, to the realized product, which is documented in plain, simple language. It is not traditional requirements and may lack a lot of the structure that a traditional requirements doc includes, but if the objective of the traditional requirements doc is to define what is requested to a level of detail that can be executed and litigated against, then the wiki reqs, or Requirements 2.0 is intended to be easily digested by humans who may have a need for the information.

This mashup doesn't fit perfectly into Scrum or a PMBOK type approach. But, it does enable the workflow process and meets the informational needs of the client in a way that does not place an undue burden on the team.

I'll post more in about a week, but if you have any mashups of your own, I'd love to hear about them.

Happy New Year!