Strategic Planning and Jam

Whilst IT strategic planning has become more and more the way forward, with more and more advice on how to do it, there remains one area within most organisations which constantly fails to deliver its promised potential.

The big problem is how do you get from a strategy to delivered systems? Well, you will get lots of advice on how to build large, complex strategies covering every aspect of the organisations IT from people to networks. Problem is these strategies are never implemented. They are not implemented because of a lack of commitment, or because they are wrong, or that the technologies or skills are not there. No, it is simply that reality tends to intrude, and all these strategies tend to take five to seven years to implement. 'But what about delivering something useful today?' is the cry from the top, 'you have been promising jam tomorrow for the last twenty years', 'when are we going to see some return on our investment in you?'

Weak Joke Koan

How many programmes does it take to change a light bulb?

None, it's a hardware problem.

Productivity?

"You aint seen nothin yet" - Bachman Turner Overdrive

Let’s be clear, the path to real, genuine productivity is by the use of teamwork, and teamwork will be covered later in this blog. So I suppose that's the end of this entry;

THE END

But in order to understand why you should be so enthusiastic about the use of teams you have to understand why productivity is so important, how it fits in with the rest of the organisation, and how there are some ways of organising your work that are more likely to achieve it than others.

First of all a basic question; what is the most important aspect of building, or developing, systems?

The answer is;

PEOPLE

…and it is definitely not;

THINGS

This is very important, so let us dwell on it a minute or two. By 'people' I mean you, and me, and the Users, and the system administrators, and so on. By 'things' I mean hardware, systems software, tools, methodologies, concepts, technology, consultants, and all the other stuff that you can go out and buy off the shelf.

Another way of putting this is by saying that the most important aspect of developing systems is;

SOCIOLOGY

and not

TECHNOLOGY

Thorpe's Third Rule of Estimating

IT IS ALWAYS 2.7 TIMES BIGGER THAN YOUR MANAGER THINKS.

Of course you could always use the Zen estimating method; 'It takes as long as it takes!'

Thorpe's Second Rule of Estimating

IT IS EITHER 11.6 TIMES BIGGER OR 1/11.6 TIMES SMALLER THAN THE USER THINKS.

Unfortunately, they underestimate 11.6 times more than they overestimate, but nonetheless for 8.67% of the time you can impress users. By the way the 11.6 is an average, the more senior the user the more he will underestimate the task to the point where I had a Chief Executive who was convinced that anything could be achieved with 'only one line of code'. Another strange aspect of the users perception is that it cannot be improved by any amount of training.

Thorpe's First Rule of Estimating

IT IS ALWAYS, ALWAYS BIGGER THAN YOU THOUGHT.

Do not be fooled, even if you are a world expert estimator complete with COCOCOBANA and electric fan, even if you have a full set of past metrics and a record which says you are normally within 5% accuracy, deep down you still feel it should not take as long as the figure you have just come up with.

Computer Aided Scientific Wet Finger In The Air

CASWFITA really does have some basis in reality. The main aid a computer can give you when it comes to estimating is in recording previous estimates together with the actual time taken. The thing is it is no good simply asking programmers nicely if they would awfully recording these details? No chance.

No, you have to create an environment where estimating, developing, testing, and moving to a live environment are all integrated. Not an easy thing to ask for but it has been done.

Pseudo Scientific Wet Finger in The Air

Beware of some of the aids to estimating that you may be offered, what I would describe the PSWFITA estimating techniques, some of them only actual work after you finished the project, or so far into the project that they are of little use, or mean that significant extra work is involved in performing the required task.

Having got this far with our estimating acronyms we can follow one of the few rules for building newer, bigger, and better acronyms. Take your acronym and add 'CA',for computer aided, to the front of it.

A particularly attractive acronym in this area is Barry Boem's Cost Control Model or COCOMO which has been incorporated into a number of software products. What I've always wanted to do is to go one step further than COCOMO and come up

with an estimating model called COCOCOBANA, but I have so far failed to come up with something sensible it can stand for.... suggestions on a postcard addressed to Terence Thorpe.....

Converstions with a Mental Midget

One of the ways of measuring the size of systems is by the use of Function Point Analysis (FPA), it is particularly useful because it can be used relatively early in the development process and is language independent. I have used FPA as a tool in measuring productivity. However, there are two versions of FPA, FPA I and FPA II. I was explaining to a 'Methodologist' about some of the productivity we had achieved in a major project which was an order of magnitude better than what was normally achieved. All this particular 'propeller head' could comment was that I had used FPA version I and this had now been superseded. Frankly I did not care if I was measuring the system size in Widgets Per Square Inch (WPSI), it was the relative performance of the team that was really important. He had totally lost the point of the exercise! No measure of system size or productivity can be very accurate there are just too many variables, what FPA gave me was a 'rule of thumb' measurement.