| Pete Dashwood 2006-10-31, 6:55 pm |
| Some responses below...
"Clark Morris" <cfmtech@istar.ca> wrote in message
news:dunuj2lsrlmfl2562ajued527airpmi4db@
4ax.com...
> This is in response to a thread of a few months back and my comments
> are interspersed.
>
> On Sun, 30 Apr 2006 14:06:32 +1200, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> I believe that organizations get the IT they manage for.
That's like saying that in a Democracy, we get the politicians we deserve...
:-) (I agree this is arguable, but having just returned from a couple of
w s in the United States, I can't believe ANYONE deserves the current
administration... :-))
Sorry, coming back to your point...
Unfortunately that is not always the case. The cost of in house IT often
balloons... This is usually caused by unforeseen problems, hidden costs,
escalation of costs, and undercalling by accountants who have no real idea
of what is involved. When financial alarms start going off, the usual
response is to stop work. (God forbid the budget should be exceeded and the
Management Team all lose their bonuses...:-))
In good years when the company is making easy profits, this can be accepted,
and the projects will be completed with an increased IT budget, but if
profits fall for any reason the IT budget may stand out like a throbbing
thumb.
Suddenly the question is asked: "If we are a [whatever] Company, why are we
spending [large percentage] of our profit line on things like IT?" The
option to simply outsource or lease the service, or replace it with a
standard package and do some Business Re-engineering to meet the package
requirements, becomes very attractive.
(Note that the only people likely to object to any of these options are the
IT people; the rest of the business just want a timely solution... Besides,
it is not THEIR jobs that will be axed...)
Here's an interesting exercise...
Find out what the annual IT budget is in the company you work for. Then work
out how much product or service your company must move or sell in order to
cover that budget.
If it is more than 10% of the annual sales, polish up your CV...:-)
I was working many years ago for a photocopying company in Germany. They had
had many years of easy profits with their 'salesmen' really just 'order
takers'. Then it changed. In one year, they went from substantial profit to
a hefty loss. The IT staff, like the rest of the work force, were fairly
blase...this was Germany, there were unions, no jobs were in danger, it was
just a glitch, next year they would be back in profit...
I worked out that to cover the IT budget they would need to make around
50,000,000 photocopies. I had no idea how many they actually did make, but,
given the population of Germany at that time was around 60 million, that
seemed like a pretty big stack of paper.
Sure enough, within 3 months they had brought in a new CEO and the first
thing he did was slash and burn IT. Hundreds of people lost their jobs (self
included; but, being a contractor, I was pretty philosophical about it and I
had already started looking when I did the calculation outlined above...I
was actually out of work for about 10 days...others weren't so lucky).
The point is that even if a Management Team plan their IT, budget for it
carefully, there is no guarantee it will fulfill what is expected of it.
Technology changes so rapidly, ownership of this years cutting edge may find
ou with a heap of obsolescence before the equipment has even been
amortised...
> As computers
> become more powerful, the inefficiencies of packages using external
> tables and mechanisms other than customized code to control processing
> becomes less of a problem.
From the Management point of view, that is the least of the problems anyway.
10,000 thousand cycles measured in
> nanoseconds per cycle with overlapped processing is a lot less of a
> concern than the same number of cycles where the cycles are measured
> in microseconds with no overlap. The move to outsourcing IT however
> is more questionable. The computer systems encode and implement the
> organizational practices.
And most of these have 'evolved' over time. Very rarely have the Enterprise
processes been DESIGNED as an integrated whole, from the ground up. They are
bloated, inefficient, and we would love to start over, but nobody dares to,
because it would have unquantifiable risks... Outsourcing or implementing a
package may be a good opportunity to review existing processes and
practices.
> While program coding by what ever method
> (COBOL coding sheets with punched cards, drop down menus and the
> latest shining IDE in Delphi, .NET, etc.) may not be the core
> competence or need of the organization, controlling the way the
> organization works definitely better be.
Definitely! But that is not an IT function; it is a joint responsibility of
a Managent Team, with IT providing input to it and making sure that what is
being proposed is technically feasible. The methodology and technology
utilised should not have any bearing on it; it is clarifying WHAT is to be
done, not HOW, that is important.
> If the IT department is
> viewed as unresponsive, that may say more about the communications and
> outsourcing may only exacerbate the problem.
Well, it MAY say more about communication, but in my extensive experience it
doesn't... It is unresponsive because for decades it has been trapped behind
methodologies and 'practise's that simply don't deliver.
Consider the normal approach...
1. Requirements gathering.
A Business Analyst goes and finds out what is needed. How? By talking (and,
hopefully, listening...) to people on the shop floor. The business people
have traditionally had no idea what computers are capable of (fortunately,
computer literacy is rising exponentially in the general population, but
this is another factor leading to the demise of in-house IT), and the
Analyst has only general ideas about how the Busness functions (but may well
have a programming background, so sees everything in terms of files and
records). It is like a Quantum Physicist talking to a Mechanical Engineer,
about scheduling oil changes on a moped.
Wouldn't it be much better if the Engineers could simply schedule and apply
oil changes without needing to talk to a Physicist?
If oilcans weren't so complex, they could...
2. Functional design.
Analyst translates what was discussed, into the outline of a system.
3. Point 2 above is decomposed into a set of technical specs and it is
signed off. Programming starts.
etc ad nauseum...
We already have three opportunities for poor or misunderstood communication;
programming, testing, debugging will provide more.
Finally, 9 months later, IT triumphantly roll out the new schedule and the
new oilcans and get the Engineers trained on them.
Engineers greet the IT delivery with polite acceptance. The oil points on
the moped have changed and the moped itself has been upgraded. There is a
new motorcycle that has had to be bought to cope with increased deliveries,
and it requires a different schedule. Too much hassle in getting signed off
requirements changed to tell IT about it, so just learn how to use the new
oilcans and do the best we can...
2 months later the new motorcycle seizes and cannot be used; diagnosed as
incorrect oiling.
The Waterfall delivers something like what was required 9 months ago, to a
Business that has moved on and needs support today. IT can NEVER catch up.
Although this is not their fault, they are perceived by the organization as
'failing to deliver'. (Human Beings are not always fair and reasonable when
assigning blame...)
Now contrast this with outsourcing...
The outsourcer has a vested interest in delivering the goods and keeping the
customer happy. If there are changes they must be managed, but they will be
accommodated if feasible. The customer will be offered the options of havng
the new changes, but the date slipping, or accepting what was agreed, with
release 2 scheduled as quickly as possible behind it, or, for an additional
pament, having the changes incorporated into the current delivery. The
outsourcer's costs are lower; there is no problem with getting added
resource to do the changes the customer has requested. The rate may be
re-negotiated but everyone will be happy.
.... or with a package...
The package does what it does. If changes are required the first thing will
be to see why the base system is being deviated from. Tailoring will only be
indertaken when the business case shows it must be and when internal process
re-engineering will not achieve the advantage that tailoring would.
As the package vendor is not part of the company, they can be litigated
against if there is failure to deliver.
> Now changes are visibly
> billable.
Yes, see above.
>With outsourcing the people in IT definitely have a loyalty
> to the provider and are a part of the provider's culture. Crossing
> country boundaries can exacerbate the communication problem even if
> the countries are the United States and Canada. Each level of removal
> complicates the legal situation.
But you have a choice; there are many outsourcers, all vying for your
business.
>
> This seems good but I truly question whether a spreadsheet application
> developed as a side project in a using department has the same rigor
> that the official application would.
I can't believe you wrote that :-) Some 'official applications' I have seen
(and had to 'fix') were far worse than anything an IT illiterate user could
come up with.
However, I cede your point; for the most part, professionally developed and
designed stuff is better than stuff that someone built by reading the Help
files on Access or Excel. (At least, they SHOULD be... :-))
More importantly, if the shaky 'locally-assembled-by-idiots' application is
available TODAY and does everything the user department wants (even if it
doesn't comply with IT 'best practise' and doesn't have logs and controls
and interfaces), but the 'official application' is still 3 months away
because some problems were encountered with downstream feeds or data
migration from an old validation database, or there has just been an OS
upgrade on the mainframe and we have three ws of regression testing every
existing application, so development has dropped to a very low priority...
then, would you be prepared to tell them they can't use their home made
tool? (I wouldn't...)
> Little details like error
> handling, making sure the inputs are correct, making sure that
> organization policy about items is taken into account, etc. get in the
> way.
No, they CAN get in the way. I have seen local systems that took all of
these factors (and more) into account. A contract I recently completed in
the UK had more Computing Science graduates in the Business than in the IT
department. Some of their 'local systems' were excellent. The world is
changing. There is a rising generation of computer savvy youngsters coming
into business and they don't necessarily want to work in IT. Eventually IT
departments (in the companies that still retain them - many will simply
outsource their network management, help desk, and hardware rollout) will
need to embrace these local systems and ensure that shared resources are
available for local development.
>If the IT department is doing as bad a job as the department
> creating the spreadsheet, then there is no greater problem. Many
> times IT has to be the mediator between/among departments. Just
> because something looks right doesn't mean it is right.
Er... I think it usually does... otherwise it would look wrong. :-)
> Bluntly
> people in the business don't necessarily know exactly what they need
> and these scattered applications may have a good effect on the bottom
> line or a disastrous one.
I'm not advocating duplicated data and 'scattered applications'. I'm
advocating IT working with users and ensuring there are shared resources
available so that local systems can be developed by individual departments
in a way that benefits the oprganisation as a whole. Yes, there are petty
rivalries and jealousies between departments and some of them don't want
certain figures to be publicly available. That has to be addressed, and IT
is a perfect mediator for it. The corporate needs are above the need of any
individual department, but that does't mean that departments can't develop
their own tools and databases.
It has certainly been true that people in the Business haven't always known
what they needed IN IT TERMS. That is changing.
And it is also true that IT specialists don't necessarily know what the
Business needs either...
> This is especially true in an era of PIPEDA
> (privacy act in Canada), Sarbanes Oxley accounting system requirements
> in the United States, Health information requirements in many
> countries, etc. Understanding these requirements and making certain
> systems comply with them is time consuming. These laws may require a
> documented and structured way of implementing ALL information systems.
> We are not there yet but somehow ad hoc production systems producing
> data for making decisions don't seem to meet the need of the CEO to
> know that a system is in place that can give him or her some assurance
> that he can safely sign certification documents.
This is totally dependent on the individual organisation. How would the CEO
know that an IT developed core system can be relied on?
It isn't about who developed what, it is about the checks and balances that
are in place for ALL systems.
[color=darkred]
>
> Application isn't difficult because of procedural code or necessarily
> something you want to leave to end users. Pathological events and
> data have to be considered. Relationships have to be considered.
> Coding is the easiest part. It is the analysis, research, control and
> testing that is difficult. It is making sure the external reporting
> and help is clear and that includes the manuals and other
> documentation. (Yes, I know that IT has been less than sterling in
> this regard but documentation and help seems to be an orphan
> regardless of whether the user or IT has the responsibility).
|