Best Practice Applied In Wrong Context - Example 1

A friend of mine was ranting the other day. He had just done an iteration retrospective with his development team wherein they took a look at their quality metrics and discovered that "quality" had actually dropped off even though his team had spent more time than ever before on the client's official Quality Process.

I discussed this further with him and we agreed that quality is a mostly subjective concept when it comes to software ... we agreed that it can't be objectively meaasured ... we agreed that it can't be artificially injected "to meet the required metric" ... we agreed that it is something that Software Quality Assurers infer based on monitoring the various metric trends that make sense in the particular environment/context that the software is being developed in/for.

So with all this agreeance I asked him to explain further.

This story is probably a symptom of why I think there is so much cynism in the software industry. Read on if you dare!

It turns out that the client has a well worked out, well defined Quality Process that they are extremely happy with. This Process is guaranteed to prevent massive loss of life/income/spiralling out of control costs/etc etc - you can imagine why a large company invests huge amounts of time and money in creating a bullet proof Quality Process: manage risk, whatever that risk is.

Okay ... so why is my friend ranting? His team followed the process, passed a bunch of procedural milestones apparently and everyone was happy. Yet when he and his team look at the metrics they defined for how they measure quality, they noticed that the number of issues had risen, that some important tests had not been run early enough in the iteration to find issues that they could then respond to before the end of iteration. There were known open issues, and the were issues that had been addressed, but had not been signed off. There was waste accumulating that had not been a problem before.

How did this happen? The people whose responsibility it was to run the tests, to provide the early feedback had been too busy ensuring the team met the Quality Process requirements - they had been documenting, and reviewing and getting documentation reviewed and spending a large amount of time away from the product they were responsible for delivering. They were going on a tangent from users' needs.

And it showed.

There is no happy ending here - key client representatives (project stakeholders, but not users) have to ensure that their organisation's process is followed. Even if they know, and everyone else knows, that the process is not adding value, and that indeed, as above, the process is actually diminishing value. And it appears often that several times a group of client representatives need to experience failure and pain before they will attempt to address a badly formulated, or in the example above, placed, process. Sometimes, regrettably, these lessons are learned during retrenchment phases.

Yuck!

Basics of Web Site Optimisation - Rule 3

This post is mainly aimed at small to medium businesses that are just starting out and are keen to get something going, or have just gone live. I can't tell you how many times I have taught people over the past few years just a handful of strategically important things. So...here goes again, this time in a way that I can now simply refer to. As for my credibility - I would rather not divulge that here, read my Web Site Optimisation Rules and you decide. They are, after all, common sense, and common knowledge....like most things I blog about!

My number 3 rule: Choose or move to a good web site/domain name

Reasoning:
1. A great deal of emphasis is placed on web site / domain names by search engines when they rank your site
2. A great site name is easy for visitors to remember, to type, to tell their friends about, and their friends will also be able to spell!
3. A great name does not get easily confused with another site
4. Choose carefully when choosing .com or .co.uk/.za/.ch/.etc! Where are your visitors? What are you providing? Where would your visitors EXPECT you to be? Your domain name suffix also sets up expectations for visitors who do not know you at all and are trying to distinguish you from your millions of competitors!
5. Similar to my previous rule regarding good page and sub-directory names, the closer to English and your "market speak" your site name is, the better it will do, eg, bad:
http://www.baddayatwork.com, versus
good:
http://www.good-day-at-beach.com
6. Try and make sure each of your web pages' content somehow relates to your domain name - you do this by either creating very small web sites that are very focussed, or by choosing broader domain names that can be more easily applied to the different types of content on each page
7. One day when you busy swapping links with valuable online partners, the closer your domain name is aligned with theirs (or broad enough) the better it will be,
eg, bad:
valuable partner's site is all about pencils, eg http://www.pencils.com, your site is named:
http://www.erasers.com, versus
good:
http://www.pencil-erasers.com
best:
When the search engines look back from pencils.com to your pencil-erasers.com and vice-versa, they will identify a cluster of related sites, and thus rank both your sites higher!

As a final note - it does matter, and it does not matter what domain name you eventually choose. But in the initial stages it helps to have a good one. After your site is well known, after you are receiving enough enquiries as you can cope with, then it really does not matter. How many sites have "bad" names yet are now household names - yahoo, google - these are not (or were not) common English words before they became very well known web sites! And in my industry it is common for the "guru's" to create site names based on the concatenation of their first and last names - just look at the list I read on the right of this page to see what I mean!

And that is my Rule 3. I will be uploading the others as time allows!