New Tech. Man.

[Keith Page]

News Break.

 

Just heard Darren Barnfield is our new Tech. Manager.

 

Regards

 

Keith Page.

 

 

[rankamateur]

bet that was a surprise.

 

 

[biggles]

Don't doubt you but nothing on the RAAus website

 

Bob

 

 

[Oscar]

I've heard good reports about Barnfield as having the depth of technical and regulatory knowledge to handle the job and with the recent changes to the Board and Executive, hopefully there will be a highly co-operative (and sufficiently administratively-savvy) atmosphere generated that will get the pressing issues resolved both efficiently and above all effectively. RAA cannot continue to stumble along with IED's (Improvised Explosive Devices) such as the Pacific Ibis situation, confusion and possibly false registration of aircraft at above certificated MTOW etc. blowing up in its path far too frequently.

 

The new Board and Tech Manager probably still need some time to develop both strategic and tactical plans for the future, but I suggest it is an appropriate time to take a really serious look at the whole re-registration system to see how it can be significantly improved. If we are to utilise the Tech. Manager effectively, we must reduce the routine re-registration workload by improving the system so that the time the Tech. Manager has to spend on routine matters is reduced as far as possible and the time available to handle non-routine issues is enhanced. I think it is axiomatic that this will entail the development of an on-line and properly automated system that requires owner self-checking of required documentation (e.g. current photos of placards, certification of correct completion of mandatory mods. etc. ).

 

Developing such systems requires both a high degree of technical expertise of determining the 'Business' requirements (what the system must achieve to pass a process audit) and the 'Technical' requirements (how the system will actually work: database structure, transaction architecture etc.). Then, it has to be built: software development, hardware acquisition and implementation, on-going development and maintenance.

 

Obviously there will be a considerable amount of investment involved. Dare I suggest that a levy be placed on members (or at least owners) to provide the necessary capital? Let's pluck a figure out of the air (no pun intended..) of an initial $100/year for two years. That's less than one decent restaurant meal for two people a year, and I for one would be more than happy to pay that as a deposit on a more secure future for my registration. In theory at least, after the initial development cost, the efficiency of the new system should allow it to be maintained fairly much within the current schedule of registration charges.

 

If we wanted to be even more sophisticated with regard to both the development and the on-going costs of registration, it might be possible to derive a scale of fees (and initial levy) based on the typical workload required for different classes of aircraft - for example, 24-reg. aircraft ought, I suspect, to generally present less of a workload on the RAA Tech area since a considerable portion of things like approval of deviations from standard configuration are the province of the manufacturer. I imagine that 19-reg and 55-reg present (at least potentially) more workload because they are in general terms 'one-offs' for changes/mods./repairs.

 

Do we as a group have the will to grasp the apparent opportunity of the moment for substantial change and put our money where our wishes indicate? I'm not suggesting an immediate knee-jerk reaction here and I'd want to see a rational, cohesive, potentially-effective and well-presented strategic plan coming from the Board and Executive, but I'm very much inclined to suggest that if we as RAA members demonstrate a willingness to provide the resources that will be necessary to implement such a proposal it will give the RAA HQ chaps (and chappettes, if 'chaps' is not considered all-inclusive) a high degree of incentive to progress the formulation of a new and better system with all speed and intent.

 

 

[metalman]

I've dealt with Darren on the rego of my VH exp, good bloke, very switched on and hopefully won't get screwed over by RAA,

 

Matty

 

 

[BPN]

You are correct, still not officially on the RAA website. I have recently had accassion to use Darren's professional services and can only speak highly of him.

 

Straight down the line, no nonnsence, new his stuff, resolved my issues in a timely and professional manner. If he has been appointed our new Tech Manager

 

I wish him well.

 

BPN Broken Hill

 

 

[Guest Andys@coffs]

I don't believe that we need to build a new system from first principles, rather we need to be aware that registration at a system level is technical document handling and workflow and that there are suitable document handling systems that exist today where all we would have to build is the workflow rules, and that in general doesn't require an IT team and/or a software development team but rather some business analysts and specialists in the tool itself.

 

Through exposure in the business Im part of I very much expect that Microsoft SharePoint (a Server based solution) could be made to do what we need if tied back with a OCR engine that links to sharepoint.

 

A lifetime in IT tells me that if we build from first principles we may all well be dead of old age before it matures and fully meets our needs, or, and more likely, well either run out of funding and or change management and direction before it lays an egg......

 

When ever and where ever possible use existing off the shelf solutions changing our business practises rather than foisting current practises into a bespoke software development should be our approach.

 

Andy

 

 

[Guest Crezzi]

When ever and where ever possible use existing off the shelf solutions changing our business practises rather than foisting current practises into a bespoke software development should be our approach.Andy

I also have decades in IT and agree 100%

 

Cheers

 

John

 

 

[coljones]

I've heard good reports about Barnfield as having the depth of technical and regulatory knowledge to handle the job and with the recent changes to the Board and Executive, hopefully there will be a highly co-operative (and sufficiently administratively-savvy) atmosphere generated that will get the pressing issues resolved both efficiently and above all effectively. RAA cannot continue to stumble along with IED's (Improvised Explosive Devices) such as the Pacific Ibis situation, confusion and possibly false registration of aircraft at above certificated MTOW etc. blowing up in its path far too frequently.The new Board and Tech Manager probably still need some time to develop both strategic and tactical plans for the future, but I suggest it is an appropriate time to take a really serious look at the whole re-registration system to see how it can be significantly improved. If we are to utilise the Tech. Manager effectively, we must reduce the routine re-registration workload by improving the system so that the time the Tech. Manager has to spend on routine matters is reduced as far as possible and the time available to handle non-routine issues is enhanced. I think it is axiomatic that this will entail the development of an on-line and properly automated system that requires owner self-checking of required documentation (e.g. current photos of placards, certification of correct completion of mandatory mods. etc. ).

 

Developing such systems requires both a high degree of technical expertise of determining the 'Business' requirements (what the system must achieve to pass a process audit) and the 'Technical' requirements (how the system will actually work: database structure, transaction architecture etc.). Then, it has to be built: software development, hardware acquisition and implementation, on-going development and maintenance.

 

Obviously there will be a considerable amount of investment involved. Dare I suggest that a levy be placed on members (or at least owners) to provide the necessary capital? Let's pluck a figure out of the air (no pun intended..) of an initial $100/year for two years. That's less than one decent restaurant meal for two people a year, and I for one would be more than happy to pay that as a deposit on a more secure future for my registration. In theory at least, after the initial development cost, the efficiency of the new system should allow it to be maintained fairly much within the current schedule of registration charges.

 

If we wanted to be even more sophisticated with regard to both the development and the on-going costs of registration, it might be possible to derive a scale of fees (and initial levy) based on the typical workload required for different classes of aircraft - for example, 24-reg. aircraft ought, I suspect, to generally present less of a workload on the RAA Tech area since a considerable portion of things like approval of deviations from standard configuration are the province of the manufacturer. I imagine that 19-reg and 55-reg present (at least potentially) more workload because they are in general terms 'one-offs' for changes/mods./repairs.

 

Do we as a group have the will to grasp the apparent opportunity of the moment for substantial change and put our money where our wishes indicate? I'm not suggesting an immediate knee-jerk reaction here and I'd want to see a rational, cohesive, potentially-effective and well-presented strategic plan coming from the Board and Executive, but I'm very much inclined to suggest that if we as RAA members demonstrate a willingness to provide the resources that will be necessary to implement such a proposal it will give the RAA HQ chaps (and chappettes, if 'chaps' is not considered all-inclusive) a high degree of incentive to progress the formulation of a new and better system with all speed and intent.

A levy? RAA is sitting on a pile of cash that it has no clue why it has it or what to do with - other than a rainy day. We have had a succession of executives and boards and treasurers who have been incapable of articulating either short term budgets or long term aspirations. A levy - no, not at all. What we need is some common sense and planning not big-noting and chest beating.

 

 

[Teckair]

Dare I suggest that a levy be placed on members (or at least owners) to provide the necessary capital? Let's pluck a figure out of the air (no pun intended..) of an initial $100/year for two years.

I don't think so, why do these sort of ideas get suggested?? The fees will go up all by themselves without any encouragement.

 

 

[fly_tornado]

Even if they had a web based archive for incoming correspondence that would stop the mysterious disappearance of registration documents.

 

 

[Oscar]

Andy, Crezzi - as long-time IT pros, you guys will know probably better than most the old adage: 'you can have it good, or cheap, or quickly - but you can have only one of those options'. Obviously, choosing the right application development platform (or suite of platforms) is pretty much the first step AFTER defining the actual requirement. I've been involved heavily in the development of two national information networks, one 'industry' network, and a Business Process Management system that provided around 75% of the capability of Peoplesoft at a fraction of the purchase cost plus implementation cost of Peoplesoft. I've also been a user and critical observer of one implementation of Peoplesoft that cost many tens of millions of $$ over the purchase cost of the package, and still didn't bloody work properly. That's not my subjective impression speaking - the relevant State Auditor-General went ballistic at not one but two institutions that were caught up in the same financial morass. Meantime, the BPM system I helped developed works just fine, thank you, for a business that is part of a $300M+ annual turnover international company (Worley Parsons, FWIW).

 

If there is a genuinely adaptable package commercially available, then minor tweaks to the way RAA handles registration is a given as the best way forward. However, something that is in effect little more than a document registration/exchange system cannot provide the auditability that will be required to ensure that the relevant regulations are in fact being met - that would take human intervention to review the documentation for each registration, so it would be little more than a baby step in streamlining the workload of registration. It's not sufficient to just ensure that documentation has been delivered; the acid test is whether the documentation supports compliance with changing regulations.

 

My experience with BPM systems is that trying to adapt the specific circumstances of the individual enterprise to any OTS package is the least effective route - assuming that the enterprise itself actually can define what it does and need to continue to do. It ends up as the classic 'horse defined by a Committee' solution (a Camel is a horse defined by a committee, an elephant is a horse to Admiralty specifications, etc.)

 

You simply cannot say 'X package is ideal for this job' until the requirement of the job are established. From all reports, Darren Barnfield has the requisite knowledge to define the requirements, though given his workload he will need support to document these (and that documentation will need to be pre-audited by CASA to ensure they are complete and accurate), evaluate potential solutions and if necessary define the development parameters. A capable IT consultant can then examine and suggest possible complete solution packages / application development candidates and the scope of a project for development. I've been down that path from both the POV of a system development acquisition contract evaluation team leader AND a contractor proposal developer ( i.e. both the 'buyer' and the 'seller' roles -in both cases for complex, expensive systems) and one constant I can guarantee: any pre-disposition to a particular 'product' that existed prior to a detailed system requirements specification, has about a snowball's chance in hell of being a satisfactory answer.

 

RAA seems to me to be in the position of being at the cross-roads of its existence: either grasping the opportunity to become an effective third-tier of aviation activity after RPT and 'GA' as an entity supporting airwork and IFR operation, or conversely relapsing into a highly limited 'just-for-fun' sector. My personal position is that I believe the way forward is to grasp the former concept: that RAA should become the entity that administers compliance with the requirements for a competent (though operationally-limited) sector of aviation. I have no quarrel with those who want the freedom to fly a plastic chair over unpopulated terrain for the joy of that and if the damn thing crashes, well, I chose that end and I didn't harm anybody else. Indeed, I might well join their ranks for a part of my aviation fix.

 

However, there are a significant number of RAA members who invest $100k or more in their aircraft and have a perfectly reasonable desire to be able to use it as a viable means of transport both for 'recreational' and quasi business purposes - which these aircraft are capable of providing. Higher-end RAA-class aircraft are (generally) competent aircraft. With sufficiently competent pilots, they can be the airborne equivalent of delivery vans, taxis, courier service vehicles, tradies utes etc. For those familiar with maritime operations in an area around a major port: think 'water-taxis' (RAA) vs. 'Event' boats - parties, whale-watching, off-shore fishing groups (GA) vs Ferries through to cruise liners: 'Commercial - RPT' services.'

 

The point? RAA can remain as a lowest-common-denominator of aviation activity and survive with simplistic and time-costly basic services or embrace a more sophisticated operational future by investing in suitable systems and people. If it chooses the latter path, then investment in cost-effective systems development is very likely to be mandated. To me it appears that with a largely new Board and a suitable Tech.Manager, RAA has the opportunity to progress; the alternative is to maintain a reduced status quo and reduce the status of sub-GA aviation to billy-cart derby levels.

 

 

[frank marriott]

"an entity supporting airwork and IFR operation"

 

It is already there it is called GA - leave RAA to recreational flying

 

 

[Guest Andys@coffs]

Then we have common background... Ive been involved in Program managing Oracle ERP implementations in previous roles, but these days because I work from home in Coffs for a Company in Adelaide no longer do the heavy management roles that require multiple face to face interactions every day.

 

Your point about not setting sail until requirements are defined is equally true of off the shelf and bespoke software development. Until you know what done looks like your unlikely to arrive there and have a better chance of winning lotto than convincing a team of people that we have all arrived there if there isn't pre defined.

 

Your points around Document management suites is, in my opinion wrong, there are plenty of ways of capturing who made what changes to what over the document history, and in fact by turning on versioning in the tool I mentioned, which I agree is in advance of requirement gathering, will capture all iterations of a document from creation through to final archiving. A point that is valid in an open discussion but as you've suggested is well ahead of the cart that is ahead of the horse. Today in our paper based system we have exactly zero ability to understand who did what to who and when.....and we sure never understand when files go missing in entirety or just bits from them....

 

While ERP,'s like Oracle and Peoplesoft can be very complex and difficult to implement its because they are in many situations whole of enterprise systems...... In the RAAus scenario we don't need a whole of organisation solution (which even if we did RAAus is very small compared to a large corporate or government enterprises) , just a document handling system that can host some workflow and traceability and owner scrutiny......hardly ERP in size......Bespoke would be a disaster for membership funding. Off the shelf is very likely to meet the majority of needs for a sum that isn't anywhere near what the organisation has as reserves....especially if we use a bit by bit delivery process rather than big bang....that may never come. Oracle and Peoplesoft by their nature and tight integration have to be big bang and with that comes big $$$ and people that cost between $1k and $2.5k per day!!! we don't need or want to have to pay that sort of rate. Its my view that we sure don't need MRO or complex MRO capability either (Maintenance Repair and Overhaul or complex MRO which is MRO with full rotable and subcomponent traceability) which I have heard some were suggesting...... Its good to look to the future but it needs to be a near enough future that others can see it and not so far ahead that your the only one seeing it that way.....

 

Today, however I wonder who it is that we have who can document these requirements and review industry solutions and set sail....I fear that the team we have are so busy in the forest with the blunt axe.......

 

Andy

 

 

[Oscar]

Um, Frank, I intended to state that GA was the entity that should control airwork and IFR non-RPT operations; but that RAA-class aircraft and suitably-competent pilots can do some 'commercial' (as defined by CASA) operation in VFR conditions. I'll try to be less obscure in future!

 

 

[frank marriott]

Oscar

 

OK I get what you meant - but even so my belief to even consider RAA doing some AWK that a PPL is not permitted would only open a can of worms and go nowhere - starting with LAME maintenance I would suspect.

 

 

[Oscar]

Andy, I think we are actually singing to the same hymm sheet, just different roles... and I was one of those $1k+/day consultants - but we burn out after a certain time, one can only do the 14-hour days living on coffee and sushi and going to sleep after a full glass of Laphroigh for so long. A bit more than 10 years did it for me.

 

However, and I mean this sincerely - I think we ought to be looking for something more than document registration and change tracking capability. We are seeing increasing occurrences of CASA/manufacturer mandatories being promulgated ( e.g. the Jabiru through-bolts A/D, the Rotax shaft inspection A/D etc.) that need to be distributed to owners and certified as having compliance achieved before new registration can be approved. Unless the registration system can automate documentation of such matters, the workload on the Tech. Manager is not going to be significantly reduced - only the filing of paper documentation task will reduce.

 

I am looking to the implementation of system assistance that allows the Tech/ Manager to concentrate on the 'exceptions', so that exceptional circumstances can be resolved quickly, efficiently and reliably. I believe that if RAA can develop a reliable system to handle the bulk of registrations, it can operate with a small and highly-focused staff to handle the exceptions. That is cost-effective for members in the long run.

 

The recent CASA audits have shown that neither routine registration (including re-registration) nor 'exceptional' registration (such as acceptance of variations to MTOWs or even acceptance of type certification) has been properly controlled to an audit-level inspection standard. I'm not competent to suggest whether this has been a problem of Tech. Manager competence / Tech. Manager resourcing / Executive or Board intrusion into the process - but the results have been fairly cataclysmic for some members. Are there any Pacific Ibis aircraft flying? Are Sting aircraft able to fly two-up much beyond the circuit area? (though the latter may be taken by some as a blessed relief from exposure to possible death.)

 

I think we have to recognise that there is a trade-off between expending resources on development of a system that handles routine registration matters cheaply, efficiently and reliably and continuing to employ a coterie of qualified staff to handle these matters manually. In terms of legal liability, there is no question that auditable compliance with determined standard is the cheapest route; by definition of the requirements to achieve a pass standard for auditable performance of process to meet the requirements, we can assess the suitability of candidate systems (manual or automated) for the task.

 

 

[Oscar]

OscarOK I get what you meant - but even so my belief to even consider RAA doing some AWK that a PPL is not permitted would only open a can of worms and go nowhere - starting with LAME maintenance I would suspect.

Frank - I suspect that the break-point is risk to third parties- those who sit in the aircraft or those on the ground underneath where it might crash. I contend that e.g. a diesel mechanic flying him/herself plus his/her tools and parts out to a remote community to service the local generator that provides the power for water, lighting, domestic and rural services etc.while maintaining full compliance with all VFR regulations can just as well be accomplished by say a J200-series aircraft as a C172 - yet the J2X and a competent pilot is currently denied that opportunity to provide the service. In a ground-limited vehicle analogy: the diesel mechanic couldn't provide the service using a Landcruiser ute, but he could using (and having a licence for) a B-double - even though he's only carrying 50 kgs of tools and parts. That isn't the case for surface transport (as we know) and I doubt there is any statistical argument to suggest that such a limitation should be introduced - and nor is there any realistic basis for an equivalent limitation on RAA aircraft. But that is what we have at the moment. This, I believe, needs to change.

 

 

[Guest Andys@coffs]

Hmmm don't see it that way myself...... We cant do basic in a repeatable manner. Implement a cheap tool that makes basic a synch, get regulator buy in, then in baby steps go looking for more difficult problems to bounce over in a single bound.....

 

AD's to me is a relatively simple tie in of metadata that is attached and collected by the document management system that can then have a workflow attached.....New AD for all Aircraft type X produced between dates Y and Z then providing that X, and the Date of manufacture W is collected at initial registration time it can be reported on and workflow kicked off...

 

But in any event get the basics done first. prove that we have a single master source of data that is controlled, backed up and for DR purposes also stored off site then get down with the fancy stuff because the Techman should have heaps of free time to do just that.....

 

Whether bespoke or off the shelf, put controls in place about who and how we make changes to the system (or to be more blunt, lock out the operational staff from being able to "play") and I think we have the basis of a good start that may well over time grow to being a mini ERP for our organisation.

 

Andy

 

 

[facthunter]

Don't concentrate on the icing, if you don't have a guaranteed cake. GA hasn't sorted that one so why mention it in RAAus. carrying 50 kgs of tools? What plane could do that that is RAAus controlled where most are limited to 544 Kgs? Most have to go on a weight reduction diet and reduce fuel load to fly now. ( legally) Nev

 

 

[TK58]

News Break.Just heard Darren Barnfield is our new Tech. Manager.

Regards

 

Keith Page.

Love to know where you heard that Keith since the Board had not made a decision on Saturday.

 

 

[rankamateur]

Love to know where you heard that Keith since the Board had not made a decision on Saturday.

Well it got an interesting discussion going anyway didn't it.

 

 

[kaz3g]

I don't believe that we need to build a new system from first principles, rather we need to be aware that registration at a system level is technical document handling and workflow and that there are suitable document handling systems that exist today where all we would have to build is the workflow rules, and that in general doesn't require an IT team and/or a software development team but rather some business analysts and specialists in the tool itself.<snip>

When ever and where ever possible use existing off the shelf solutions changing our business practises rather than foisting current practises into a bespoke software development should be our approach.

 

Andy

Someone needs to share that secret with CASA and save us all a mint in regulatory costs

 

Kaz

 

 

[Oscar]

Then we have common background... Ive been involved in Program managing Oracle ERP implementations in previous roles, but these days because I work from home in Coffs for a Company in Adelaide no longer do the heavy management roles that require multiple face to face interactions every day.Your point about not setting sail until requirements are defined is equally true of off the shelf and bespoke software development. Until you know what done looks like your unlikely to arrive there and have a better chance of winning lotto than convincing a team of people that we have all arrived there if there isn't pre defined.

 

Andy - absolutely. To drag our conversation back to the point of the thread, I am suggesting that the combination of the new Board plus the acquisition of Darren Barnfield may well be the ingredients needed to provide both the impetus and the expertise to do something seriously positive in regard to defining what RAA truly needs by way of an improved system. We need to know what has to be done, to what level, and what the cost/benefit model looks like.

 

Your points around Document management suites is, in my opinion wrong, there are plenty of ways of capturing who made what changes to what over the document history, and in fact by turning on versioning in the tool I mentioned, which I agree is in advance of requirement gathering, will capture all iterations of a document from creation through to final archiving. A point that is valid in an open discussion but as you've suggested is well ahead of the cart that is ahead of the horse. Today in our paper based system we have exactly zero ability to understand who did what to who and when.....and we sure never understand when files go missing in entirety or just bits from them....

 

I'd certainly agree that document version security and control is entirely necessary, but of itself just implementing that is most probably (in my opinion) unlikely to provide any auditable surety that actual compliance issues have been addressed. Ultimately the system needs to provide assistance in determining that an aircraft's compliance with the requirement for registration has been met. The reliability/authenticity of the supporting documentation is certainly part of that but in the end it is the status of the aircraft, not the status of the documentation per se, that needs to be demonstrated.

 

While ERP,'s like Oracle and Peoplesoft can be very complex and difficult to implement its because they are in many situations whole of enterprise systems...... In the RAAus scenario we don't need a whole of organisation solution (which even if we did RAAus is very small compared to a large corporate or government enterprises) , just a document handling system that can host some workflow and traceability and owner scrutiny......hardly ERP in size......Bespoke would be a disaster for membership funding. Off the shelf is very likely to meet the majority of needs for a sum that isn't anywhere near what the organisation has as reserves....especially if we use a bit by bit delivery process rather than big bang....that may never come. Oracle and Peoplesoft by their nature and tight integration have to be big bang and with that comes big $$$ and people that cost between $1k and $2.5k per day!!! we don't need or want to have to pay that sort of rate. Its my view that we sure don't need MRO or complex MRO capability either (Maintenance Repair and Overhaul or complex MRO which is MRO with full rotable and subcomponent traceability) which I have heard some were suggesting...... Its good to look to the future but it needs to be a near enough future that others can see it and not so far ahead that your the only one seeing it that way.....

 

Again, I agree with the general thrust of what you say, but I think we need to look at the situation in terms of a useful achievable outcome (or outcomes) and seek to get the best result from what resources can be mustered for the job. Compliance issues is a highly-specialised field and (as we have seen) there is not exactly a large pool of suitable talent out there. We don't have a 'Technical Division' in RAA - nor could we afford one - so what I believe is needed is an approach that maximises the time available to the Tech. Manager to concentrate on the exceptional issues by reducing the time needed to handle the routine, unexceptional ones. If I recall correctly, the actual time availability for just re-registration taken over the entire RAA fleet is something like 15 minutes/aircraft/year? Do we know how many re-registrations are in fact 'unexceptional' in terms of physical compliance (dodgy documentation aside!) - that by simply reducing the Tech. Manager workload by say 10 minutes/aircraft/year, would open up a considerable slice of time for the Tech. Manager to devote to the more complex issues? That's the sort of 'benefit' that, I think, needs to be examined and addressed in scoping the proposed system development.

 

Today, however I wonder who it is that we have who can document these requirements and review industry solutions and set sail....I fear that the team we have are so busy in the forest with the blunt axe.......

 

Yes, it's a resources issue. I suggest that there are two possible streams: one, by drawing in the assistance of volunteers from our ranks who have the necessary ability, and the other by hiring that capability. However, any of us who have been involved in IT system development will recognise the absolute necessity for 'client buy-in' to the project in terms of at the very least a high level of participation in the development of the system requirements statement at the front-end and system testing and acceptance at the back-end of the project. Barnfield (by reputation) appears to be very capable of ensuring that the system definition reflects what it needs to actually do by way of transaction processing and business process rule development; the next link in the chain would be for an IT professional to take that information and develop a system specification that can be taken as the measure against which candidate solutions (OTS or bespoke) can be evaluated.

 

Andy

[fly_tornado]

Love to know where you heard that Keith since the Board had not made a decision on Saturday.

Out of the loop?