The Retrospector

I stumbled onto an article the other day from The Chief Happiness Officer blog about the effects of starting a meeting off with a positive round. This sure triggered some memories about countless tips on project management I’ve gathered in the past, but my first reaction was that this applies to more than just meetings. Granted, it’s most applicable in a meeting environment, but I think that conference calls, emails, even the occasional self-reflection is better off when you’re able to think of something positive first before heading into a full analysis.

Effective meeting structure

I don’t want to sound like I’m advising you to misrepresent anything. By all means be totally honest with everyone about things. However, the structure in your delivery can really have a positive or negative impact on your message as a whole.

At one of the first companies I worked for, I noticed right away that there was a pattern for meetings and for most any form of communcation to a group:

1. Start with a summary of what the discussion is about.
2. Point out something positive.
3. Describe the overall goals and objectives.
4. Recap the direction and action items, if any.
5. Motivate as much as possible during the recap.
6. Thank everyone.

The part that stuck out here was the point out something positive. With any project, something is happening. It’s really not hard to find a positive to point out and give credit for in group projects unless you’re just in a really shitty project with a total set of losers for a team. If that happens, at least try to highlight something good that you’re going to do.

Having felt a sense of accomplishment and recognition is highly motivating. One of the points I’ve made in a previous article about motivating geeks elaborates more on why this is a crucial step in keeeping motivation in the group. Starting off with postive points in a meeting is a great opportunity to give that recognition in there where it’s deserved before diving deep into controversial materal for the rest of the discussion.

May as well make the best of the unavoidable

I really hate meetings. They are, however, a necessary evil sometimes to keep effective collaboration amongst a group. The one-man-show should have no trouble with just communicating status upward because all the other coordination is simply happening in his mind. Having others to work with complicates things because if there’s communication barriers mistakes work their way into flawed designs or implementations.

So, if you have to sit through or coordinate meetings every week. I would say a good idea is definitely to start off as Alex mentioned in the link above, with a positive point that can set the pace of the conversation for your entire encounter be it a group meeting, call, or email.

What ideas do you have to put a nice positive spin on things before you get started? Do your meetings ever start out with a totally negative feel where you just get totally torn between wanting to work somewhere else and digging in your heels? Maybe putting the positive note somewhere else in the meeting structure has worked well for you. Share some insight, I’m interested in what you have discovered.

Tags: communication, meeting, positive+influence, collaboration

One of the crucial points in a project is near the end where you have to decide to simply wrap things up enough to deliver. The ability to enhance the product forevermore can creep into your scope so easily if you let it. (Scope Creep) Sometimes it gets to the point where you’ll be on an endless timeline of development where you can’t just finish it and get the product shipped.

What I’d like to talk about in this article are some of the things to watch for to make sure you can get your product delivered to your customer. Such things include avoiding scope creep, properly comparing requirements with personal opinions, and follow-through on making sure your product gets to a deliverable state.

Scope Creep

This is a subject that probably has enough issues that it could be an entire series of posts. What I think you should take away from this for today’s article is simply that allowing the scope to broaden or change too much will prevent you from every being able to clamp down on the “moving target” deliverable. You will spend so much more time trying to factor in new features or implementation approaches for a dynamic scope than ever wrapping up the ones you currently have on the table that you will never get the original requirements in a deliverable state.

(more…)

The last few weeks I’ve come across a number of things that required some sort of estimations, so that everyone involved could get a set of expectations in their minds on what would result with each endeaver. (I’ve also noticed quite a few articles about estimation lately.) Tasks range from honey-do projects around the house, to components on an application in the office, to personal estimates on some little things I’d like to just get done.

Estimation is very simple in most cases, but it can get very complex for some things. I’m going to break down some of the issues that effect one’s ability to accurately estimate projects here and hopefully share some insight on how to find your most likely results when forced to think about quantifying your abilities.

Experience

If I had to sum up the art of project estimation in one word, that word would be experience. There’s simply no replacement for what experience can do for you when you have to think about tackling a problem.

If you were given a task of figuring out how to start a campfire, you would have learned the first time around some of the things that don’t work by trial and error. You may have spent an hour trying to get it started the first time, but this time you know you should give plenty of airways to the bottom of the fire to let it breathe while you put the tinder in the flame to get it going. There’s really no way to know that without having experienced it for yourself the first time around.

Case study

Let’s apply this to a scenario at work. Let’s say your boss comes to you and asks how long it’s going to take to get the florescent green with dancing monitors background CSS generator doo-hickey working. Now you know you really need to get this really cool background generator done this week, and if you could get it done today you could impress people. Not only that, but you quickly realize that it’s just some string parsing that you could do blind-folded because it’s just some little class with a few methods for generating color and monitor outlines.

(more…)

In the corporate world, there is a very heavy weight put on successful delivery. Companies usually understand that some things have learning curves, but where do you draw the line on testing out new technologies before you actually stop and deliver something?

Are you known as the guy that knows about a lot of things but never delivers on time? Can you relate to someone that always delivers on time but ends up using the same outdated approach over and over again? Maybe you’re somewhere in the middle, but how do you know when to balance learning with delivery?

I’ll define some considerations you need to take, factors that should effect your decision, and give some tips on how to apply what’s known to deciding which approach you should take to still be successful.

Things to consider

• Time – How much time do you have? Are your customers patient? Is there a high visibility on whether or not you can deliver quickly?
• Risk – Do you already have success with similar projects? How much experience does your team have in completing like tasks? Do already know how to implement all requirements requested?
• Resources – Do you have enough help to get everything done? Are you in a volatile environment where people aren’t able to dedicate themselves long enough to be effective? Is everyone involved able to focus on just your project without worrying about other commitments?

All of these items should be weighed in when deciding on a project plan. If you know there’s a very low risk in being able to deliver on time, it’s likely a good opportunity to begin trying new things or experimenting with new technologies that can be applied to some of the components.

If the risk is medium or high that you might not meet the expected delivery, using what you know will work should take precedence over experimenting with frameworks or widgets you’re unsure of.

(more…)