Posts

Showing posts from June, 2007

Why IPTV won't work in Australia - ISP Volume Charging.

It's all about cost... A phone line costs $25-$35 just to have. Add ADSL plans on top. ADSL plan costs vary with speed and pre-paid download volume. Reasonable TV needs around 4Mbps these days - the highest speed and cost plans. How many hours/week of TV per household? Individuals may average 4-8 hrs/day [30-60 hrs/week] - or 15-30%. The Free-to-Air stations and Pay-TV operators provide content 100% of the time. 4Mbps should be available up to 4km from an exchange - ADSL 1 or 2 - or around 50 sq. km. It's not everyone, but a large chunk. For example, Canberra has 10 exchanges, 300,000 people in about 110,000 dwelling units and covers 275 sq km of urban land, or 176 sq km of residential land. Coverage is not uniform, overlaps and not laid-out symmetrically around exchanges. The 2004 ACT Telco Survey [5.5Mb Word 'doc'] estimates ~75% of households would have ADSL available (4km) - but 93% coverage by all means. Monthly ADSL plans start at around $20 plus $30/20Gb. Which...

Turnarounds

My previous post on 'Digging Out', a methodology built from experience in a number of turnarounds, can't stand alone without some justification: What have I done to be credible? Here's a sample taken from a version of my CV: Completing large business critical projects on-time and on-spec. In complex political environments achieving all client outcomes without formal authority. ABN online registration system - Business Entry Point, DEWRSB. Y2K conversion - Goodman Fielders (Milling and Baking) Y2K remediation, CDM DFAT (ADCNET Release 3, ADCNET build/release system) TNT Unisys/Customs (EDI & Finest/Nomad) CSIRO - all Australian daily weather database Diskrom ($350k project income in a year) ABN registrations: The ATO paid for and ran the project. The software contractor was combative and unhelpful. The environment complex - around 6 different organisations for this one project, and another 10 projects. To get anything done required a huge amount of effort, n...

Basis of Quality - What I learnt in my first years at work

On the 17th of January 1972, with 70+ others, I started as a cadet at CSR. This early work experience set the stage for how I approached the rest of my life at work. I'm come to the conclusion that these early formative experiences are crucial to a persons' performance and attitude for their entire working life. Breaking these early patterns can be impossible for some. The cadets of my intake had the privilege to have unrivaled experiential life lessons in quality, safety, team building & working, skills development and personal responsibility. The lessons I took with me into my career: Quality workmanship and precision techniques Formal quality techniques and analyses Following precise analytical processes Managing high work loads and meeting tight deadlines Responsibility for high-value processes/outcomes Satisfying stringent customer requirements Respect for, coping with and managing work in dangerous environments - and experience in handling/responding to hazardous inc...

Digging Out - Turning around challenged Technical Projects/Environments

Something I wrote in 2002: ‘Digging Out’ - 7 Steps to regaining control This is a process to regain administrative control of a set of systems. It can be practised alone or by groups and does not require explicit management approval, although that will help. ‘Entropy’ is the constant enemy of good systems administration – if it has blown out of control, steps must be taken to address it and regain control. The nature of systems administration is that there is always more than can be done, so deciding what not to do, where to stop, becomes critical in managing work loads. The approach is to ‘work smarter, not harder’. Administrators must have sufficient research, thinking & analysis time to achieve this – about 20% ‘free time’ is a good target. This process is based on good troubleshooting technique, the project management method (plan, schedule, control) and the quality cycle (measure, analyse, act, review). The big difference from normal deadline based project management is the t...

Commercial Software is Good - because you Have Someone To Sue.

A friend came back from a ITIL Practitioners course with an interesting story: The course was mostly about the complexities of handling Commercial Licenses, no two of which are the same. The course provider made the not unexpected statement about Open Source: "Don't use it because you have nobody to sue". And they went onto ask "Why use OSS?" His response was: "Because it's best of breed, especially rock-solid utilities & tools". And they continued to not listen... This note is NOT about that particular mindset [Risk Avoidance, not Risk Management]. I'd like to give him, and other technical people like him, a "slam dunk" one-liner response to each of these questions: Why OSS - because it's best of breed! Why use a bug-ridden, poor functioning piece of commercial software when the best there is is rock-solid, secure & Free and Open? Not only do you remove the need to sue *anybody*, you get the best tool for the job and k...

Who can we sue? Or - the Myth of Riskless I.T. Management

This started as a conversation on an Open Source list - on how to respond to people that assert: "We can't use Open Source because there's Nobody to Sue". This is a response I received: The "Who can we sue" issue should be questioned. (i) Can the 'propriatory' software company be successfully challenged? Ask them how many people have successfully won a court case against Microsoft for example? (ii) To sue someone you need to allocate resources to the 'sueing' budget. Ask them that if they plan to sue people then have they budgeted for the possibility? or do they expect their insurance premiums to cover that? Wouldn't the insurance companies be concerned about the 'who to sue' bit and not the company? (iii) You can have software companies who write non open source software who have no money. Sure you could sue them, but you end up losing money and if you send that company broke who is going to fix or maintain the non open code th...