The picture pretty much speaks for itself. I haven’t had to make business cards on my own in years, but Zazzle made it pretty simple to do online. I created the logo at faceyourmanga.it. Even in the days of the web a card can have some impact.

As a project manager on dozens of projects I have sent hundreds or perhaps thousands of project status reports. I’ve read even more status reports as a development manager often showing up Friday afternoons in the old inbox.

Every status report needs to cover the basics like budget, scope, and schedule. Other than that the big thing is to point out new risks or items that have been mitigated. In an Agile context the status reports can often be eliminated entirely, but it tends to be a document people hold onto when getting adjusted to Agile. They often looks like paper versions of dashboards with the traditional red/yellow/green designations. All green means no need to read. Then again I once worked for a director who was actually color blind so I’d make sure the colors are also spelled out.

As a PM I remember borrowing my first status template from another PM who had in turn adopted it from her time at Andersen Consulting (Accenture after the rebranding). I adjusted it, but I’ve used it ever since. I can’t say I have a favorite format for project status reports, but I do know they need to communicate the key points as succinctly as possible. As a PM it’s important to know who’s going to actually read these reports. Some of your audience much prefers to here a verbal update even if it’s very short.

As a manager the best approach to status reports is to stay directly connected with your projects so you don’t need to rely on them. You should be spending a significant portion of time with the bigger projects or the projects that are struggling potentially only relying on status reports for the well oiled smaller projects that are just getting done. And don’t forget to reward those projects that are just getting done right without much need of your services. These are the well managed projects that should be rewarded more often.

Finally, I think I should expand on email and status reports. As managers you typically get 150-200+ emails a day many CCed or forwarded to you as an FYI. When you send that very detailed status report as a Word attachment much of your audience will never read it. I realize PMs often spend a painful 30-60 minutes tweaking the status report to send out every week only for it to go almost completely unread. What I really want is the key points of the status report directly in the email. That means you can send the attachment, but make sure you copy the critical stuff into the body of the email. The pain involved in not being able to read it in the preview pane, having to click on the attachment, wait a few seconds for Word to bring it up and render it just to start reading that nothing critical really happened this week often isn’t worth it. And an email link to the status report buried in project server is rarely any better. So, please don’t rely on attachments.

A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

• Prag Dave’s original CodeKata site.
• The KatCatalog from the Coding Dojo wiki.

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

I realized today that I’m #152 on a list of the top blogs for developers. Jurgen Appelo (NOOP.NL) has been compiling lists like these for a bit now and this humble little effort manages to do pretty well. Jurgen himself has made a great effort to put out quality content on a regular basis with a management perspective. As there’s not a lot of software development managers posting these days it gives you some rare perspective if you’re a developer working for one of us pointy haired bosses.

I’m now part of 11.5% of all California workers looking for work. My organization decided strategically that they didn’t want to do in-house development, hence they didn’t need a development manager. I just wish I had gotten a longer chance to show the significant quality and cost benefits of maintaining a development team in-house.

There is shock as you realize your routine has changed. It settles down after a few days. Next came the silver lining that comes with this sort of change:

• Doing coding katas every morning to tighten up my programming chops. I’m alternating between doing solutions in Ruby, Java, and Groovy.
• Looking at options to do something I’ve been passionate about like Agile coaching, QA management, or old fashioned professional services.
• Attending some conferences and user groups in the Bay area since I have some travel time.
• Reviewing some open source projects I always wanted to contribute to.
• Catching up with friends in Sacramento over lunch.
• Hanging out with my two daughters including picking them up on bikes last week.

Sacramento isn’t the biggest tech market and it’s home to the state of California government and their massive budget issues, but I’m confident I’ll find a good opportunity.