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.)

Striving for “It Doesn’t Suck”

While waiting for the bus I looked across the street and noticed that someone seemed to have written a long essay on the plywood surrounding the construction site.  While I couldn’t read much of it, what I could read was very thought provoking:

… should we be striving for “it doesn’t suck” as our goal?

Is “it doesn’t suck” ever something we should strive for? 

As I sat down on the bus, thousands of images flashed through my mind, all of them related to that comment.  For instance, did you know that of the last 24 toy recalls in the United States, every single one has been related to a product that has been shipped from China?  Due to various pressures, both in the Chinese company manufacturing the toy and the American company importing the toy, the people involved probably thought that “it doesn’t suck” was a pretty good choice.

It doesn’t suck doesn’t necessarily mean that something is good, just that it isn’t bad.  There is still a wide gap between good and bad and it doesn’t suck only covers a small area of that gap.  Now, I will be the first to admit that this problem is not specific to one role within the project.  Everyone, from the project manager to the developer and everyone in between, has to commit to striving for something better.  While one weak link in the chain can have a downward affect on the overall quality of an application, that does not mean that it cannot be remedied.

When I was younger I remember the news talking about the lack of quality of North American products and how products from overseas were better built and cost less money.  Ford started an ad campaign about “Quality is Job 1”.  Much has happened since that time.  Overseas products no longer have the same high regard as they used to (at least some overseas products), but the rise in quality in North American products has not been that great.

The sign of a great company, and great staff, is one where no one strives for “it doesn’t suck“.  The purpose behind all of our work is continual improvement towards something better.  Something good.  Something great.  In my mind, what we should be striving for is “it’s awesome“.


Being old, excuse me, older, than many of you gives me an advantage over you in a number of ways. I will be able to get the senior rate at the movies before you and I will be able to get discounts at hotels before you. What it has also done, is given me the opportunity to fail more often than you.

One of the best teachers in the world is failure, as it shows you what went wrong and what not to do. All you need to do now is learn from that failure and try to prevent that same situation from happening again. As someone who has been in this field for 20 years I have experienced a lot of failures, both on my part and those with whom I’ve worked. Each failure has been a learning experience that has allowed me to gain some piece of knowledge such that I am able to either not fail in the same manner or at least recover faster.

Unfortunately, failure is often seen as a bad thing, and from an overall project perspective it most certainly is a bad thing. However, small individual failures are not something that should be frowned upon, but embraced. Scott Berkun, in The Art of Project Management, wrote:

Courageous decision makers will tend to fail visibly more often than those who always make safe and cautious choices.

This applies to everyone that makes decisions, from the project manager down to the developer. If a decision was made that was, at the time, the right decision, celebrate the decision, regardless of whether or not it was a success. If the decision was bad, educate the decision maker so that they can learn from their mistake. (Educate does not mean punish.) By telling people you expect them to be perfect and that you do not expect any problems, you are telling them to play things safe and not try anything new. Mankind didn’t go to the Moon by playing safe. IBM played it safe with the personal computer and lost. Risks need to be taken at certain points and we need to train all of our staff, from developers to project managers, when failure and risk, is a good thing.

High Performance Teams

In another life I was busy researching the idea behind “High Performance Teams” (HPT). These teams are not NASCAR fans, nor are they hooked on amphetamines. Instead, they are a group of individuals who work with each other really well and outperform other similar groups in terms of their quality of work and the speed with which the work gets done. You’ve seen these teams in hockey as the coach will normally put certain players together and keep them together throughout the season with few changes.

In IT, however, the concept of a high performance team does not always seem to be understood or even implemented in many areas. A team can be as small as two people, or it can be much larger, but there are some key traits that all of these teams share. (OK, here is where I differ from conventional wisdom so if you want you can tune out, even though you may be missing some really cool stuff.)

  • Trust. Perhaps the most important trait is that the members of the team trust each other to make the right decisions or at least a decision that can be lived with by everyone.
  • Communication. Team members communicate with each other effectively. Different people understand things in different ways. Some people like metaphors, others like analogies while others love diagrams. In a HPT the appropriate mechanism is used at the right time to maximize the effectiveness of the communication.
  • Commitment. Each team member knows that every other member of the team is just as committed as they are to producing a high quality product.
  • Continuous Improvement. An HPT is not satisfied with the status quo, they want to do the next job better than they did the last job and the one before that, by continually improving how things are done.

Some organizations are not ready for HPTs as it means setting a group up as being “special”. Others are not interested as they believe, rightly or wrongly, that if people just follow the process everyone would be part of an HPT. Some larger projects do implement this concept within the overall project and find that the HPT is extremely productive and crucial to the success of the project.

It may not be your cup of tea, but at least you’re aware of the possibilities.