Back from the first week of ITIL Service Managers' Training... Took me 4 days to recover - part of which could be the driving [only 7-8 hours each way].
Realised I needed email access whilst away - and my Palm PDA with 802.11 wireless doesn't cut it for email. Have acquired a laptop, and am creating 'dual boot' setup. Don't trust MS-Windows - especially those in Internet Cafes. Need 'ssh' to access mail.
So why was I exhausted?
Six of us doing the course - and all of us suffered the same. Lack of sleep, 'exam nerves' each day and extreme psychological reaction. At least a number of us seriously thought & discussed ditching the course - a seriously expensive move.
I don't have a good reason...
Everyone [all men] found the experience "intense". We are all used to change, acquiring new information, reading long tracts, writing, solving problems, creating/giving presentations and attending talks/lectures... And doing the odd test.
It's not like the ITIL material is 'deep' or 'difficult' like Queueing Theory [thanks Neil!]
It is broad - there is a lot to cover. Not that many Powerpoint slides [50 a day?]
Still don't know why I came back so wrung out. Not sure if that's a universal experience.
At this point, just have to take a note of the effect and look for other stories/experiences - and keep pondering over it.
Thursday, March 15, 2007
Why is learning ITIL so hard?
Friday, March 2, 2007
The end of the "Silicon Revolution"
This seems to be one of the biggest IT stories not making news and not being actively addressed by Professionals and the Industry.
Neil Gunther writes about the change in the Moore's Law CPU speed constant. Which is why we have "multi-cores"... In 2000 and 2001, Intel released articles flagging thermal effects could be the next barrier - and predicted in 2010 a single CPU consuming 18 kilo-watts. More than ten times the average household power consumption!
Herb Sutter in The Free Lunch is over makes an aside, illustrated with a graph, on the inflection in CPU speed growth curve - in January 2003. Herb was talking about the insidious problems that true, ubiquitous concurrent programming incur.
Commercial IT has been going more than 55 years. It is becoming quite mature. The next big event horizon is end of the Silicon Revolution - when all the physical limits are met for CPU's (speed), memory size, disk size/speed/transfer rate and network bandwidth.
What will over IT Services look like then? IT groups will no longer be able to rely on the back of the rampant technology improvement. They will have to work, hard, to keep improving their figures.
Design will matter. Real talent, skill and understanding will become important. When large companies are spending 12-15% of their Operating Expenses on IT, the ones that can maintain service levels and business effectiveness and shave 1-3% off costs will have a substantial competitive advantage. The savings go straight to the bottom line, adding directly to Nett Profits.
Nett Profits usually lie between 1% - 10% of turnover. The IT savings above will boost whole company profits by 5%-30%.
Which will impress the market analysts.
This definition of Engineering gives the reason: "An Engineer does for a dollar what any fool can do for 10."
How does the "2% Rule" apply to IT and ITIL?
ITIL is about aligning IT with the business needs. IT acts as an internal business supplying customers - who may be captive.
Sometimes IT is the "2% Rule". Price can be (nearly) no object.
People may need a business result and price is not the main criteria. Recognise these situations and react accordingly.
The "utilisation" and "efficiency" of particular IT assets is not of prime importance - the Total Business Result is.
That's why we don't fret over CPU under-utilisation on desktop computers. And why we do fret over 'poor response' on those same machines.
That 'captive audience' of yours can fire you as a supplier: it's called "outsourcing".
It's all about 'perspective'.
The 2% Rule, or 98:2 Solution
You know the '80:20 Rule' - the Pareto Principle - that 80% of faults are caused by 20% of problems. Here's a similar rule: Items under 2% of budget get different rules.
Every organisation has it's "core business" and will/should actively monitor and control those inputs/supplies/services to remain profitable. They will be very sensitive to their major selection criteria on those.
But for the 'incidentals', different economics and criteria apply.
As a supplier or consumer, recognising which situation applies will help you greatly by being able to tailor your services to the consumers needs and maximise your profits.
If you're a builder and you can buy the same building products for 20% less with no other penalties, then there has to be a very strong reason to not change. Inertia isn't a strong business reason. "Family connections" probably are.
But what about those inputs/supplies/services that you don't use every day? The one and two percenters? The necessary 'noise'.
My plumbers charge $160/hour. If they need some printing done occasionally, how much time can be spent looking for 'the best deal'? The savings have to beat $160/hr spent. Taking a half-day to save 20% on a $1,000 printing job is a nett loss of $450!. (gain: $200, cost: 4*$160 = $640)
For the "1-2%" inputs, cost price is the least important determinant. Total Cost, including opportunity losses/forgone revenue etc, has to be used for a realistic economic comparison.
For the little things, the incidentals, most people put first one of:
For some people, it is always about the price. People on fixed-incomes are "time rich, money poor". They usually fall into this category. Others may be wealthy and always be "careful" or "tight" - there are no set rules for behaviour.
When the hotwater system has failed or the roof has flooded, you need someone Now! Someone who's going to do a Good Enough job, Real Soon. Even if they charge double you're probably happy to pay the money. The downside is not trading for one or more days - way more expensive.
If it's a service, like an accountant, that you are going to be using over an extended period and it's critical to your business, you may take some time over the decision and be very particular in your criteria and trade-offs. It's worth an hours' travel and 30% more to get the best advice and save a lot more!
The "2% Solution" has two business impacts:
The "2% Solution" can also inform what business segment you decide to be in.
If you are an Engineering and Construction firm and specialise in (steel) piplelines, you can choose to enter the "high volume/low margin" end of the business - supplying and laying the long straight bits, or enter the "low volume/high margin" end - building the complex valve/joiner units.
You can make good money at both ends.
Low Margins arise because of fierce competition - everyone can do the technical side.
High Margins are allowed when there is little competition - because the technicalities of the job are demanding/exacting.
Both ends need good management and tight fiscal control to remain profitable.
Technology has the horrible habit of quickly making the esoteric into the ordinary - being a technology leader as a point of differentiation means you can't stay still.
In 1991, it cost $10,000 for a CD-Writer and about as much for a disk that would store those 600Mb.
15 years later, writers were under $100 and disks over 20 times bigger for $150.
Thursday, March 1, 2007
Mythical Man Month II
Brooke's Law doesn't include scaling effects. They're geometric. [There is another effect I can't yet name that kicks in for very large projects so they can never complete. This isn't just an asympote, but a maximum - total output reduces the bigger you make the project team without relaxing the time constraint.]
Here's the heuristic scaling law:
To double output, triple the resources.
[No evidence or research to support this.]
If you have 10 units of work to do and your staff of 6 can do it in 3 months, to produce 20 units of work in 3 months, you need 3 teams of 6 [modulo their effectiveness and project initiation time]. For 40 units, 9 teams, 80 units - 27 teams etc.
Alternatively, what the team can do in 24 months, might be possible in 3 months with 27 times more resource - or around 8 times the total cost, if it ever completes. [I don't have any ideas on the increase in unreliability of the estimates or the 'Project Risk' increase.]
Sometimes "Fast Tracking" may be necessary... But hugely expensive - and where are you going to find around 25 times as many people???
The Standish Group have been performing Primary Research (surverys) of I.T. in the USA since 1994. They've accumulated a large amount of data and 50,000 project case studies.
Their "Recipe for Success" (for I.T. projects) is simple - six people for six months.
It seems to confirm this hypothesis.
"Cheap, Fast, Good - pick any two".
From an article in "Software Magazine", Here's the list of Standish's Top Ten:
Recipe for Success: CHAOS Ten
Confidence Level Success Factors
Executive support 18
User involvement 16
Experienced project manager 14
Clear business objectives 12
Minimized scope 10
Standard software infrastructure 8
Firm basic requirements 6
Formal methodology 6
Reliable estimates 5
Other criteria 5
The Mythical Man Month Revisited
Fred Brookes wrote a definitive book, "The Mythical Man Month" on the management of large projects. He reported the development of the Operating System for the (then) revolutionary "IBM/360" around 1960.
His main conclusion is usually stated as: "Adding more programmers to a late project only makes it later."
Take together the last set of posts on programming/I.T. productivity factors:
Teams, Staff 'Morale/Attitude', Star Performers, Nett Negative Producers and Ineffective Management.
All the factors multiply together - the range of productivity, even for the same staff, is tremendous.
How can sensible "Man Month" estimates be made in these conditions?
Brooke's Law can be explained by a computer analogy:
It's a 'cache coherency' problem. The memory of the existing staff is being copied to the new staff - both groups cannot produce anything until the transfer is complete.
Projects and Admin/Operations tasks can't be forecast using a "mean average person" - individual forecasts have to be made for the productivity of the specific person, team, project, environment... And if you are "Going Boldly Forth where No Programmer has been before" - isn't that the definition of "research"?? It's a creative endeavour - you are done when you're done, not before. Applying pressure, especially in the form of deadlines, is counter productive. Only the bravest of staff will 'push-back' and refuse to release incomplete, incorrect and buggy code or services. And once a 'milestone', like any Victory in war, is declared complete, there is no going back. The body of work, no matter how poor, can only be tinkered with, never fixed.
Or restated: By applying arbitrary deadlines, you guarantee faulty code. Then you are stuck with the mess as the foundation for the rest of your work. You will slowly drown in the morass of your own mistakes - and all easily preventable.
The real Myth, is that there is an average person who's output can be projected.
The best person to forecast completion of a unit of work is: the one who's going to do it!
And the 'horizon' is only clear for about 2 weeks ahead. So detailed work plans can only be constructed for the immediate future. Yes, there will be a design, but it will evolve and it will be a set of road signs.
The old rubric applies: Double your best estimate, then double it again.
And don't take on tasks you don't know how to do... You'll only create a huge mess, and everyone, including you, will be very sorry.
Teams - the Killer App?
Jerry Weinberg, the doyen of the Quality Software movement, in his landmark four-volume set "Quality Software Management" comments on models of Software Metrics - that five factors, each of which could vary productivity two-fold, were left out because they were too hard to measure.
Team Performance is one of these five [from memory].
In "Pop Management" books, there's a lot of "soft" assertions and anecdotal evidence on the value and creation of "High Performing Teams" - but where's the solid research that shows Teams Really Do Work? And what their multiplier factor is. [Jerry is much better than that. He's been an academic and reports some very nicely constructed experiments.]
"Dynamics of Software Development" by Jim McCarthy, the real-life lessons from Microsoft's C++ team, focused on team factors. McCarthys mantra is: "The Software is the Team, the Team is the Software". If there is a problem in the team, it will show up in the software. Faults in the Software are caused by failures in the team process. Team dynamics impact performance immediately and greatly.
Bob Lewis succinctly defines the difference between 'teams' and 'groups' - a 'team' needs everyone to complete the task. There are no "Sales Teams" - individuals make sales.
What I'd like to say is: "Here's the definitive reference that shows Teams improve software & I.T. productivity by a factor of 2-5".
When I find the research, you'll be the first to know.