Do you mean SMS?
Yes 
Iām not totally sold on the terms ādeparture locationā and ādrop-off locationā.
Is anyone else feeling similar or is it just that I have yet to adjust?
To me, ādrop-offā has historically meant āthe place where parents drop their youngsters off to start the eventā - Particularly since this is going to be cadet facing.
A coach driverās idea of ādrop offā would be the polar opposite of a parentās idea of ādrop offā.
Perhaps ādepartureā and āreturnā; or āreporting locationā and ācollection locationā; or āstartā and āendā might feel more comfortably intuitive?
1 Like
I want to know:
- Where the event is happening, and what time it starts and ends (āevent locationā, āevent arrival timeā, āevent finish timeā)
- Where any centralised transport leaves from, and when (ādeparture location and timeā)
- Where any centralised transport returns to, and when (āreturn location and timeā)
- Where any squadron-organised transport leaves from, and when (ādeparture location and timeā)
- Where any squadron-organised transport returns to, and when (āreturn location and timeā)
1 Like
Your list there looks very much like the one Iām putting together as we speak.
Along with a series of ānotes to organisersā to suggest best practice when creating SMS events.
So far in our area there is still far too much of a requirement for Sqn staff to dig through JIs or AOs to find that basic information needed to push the event to Cadet Portal.
With regards the transport location and time, that will need to be more flexible than the single date/time control currently used, to allow for multiple collections along a coach journey.
Is there a need to include all of that in SMS though? Itās not aimed at replacing the standard organisational documents (JIs, admin orders etc) is it?
Surely the point is to give cadets an overview of where they might have to get to if no transport is provided? As the event arrives, detailed JIs will further develop the transport plan.
Well, this is something which needs to be decided and a policy or best practice guide created.
Currently we are required to enter departure and dropoff locations and times, so I suppose weāre just expanding on that idea towards what is actually required to make it work.
However you are quite right, HQ must also consider whether that should be a requirement at all.
Iād say ānoā. Make those fields optional - Not least of all that would allow events to be pushed to CP whilst details are being arranged.
For Wing events I donāt even consider the coach details until I know where in the Wing the participants are coming from so I simply donāt have departure and ādropoffā details until after Iāve closed the bidding and confirmed the attendance.
However I do think we should provide an overview of the event itself on SMS from which Sqn staff can quickly make decisions.
When calculating an arrival time at the squadron (before getting into the minibus and driving to a wing event) I need to quickly know what time Iām required to arrive with the cadets.
I shouldnāt have to go digging into admin orders for that - it should be there, on the SMS event.
Which also brings us to a point which requires guidance.
There is of course a field for the start time and end time on the main details tab. However, people are often adding ābuffersā to those times to allow for advanced party &c.
E.g. the event starts at 1900 but the advanced party are going to arrive at 1200 - so the SMS event says āstarts at 1200ā.
We need to know whether we are required to enter the earliest duty time (as was implied by our wing when the system first came into use) or whether it is just accepted that staff are going to be moving around on duty at other times as standard.
I favour the latter approach - the SMS time should be the event time and we just acknowledge that staff are working around that to support it.
The idea that if staff are working outside those times then they are not covered for āinsurance purposesā always sounded like BS to me anyway.
I also maintain that, despite what my Wing were pushing, there is not a need for every single event to have a full admin order as an attachment.
Where the details are simple, such as āTurn up at church. Sit on pew. Go homeā an AO is a waste of everyoneās time. Those details can just be recorded in the standard SMS fields. Thereās a whole ādetailsā box there where they can be written.
Itās what Iāve started doing recently and those events have passed the Wing audit so clearly the WExO is happy.
With so much BS, ālocal policyā, and personal habits in place there is no defined standard for these things. Now that we are all required to quickly and easily interpret the SMS details when pushing to the portal there needs to be.
I have admin orders for my routine local activities mostly as a mechanism to define the scope of those activities for my own internal use. That it explains it to others is a bonus.
It neednāt be a complex document but if it covers what, when, where, why and how to dress then you have a central document to refer to and get most of the answers from. More complex activities need more detailed admin orders.
By the way, many of the SMS fields are too small for what can be a relatively complex set of data. For example, the ādressā field can be need quite a lot more than simply saying ā2Aā, even for quite a simple activity. I suppose we could say āsee admin orderā in this field 
I agree.
I think we do need to be careful not to overcomplicate the SMS event, whilst at the same time making sure that we provide the basic details in an obvious way for Sqn staff to find them quickly and easily.
For a big event I always write an AO.
Some in the past (for large, self-run, multi-sqn camps) have spanned a dozen or more pages with various annexes; others have been far simpler, 3 or 4 pages in total.
The ideal being that if I were not around anyone could read the AO and go on the run the event exactly as I have planned it.
For small events I simply donāt bother with the AO and instead include the details on the event itself. The same result can be achieved for those smaller events. Someone can read the details in SMS and get the picture.
From an approverās perspective, I entirely agree with youā¦ as long as the information is there, I donāt care what form it takes, AO or in the details box - however - when approving an activity, in my view, Iām approving the whole thing (including transport, feeding, accommodation arrangements and any other ancillary guff, not solely the technical elements) and in the majority of cases what gets put in the details box is wholly insufficient to describe how the overall event is to be run. Granted we arenāt talking about church services here and Iām at the more complex RtL end of the scale, but that in my view is the purpose of an AO (which can be as short as 1 page for a simple exercise, and much longer for larger ones) - itās a templated guide of what needs to be there to explain the event to a completely independent person who hasnāt been involved in the planning process.
It also has the advantage of helping to demonstrate that appropriate planning and forethought has gone into the event.
We are clearly on the same page on this.
Agreed.
Now when using that description box we need to consider how to best present the information to satisfy two separate, in some areas mutually exclusive, requirements:
- Make it easy for authorising officers to understand the event and to find details in case of emergency.
- Make it easy for Sqn staff to understand the event and to find the details necessary to push to CP.
Where the description box is used in place of an Admin Order the information which is required for authorising is largely superfluous to the individual Sqn staff and is merely seen as clutter which gets in the way of them finding the basic details they need.
Keeping it simple and only providing the basic details is not sufficient for authorising.
We have now hit upon the crux of the issue - the details page which was originally intended for one purpose is now being required to fulfill two.
Where Sqn staff use the ācopy detailsā button they are copying the full administrative details over to the Cadet Portal page, which will then require much amendment.
I wonder is it possible for an event organiser to prepopulate the cadet portal tab so that Sqns automatically get the simplified information which requires less local amendment? I must have a playā¦
Taking off my VSDT hat here (mostly) and pulling on my OC SATT one (tin hat on!).
With the new policy in ACTO10, the only events that need HQ authorisation are.
- LFMT
- FT
- High level PME
- AT
For LMFT and FT, the SST is dictated by Cadet Training Ranges, and the required written instructions are RASPs, RSDs (replacement for RAM) or EASP. These documents are the ones used by SPOs to approve the LFMT or FT. No other document should be required.
For High Level PME, the PME form need to be completed + a risk assessment - this should be all that is required to approve the activity.
That leaves AT - I am not an AT expert, but obvs. a Risk Assessment is required and I would suggest the remaining info for an AT activity would be included in a written instruction of some kind. Additionally if the AT involves travelling (the AT itself, not getting to the AT) then the route map is needed. Iām sure there are others, but they would be dependent on the type of AT.
This to me indicates that the description field is not designed to provided information to authorize the event, and that with the exception of AT specific documents exist that are designed for that purpose. The description of the event should be used for exactly that - a description of what is going to be happening - In my world I tend to make it a description of the shoot and the training objectives.
1 Like
What is LFMT and āHigh Level PMEā ?
I am guessing FT = Field Training and AT = Adventure training
Live firing Marksmanship training
Public Military Event
1 Like
Preach it Brother!
Presumably if the high level PME involves DPs/Swords etc then it will likely require additional written instructions vis a vis security (and probably coordinating instructions)? If I was the approver there I wouldnāt be approving it just on a PME form and an RA.
I thought this was only allowed at a private venue? In which case it wouldnāt be PME
There are a number of armed parades that have been conducted in public.
They are technical documents for LFT and FT in order to comply with the SST. There is nothing to say that you would not also require an AO in order to book/manage other elements of whatās happening. As technical documents they tell me nothing about a lot of the surrounding administration that I would want to know if authorising one of those events.
The SR course folder teaches admin instructions and traditionally you would have expected a RAM and an AO for the very reason I mention above. The same should be applied to RSD although CTR doesnāt state that and Iāve not checked the updated SR course folder.
Sorry, that was my mistake. Not sure why it wouldnāt work but it is now. However when sorting by name it sorts by cadetās first initial rather than first letter of surname?