Archive for the 'Planning' Category

Anticipating a Project Go-Live Date

Saturday, September 30th, 2006

Here I am an entire month after tinkering with a site re-design (which I’ll be activating this week), and I just can’t seem to help myself from getting nervous before making the drastic change. There’s simply no getting around the anticipation of a change that everyone will be able to see, and know that you had some hand in the effort…even if it is as simple as changing a WordPress template choice and customizing it to your liking.

I’ve got a few things to say about this subject, as I’ve had experience with quite a few of these in the past of various shapes and sizes.

1. If you’re not nervous the minute you go live, you’re probably doing something wrong.

I’ve only been on one project where I felt really good about launch day. I didn’t have a care in the world the couple days before-hand. Needless to say, I spent most of my waking hours the next week just trying to keep everything from falling apart. Of course there’s many lessons learned about projects as you get more practice, but being a little nervous and doing my best about being aware of things all the way up to the last minute is routine for me on project lifecycles now.

2. The longer you’ve had a plan and been able to stick to it, the more successful it will be.

Of all the projects I’ve been involved with, the ones that had the most project planning were the most successful. Now I, of all people, am not the over-planning type and generally take shortcuts wherever I can if it will save a project from being late. However, I totally respect the art of planning when it comes to completing a successful deliverable. There’s a few exceptions to the rule here, but in general…the more planning the project had, the better the odds were for an on-time completion.

3. Less scope creep typically means less defects.

Let’s face it. Scope creep happens on almost every project. For anyone following an iterative life-cycle, something along one of the iterations shown to the customer will trigger a response from them that forces you to change a few things. I don’t see anything wrong with changing some things along the way, but from what I’ve seen is…the more it happens, the more defects you will be likely to find in your final deliverable. This becomes less of a problem as your team gains experience in dealing with refactoring, risk-analysis on proposed changes to your designs, etc. Either way, the less scope creep you have, the more solid your delivered product will be.

4. Enjoy the rush, most things after go-live are maintenance for awhile.

There is nothing quite like the adrenaline rush of a newly released product. That overdose of sheer cosmic power that forces the blood through your ego-veins is sometimes impossible to maintain within your body’s limits. Sure, there’s going to be panic-moments after a launch where you react to get things under control…but for crying out loud, take a moment to really congratulate yourself on the delivery. You worked hard to get to this moment. Enjoy it. Enjoy it before you think too hard about the fact that you’re going to have your hands full of all the maintenance items that will stem from this launch or deployment. Rest assured, it normally settles down and you can go back to working on another creative assignment. For the near future though, you’re pretty much stuck in a fix-it mode until you know you have something solid.

5. There’s just nothing quite like it.

The thrill of delivering a final product to a customer is just unbeatable in my book. I’m really a customer-centric employee more often than most I guess. The best part about my job is that I know I’m bringing value to my customers and feeling a real sense of pride in my abilities as they marvel over their new “toys”. Sometimes it’s just the sigh of relief they make as you prevent a crisis or save hours of mindless work for someone through automating something for them. No matter what your service is…building a pile of success stories is not only good for your marketable profile, but it’s reassurance that you’re capable of meeting your goals repeatedly. Nothing is quite like knowing you can back up your “fightin’ words” when you have to throw down your estimations or opinions for future projects.

So what is it that you anticipate before going live on a project? Preparation and size of project usually effects my expectations. What factors effect yours? I find it just a little amusing that I still get nervous over simple little website changes when I’m also working on a project that makes this entire blog look like a single pixel on my screen of responsibility. I guess that’s just a habit I’ll never get over. Oh well, I’ll just enjoy it while I can. ;)

Tags: , , ,

5 Steps To Help Your IT Team Concentrate Part V

Monday, August 28th, 2006

This post is the final installment of the 5 Steps to Help Your IT Team Concentrate series. The overview of all the steps I’ve covered in this series is listed for you here, with links to the previous posts, 0 being the introduction.

0. Coin a cool term for being fully concentrated
1. Identify how your employees concentrate and perform
2. Create a process where team members are most effective
3. Encourage collaboration in the group time, and support total isolation for the individual time
4. Create the appropriate atmosphere
5. Don’t be afraid to change and experiment

Today we’ll elaborate more on the fourth and fifth steps:

4. Create the appropriate atmosphere.

Atmosphere in the workplace can be defined in a number of ways. I like to think about atmosphere in two different ways, the physical and the mental. Physical atmosphere is the obvious environment that you can see, touch and feel just by sitting in the room. I like to think of the mental atmosphere of the employee as the environment perceived after you take away all the physical aspects of the workplace.

Physical atmosphere

The last post in this series probably touched on the physical atmosphere that would help an employee concentrate more than I really wanted it to. What I want to emphasize here is that the appropriate physical atmosphere is not difficult to provide relative to any other job environment factor.

I stumbled onto a great article from Jeff Atwood’s Coding Horror site called The Programmer’s Bill of Rights. The article is geared totally towards programmers, but I find it a very versitile list that could apply to just about any IT employee I can think of since most of them spend a lot of time in front of computers. The bill is pretty specific to physical environment factors that are ideal, if not essential for productive programming:

  1. Every programmer shall have two monitors.
  2. Every programmer shall have a fast PC.
  3. Every programmer shall have their choice of mouse and keyboard.
  4. Every programmer shall have a comfortable chair.
  5. Every programmer shall have a fast Internet connection.
  6. Every programmer shall have quiet working conditions.

I would probably add that some sort of barrier needs to be up to prevent line-of-sight with mobile people that are up and about or standing around that would distract the employee at their seat. If cube walls or something aren’t an option, face chairs toward a wall so that they’re looking at their monitor without a bunch of movement in their peripheral vision if possible.

Bottom line is, a one-time cost of a few things that are shadowed by the wages paid to each member of your team just make sense for the company in the long run.

Mental atmosphere

The mental atmosphere is a much more difficult set of factors to narrow down and adjust for your employees. Creating a positive mental environment can be achieved by taking some of the following into consideration:

  1. Work to resource ratio. Are you way understaffed? Dumping too much on everyone at one time that they can’t possibly finish without loads of overtime? Keep expectations reasonable with what you have. Overstressing a skeleton crew will turn out even worse if you drive them away.
  2. Good team dynamics. Do your team members work together well without any mediation? Are your members eager to work with any other members on the team? Try to avoid pairing up people that don’t get along, and most certainly remove personal issues between members from the department even if it’s at the expense of losing someone or transferring them. The ripple-effect of negativity is horribly bad for your team.
  3. Corporate support. How much does your company really back up your department’s initiatives? Do you struggle getting budget support for simple items? Do other departments meet you half way to collaborate on projects requiring everyone’s involvement? If the support isn’t there from the corporate level, the motivation and departmental/self worth of each on the team can certainly demoralize everyone.
  4. Interesting projects. Are you tasking talented employees with the same exact work day after day, or are you challenging them with needs that put them on the cutting edge of technology occasionally to deliver a solution. Who wants a boring job? Not anyone that wants higher salaries. Leave the boring repetive work to low-budget help or someone that’s not exposed to it. It’s more fun to get “in the zone” on projects that you have to really apply yourself on.

Basically, creating a proper physical and mental atmosphere for your team allow them to not worry about things that would distract them from total concentration. There are tons of distractions that can stem from the environment they’re in be it the squeaky chair they’re sitting in or the argument happening ten feet away about someone who told a joke that offended the person sitting next to you. Create the proper atmosphere, and you’ll get the most concentration possible from your team.

And the last step to helping your IT team concentrate:

5. Don’t be afraid to change and experiment.

This particular step is kind of a catch-all that I think is necessary as you try to find the “perfect” environment and methods to help your team concentrate. One thing that I can’t begin to emphasize enough is that every individual is different, and finds their best levels of concentration differently.

No corporate dictate on process is going to motivate your creative thinkers faster or better unless all of your employees are exactly the same. So in order to get the most for your team, you have to be flexible, and try out different things as the team grows or changes. Don’t be afraid to try something new and dismiss it if it turns out to royally suck for everyone.

Conclusion

So, to wrap up the series…I’ve described steps to take in order to help your IT team to concentrate. I’ll close with a request for suggestions from you on what other steps YOU have applied and seen successful. The steps I’ve outlined here have worked for me and many others that I’ve seen that needed to eliminate distractions and increase concentration. Hopefully they’ll help you as well.

5 Steps To Help Your IT Team Concentrate Part IV

Tuesday, August 22nd, 2006

This post is the next installment of the 5 Steps to Help Your IT Team Concentrate series. The overview of all the steps I intend to cover in this series is listed for you here, with links to the previous posts, 0 being the introduction.

0. Coin a cool term for being fully concentrated
1. Identify how your employees concentrate and perform
2. Create a process where team members are most effective
3. Encourage collaboration in the group time, and support total isolation for the individual time.
4. Create the appropriate atmosphere.
5. Don’t be afraid to change and experiment.

Today we’ll elaborate more on the third step:

3. Encourage collaboration in the group time, and support total isolation for the individual time.

In the last section, I emphasized creating a process that works for all types of employees. The focus of this post is to reiterate and emphasize the importance of what should be happening in the group and individual times allocated.

  • Group Time

Assuming you’ve found the balanced process that works best for you, or at least have found one that you’re going to try out for now…it is very important that you encourage total collaboration during the group times allocated. During the group sessions you want to get the full advantage of having everyone in one place while everyone is in ONE PLACE. You don’t want to have to readdress the same issues later on because you didn’t fully cover everything, which could totally take someone else out of their “zone” later on by trying to gather up everyone again.

During the group sessions you want to:

1. Make sure everyone has a clear direction of what’s to be accomplished while in the group.
2. Make sure everyone has a clear direction of what’s to be accomplished before the next gathering.
3. Encourage input from every member without ridicule to keep the fresh ideas and variety of possibilities on the table…yet narrow the focus before the conversation is over.
4. Keep the energy and motivation as high as possible.
5. Identify dependencies on each member if they exist, followed by action plans of those involved to make sure things fit together nicely.

I’m sure there’s more to do in group meetings to make them effective. I’m not trying to list the all-encompassing group session agenda. I’m hoping to identify what will help your group sessions really act like group sessions so that you can also allow your employees to focus without interruption when it’s time for them to work alone.

  • Isolated Time

This is the part of the entire series that I had intended for a single post. As much as I attempted to contain it within a post of it’s own, the other topics continued to jump out at me in more and more detail until they too were detailed enough to merrit posts. After all is said and done though, the initial thoughts have now been spread throughout the entire series leaving this particular part in its content-lacking state.

At any rate, the most important part of this series is finding ways to help your IT folks concentrate. The majority of IT people I’ve worked with concentrate FAR better in isolation than in a group. Some people may be more productive in groups, but concentration is definitely better when running solo. So how can you help your people perform better when they’re all alone?

Well, here’s a list that may help:

1. Give each employee their own space. That’s right, don’t make your programmers all sit at one big long banquet table in single room. Allow them to at least sit at their station without breathing down the next person’s neck. Especially don’t sit people across from each other without some kind of barrier in between even if it’s not sound-proof.
2. Reduce walk-ins as much as possible. Give them a door they can close once in awhile. If that’s not an option, headphones, cube signs saying “Currently IN THE ZONE, Do Not Disturb”, or a community “quiet room” where people can take their work with them and know they won’t be disturbed.
3. Reduce electronic interruptions. Encourage them to turn off phones, put chat and mail programs in another virtual screen or computer out of view. Some people have the ability to multitask really well, and their job may depend on their ability to focus on 10 things at once…but most employees I’ve seen do much better when they’re able to complete one task in the queue and move on to the next.
4. Make sure they are totally aware of the expectations, and that they’re equipped with the knowledge and tools required to meet their goals. There’s nothing more frustrating than having to wait on a reeeeaally slow-ass computer to compile your code when all you want to do is check that little conditional you changed. Minds wander when there’s nothing to do but wait. This also implies that your employee is trained enough to handle the job given. If they can’t handle the job, they’re probably more worried about what will happen if they can’t finish it than finding out how they could try delivering something.These are the main points, though I’m sure there’s some really good stuff you could add to it. So what else can you think of that would help in either environment?

The next post will conclude the series on helping your IT employees concentrate by talking about creating atmosphere and adopting change.

Tags: , , , , ,

5 Steps To Help Your IT Team Concentrate Part III

Monday, August 14th, 2006

Today’s post is a continuation of the series for the 5 Steps To Help Your IT Team Concentrate. The full list of steps is recapped for you here, with a link to the previous posts in the series (step 0 being more of an introduction):

0. Coin a cool term for being fully concentrated
1. Identify how your employees concentrate and perform
2. Create a process where team members are most effective
3. Encourage collaboration in the group time, and support total
isolation for the individual time.
4. Create the appropriate atmosphere.
5. Don’t be afraid to change and experiment.

Today we’ll elaborate more on the second step:

2. Create a process where team members are most effective

Not everyone on the team is going to work in the same mode of concentration, nor with the same collaboration habits. Some people are better off isolated from groups to be able to concenrate enough to finish large or complex tasks. Others are much faster at solving problems in a group environment where ideas bounce back and forth in a very multi-tasked manner.

Whatever type of team you have, make sure you identify the combination of collaboration and isolation that works for each individual. If you run strictly in one mode or the other, half your team could be ineffective most of the time.

An example

How I prefer things work in a team environment has a mixture of both environments in many iterations. I like to run projects large and small with some variation of this flow:
(Keep in mind, there’s always many other projects going on, and this example is for a pretty small project. So 1-2 days on a task just means sometime over the course of those days, not all day every day during that timeframe.)

Day 1:

  • Brainstorm Session (Group - short)
  • Brainstorm (Individual - day or so)

Day 3-4:

  • Rehash ideas, narrow direction (Group)
  • Initial design choices (Group)

Day 5-6:

  • Agree on design/implementation approach (Group)
  • Take tasks and split amongst team to work on (Individual/Pairs)

Day 10:

  • Group review to reiterate tasks/progress (Group)
  • Continue individual tasks (Individual/Pairs)

Day 14:

  • Integration Session (Group)
  • Release (Group)

Now, I’m not trying to define what a software lifecyle should be with this post. I’m attempting to focus on the team-dynamics of the workflow. A good mixture of group collaboration and individual focus time seems to have always worked best. If you can manage to schedule the group times to be short and often, the long stretches of individual time will be far more productive for some. Those that work better in groups should be paired up with someone else that works equally well with others.

The point
The idea is to come up with a scenario where you’re playing off of people’s strengths instead of assuming that some process driven by a company-adopted methodology will work for your team every time. If anything, take the company-adopted methodology and at least try to accomodate some changes to help leverage your individual team member’s strengths as you see it helpful.

Now I’ve discussed some of what you can do overall for the team. The next installment in this series will point out some of the more specific things you can do to help the individuals through whatever process you decide to adopt.

What processes have you experimented with? How many variations have you tried and hated? I imagine most of you have some combination of group and isolated environments, but are there many successful with just using strictly one or the other? Let me know your findings…

Continue on to Part IV.

Tags: , , , , ,