about:thoughts

I have been doing on how to drive people crazy or maybe not. What I haven’t touched on though is how to get value out of something that may seem like a complete waste of time. First of all I need to say that I hate writing status reports. I would much rather be doing real work.

What should you get out of it?

• I’m making something cool (Engineering)
  • Reuse existing work as appropriate
  • Know who has experience doing what
  • What’s important to the client
  • What has the high risk to the client
  • Where can I help out if another developer has a problem
• I’m paying for WHAT!! (Client)
  • When will things be done
  • Where is the money going
  • What are the problems and does it affect the schedule
  • What are the high risk items, and what is being done to alleviate the risk

By tracking these things it allows the engineering group to know how to improve for the next project and identify possible areas where additional training and/or resources might be needed. For the client it allows them to know when they will get what they are paying for and if they should use that engineering team again. While this simplifies things a bit it should become obvious that if you don’t care on improving yourself/organization then you don’t need to worry about tracking and reviewing the status of your projects.

How about now? Maybe if I keep repeating myself you’ll hear me.

Ever worked with someone that thought they needed to tell you something every five minutes or else the world was going to fall apart only to find out that the only thing they are doing is telling everyone what they wish they were doing? Alright, that was a bit extreme so lets look at the other side of the spectrum. What about the person that works by themselves only to come out once every six months to tell you how great their work is only to find out that even though you asked for a square box they made a sling shot.

Yesterday I posted about status tracking and today I wanted to discuss how frequently you should check in. in the previous two scenarios we saw two extremes where I’m sure we have/are/will work with someone that it is described as such.

In order to begin understanding why these trends are so common there are some misconceptions that need to be addressed.

• I have too much work to do.
• You can just look at my code and see what’s new.
• It’s in the project plan, I just did what I was supposed to.
• If I don’t tell you everything I do, you won’t think I did anything.
• My time is too important for that. or, I could be doing something else.
• I don’t get any value from it.

Before we can begin breaking down these misconceptions it is important to understand why it is important. At the most basic level it is about getting stuff done. But what is the stuff that is being done, and how do you know it’s correct. Then there is the issue of getting things done efficiently.

Instead of looking to methodologies for these answers, I want to focus on the broader issue of why things are important, not how to do those things. That is if it’s possible to break these two apart. So we shall see as I continue posting my thoughts on this topic where this journey takes me.

How do you handle the conveying status across the team? In my experiences as a consultant and developer I have seen various practices. When I was consulting I found where some employers did not care about status meetings or reports whereas others relied heavily upon them. Whereas the places I have worked as an employee the trend is to just convey status informally with, or without, regularly scheduled meetings.

What is the right approach? Before you say “The one that works!!” how do you know that it was effective and did in fact work? I would like to think that just by having a conversation with someone it was sufficient, but have you noticed the trend where people tend to forget things after they happen? I always forget things and take horrible notes. So the logical solution to this would be to have a place where status can be tracked in a written format where everyone in the group has access. How do you prevent this from becoming yet another process? The last thing the group needs is another process where the group members have yet another thing to do where they get no value.

Should there be a meeting used for conveying status? No one wants an extra meeting and we all have zillions of other things we want to do. Right now I feel that there should only be a meeting if the participants are able to have dialogue. If the meeting is just a way to spout information from a PowerPoint, then send out the PowerPoint to everyone and call it a day. If it really requires a meeting, do it online where people can stay in their Starbucks office. This leads me to another thing, if you are having a meeting where the subject being discussed is important, do it in person and pay attention.

Maybe for the next topic I can do a post on the frequency of status. When does it become white noise and when is it too late.

It’s been a while since I have posted anything of interest to my weblog. So think of this as a fresh start. I decided to move my blog back over to WordPress and didn’t really feel like keeping any of my old content.

One thing I want to note about my fresh start is that I am planning on doing some raw writing on my journey. I don’t want to come across as an expert, or a legend. I have more questions that answers and my posts should be read with that understanding. My inspiration for starting over came after reading this post by JP Boodhoo. I’m not going that extreme, all props to him though as that has got to be a fun journey. Jeff Atwood also had some inspiration in his post Revisiting the XML Angle Bracket Tax. Right now I can only dream as writing and programming as good as the previous two. So join me on this journey where only God knows where I’m headed.