Cancelling a Project

Inertia.  Newton described as a body at rest tends to stay at rest and a body in motion tends to stay in motion, unless acted upon by an outside source.  OK, he actually said:

Corpus omne perseverare in statu suo quiescendi vel movendi uniformiter in directum, nisi quatenus a viribus impressis cogitur statum illum mutare.

But seeing as I don't understand Latin very well I thought I would translate for you.  You're welcome.

"Well, that's all very fascinating, but what does this have to do with IT?"  Glad you asked.  You see, a project is much like a body in motion:  it tends to stay in motion.  Regardless of whether or not the project is required anymore or even if the target has completely changed, the project still moves forward.  There are a few skeletons of this sort in my closet, that I almost ashamed to mention.  (Almost, but not quite.)

Have you ever worked on a project that was headed nowhere and doing it at a break neck speed?  Imagine a project where you're almost finished the design and the technology hasn't even been chosen yet.  Tough to finish your design, isn't it?  Image a project where business rules are changing, but the design of the project is two versions of rules behind.  Not going to be that successful is it?  Imagine a project where the developers are asked to work overtime.  For free.  And then tell them they need to work more over time because the project is behind.  Imagine a project where the Project Manger gets promoted, and removed from the project, and yet his line managers are punished for the current status of the project.  Imagine a project where the "technical guru" is unable to comprehend basic technology, yet insists that his technology choices are sound.  Now imagine him in charge of the overall project!!!!

All of these are reasons for a project to stop.  All of these are reasons for a re-assessment of the viability of the project.

But the project kept going.

Inertia kept the project going.  Inertia fuelled by pride and a stubborn reluctance to say "I think we need to stop".  There is no shame in stopping a project if it's headed in the wrong direction.  There is no shame in saying "Things have changed since we started, let's stop and re-evaluate things before we go too far".  The objective for any project should be for the benefit of the organization.  Sometimes it is better for the organization to stop a project and walk away then it is to let the project continue.  Understanding the long term results of proceeding is more important than finishing the project.

(By the way, the project I was referring to was with a previous employer and should not be confused with any current or previous project of Alberta Education, Alberta Advanced Education & Technology or Alberta Learning.)

Let Them Fail

One of the things that we do as parents is let our children fail at things. 

It's hard not to step in and immediately show them the right way, but we let them fail so that they will learn.  When learning to crawl and then walk, we show them what needs to be done, we act like babies ourselves and crawl around on the floor, but we let them figure out for themselves how to move their arms and legs.  When they are older we watch as they try to put a square peg in a round hole.  If we tell them it can't be done, that doesn't sink in as much as having them fail, repeatedly, and for days sometimes, to get that square peg through that hole.

As they get older, they get "smarter" in that they recognize much quicker when something is wrong and they change their actions.  No longer do they spend 10 minutes trying to get two legs in the same pant leg, as they recognize within moments that things are quite right.  After a while, however, their hormones kick in and they become as stubborn as babies with that square peg, because they are "smarter than you" and they "know more" than you did at that age.  Once again, we let them fail, knowing that the phase will pass and that they will learn.  Sometimes painfully, but they will learn what works and what doesn't and the fact that the tattooed, lip-pierced biker down the street might not have the same interests as them.

Finally they become adults, get an education (sometimes) and get a job (hopefully).  And what happens then?  Many organizations punish people who make mistakes or make it so intolerable to function that the person quits.  For the most formative years of our lives we are left to our own devices.  We are allowed to fail, knowing that someone is going to help us out by not necessarily helping us solve the problem for us, but by letting us know that it is safe to fail.  Why does this change when we get a job.

I've made so many mistakes and failed at so many things I can't count.  I recognize some of my biggest failures and I know that I have learned from them.  I recognize some of the repeated failures where I have hit my head against the wall over and over again, only to have something finally sink in.  But the one thing that I also notice is that I have been allowed to fail.  Yes, I have had my knuckles rapped for failing, but it was only when I failed to learn was the subject every really brought up.  I consider myself quite fortunate to have had supervisors who were willing to let me fail at something, so that I would learn, rather than coddling me and telling me exactly what to do. I essentially got on-the-job education from my mistakes.

Looking back on it I realize that the best thing we can do for people is let them fail and then support them as they try again.

Best Practices

In the past year I've stated a phrase so many times that I began to wonder what I really meant.  I'm sure you've seen the phrase many times before, both in my writing, in job postings, in management briefs, all over the place, but what does it mean?  The phrase is:

"... best practices ..."

This is kind of a loaded question.  I could state that what I mean by best practices is that it is something that I think is important to do.  That would definitely boost my ego, but for the most part when I call something a "best practice" it means something more. 

For the most part when I call something a best practice it is because it is:

An established sets of practices, procedures or methods used to achieve an optimal result.

Now, who defines what an optimal result is in this context?  There are a number of different contributors:

• Academia.  Some things are called best practices because those in the academic world have studied, debated and decided that the best practice in question meets the criteria.  While those in academia do provide some input into best practices, the problem lies in the fact that the academic world is never as complex and complicated as real life.  So, take their opinion with a good dose of realism.
• Standards Groups.  These people create certain standards and they should, theoretically, know how to make the most effective use of the standards.  They are usually more accurate with their proclamations, but, once again, ideal situations are difficult to find and some of their best practices do not work in real life.
• Industry Consensus.  This is something that the majority of people in an industry think is a good thing.  It is usually decided upon by a grass roots movement by people who actually do the work and not strictly academics.  Their opinion is highly valued as it is more likely to provide meaningful results when used in the correct context.
• Organization.  Based on the way that an organization does things, there may be some specific practices that need to be done by an organization to improve the end result.  These best practices may fly in the face of other best practices read and used over the years, but because they are specific to an organization they are probably the most relevant.  (Please note that if the organization changes, but the best practice doesn't then this becomes nothing more than a waste of electronic ink.)

All of these opinions, however, must be tempered with the fact that they were created with certain pre-conditions in place or under certain technological constraints.  A best practice is only a best practice if it actually applies to your situation.  Minor variances can sometimes be ignored, but if your naming standard was based on 6 character RPG standards, they probably aren't applicable to .NET 2.0, so some (un)common sense needs to be used as well.