Serio Blog

Friday, 14 Sep 2007

Just how good is your backup regime? A colleague here at Serio tells this story.

I managed a direct sales IT system. It was a very busy environment – people asking for new reports, account managers shouting, IT staff either leaving or threatening to leave – and often I simply followed the current crisis (whatever that was), having been in the job for just a few months.

One of my first projects was to move our direct sales system onto a new ‘fault-tolerant’ system. This went well, and I delegated the task of ‘sorting out the backups’ to one of my team who was not in the process of leaving that week. I never thought any more about it (the backups), after all I had delegated it.

One Thursday morning. I came into work at 8:00am as usual, and our new server was making a funny noise, in that when you switched it on it went ‘boing...’, and then refused to boot. With increasing panic, I switched the machine off and back-on, hoping for a boot-up, but all it did was go ‘boing...’. I even tried pushing the 'on' button slowly, like that would help.

An engineer was called, who pronounced the RAID system and one of it’s disks ‘toast – never seen a problem like it’ he said. ‘It’s not that fault tolerant’ he added helpfully.

Worse was to come. I scrambled for the backup, only to find that the entire Oracle database had been skipped from the backup tape because the files were busy, as the database was still active of course. Also by this time customers were phoning, the call centre was operational (in that it had staff answering the phone).

We had £50,000 approx (a usual days trading) of unfulfilled orders. Many orders part-shipped, some ready to go, stock to be booked in things looked grim. How was I going to explain we had no backup, and all was lost? A posse of account managers was waiting outside my office. They looked mean and angry, especially the females.

Just then, ‘the new guy’ came in, who joined us no more that a fortnight earlier. ‘Wassup?’ he says? I explained.

‘Oh, I’ve got a backup here from last night. I couldn’t see any decent backup so I did a full Oracle export to network filestore, using cron to schedule the job’. And sure enough, there it was – I wasn’t going to get fired after all, although I probably deserved it’.

I relate this story for the simple fact that every backup mistake you could make is in this story.

  • Failure to plan for backup and recovery
  • Managerial delegation of responsibility with inadequate checks or verification
  • Over-dependence of ‘fault tolerant technology’ leading to complacency
  • Failure to understand how to backup his software.

I’ll post some information on Monday about the correct way to approach backing up your database system, focusing in particular on SQLServer, the types of backup, transaction log and so on.

(With thanks to AndyW for input).

Tuesday, 11 Sep 2007

This is a follow-up to my earlier post about Change Plan Templates (CPT), which mentioned that the major elements of a Change Plan were

  • Stages
  • Tasks
  • Durations for Tasks
  • Branching
  • Interested parties
  • Special Actions


A Stage is a major (actually, the major) element of a Change process, and will include at least one Task (see below), but will often include a number of Tasks. Think of it this way: take whatever you are trying to accomplish (for example, ‘Server Operating System Upgrade’) and then subdivide this into it’s major parts (such as ‘Authorisation’, ‘Scheduling’, ‘Testing’) and these will typically constitute your Stages.


A Task is simply something that someone does. For instance, an Authorisation Stage (see above) might have 3 Tasks – one for each of the members of the Change Advisory Board (see my previous postings on this subject).

The thing about Tasks is that they should be self-contained – everything that people need to know on how to complete the Task should be included for them (actually, defined when you set-up the Change Plan Template).

Don’t go mad with your Change Plan Template & Tasks

If you are in the process of setting-up a Change Plan Template for the first time, stop for a moment. Are you micro-managing? Micro-management of staff involved in Change is one of the commonest mistakes I’ve seen.

Micro-management will make your CPT much harder to maintain, and may cause your colleagues to view the Change process with disdain. It’s much easier if you assume that those participating in the Change are

  • Properly trained and able to perform their jobs
  • That they have some common sense
  • Are generally supportive of IT Service Management within your organisation

(if it’s not safe to assume these things then you have some work to do outside of Change Management).

To give some examples real of micro-management I’ve seen recently:

A Change involving a software update that had a whole Task for ‘Download patch’ when it was in a vendor website that said ‘click here for latest patch’, and then followed this with a Task for ‘Unzip Patch’.

Change that had a Task called ‘reboot server’ as part of an operating system update.

The above are examples of micro-management because there is series of menial Tasks and a heavy administrative burden, and an assumption that the engineer is too daft to do the job in hand correctly.

Checklists are cool

If you have a Task that requires quite a few things to be done, and you want to make sure that these are all accomplished, the best way to accomplish this is through a checklist. When you set-up the Task, include a simple checklist for those who will be working on the Change. It’s easier to create, and of more value to engineers.

I’ll post about the other parts of a CPT later.

Remember that for full documentation on the Serio Change subsystem, consult the HowTo guide distributed with Serio products.

Friday, 07 Sep 2007

In today's post, I'm going to introduce you to SerioScribe, Serio's screen customisation tool for both SerioClient and SerioAdmin.

Naturally, we've put a lot of thought and research into the design of our screens, and if you're like many of our customers, you'll probably find that you don't ever need to change them.

That said, specific reporting or management requirements occasionally require people to, for example, put additional fields to the logging form. At other times you might want to: streamline forms by hiding fields you never use; adjust the tabbing order according to your data capture process; move fields around; change the labels on fields to conform with your organisation's terminology or to change the use of a field; disable fields to prevent certain users from modifying them, or make others mandatory; change colours/fonts or add special instructions; remove menu options in SerioClient.

A Word of Warning

Don't hack your screens to pieces, hiding fields you just haven't happened to use yet, and leaving the others higglety-pigglety. Also remember that Serio uses industry standard ITIL terminology, so think carefully before changing it. Customisation is like a drug for some people – remember: less is more!


Each Incident received by the Service Desk at WXYZ PLC relates to a particular project. All the projects generate the same types of calls, and WXYZ have set up Problem Areas and Cause Categories to reflect these. As a reporting requirement, they also need to be able record the project code against each Incident. They decide to add a custom lookup field (Project) to the logging form for this purpose.

How to do it!

1.If you don't already have it, install SerioScribe – it's an option in the setup program in the main 'Serio' folder from your Serio software.

2.Choose 'File' > 'Login' to log on to SerioScribe – you can use the same login as you do for SerioClient.

3.Open a new Screen Explorer from the 'File' menu.

4.Look under 'Screen Sets' in the explorer pane. Most Serio installations have at least one Screen Set already set up (usually 'Default'). If you don't have any, right click on 'Screen Sets' and create one.

5.Expanding your screen set, you see that it's divided into SerioClient and SerioAdmin screens. Using multiple Screen Sets, you can create different customisations for different groups of users, but most users only need the one.

6.Expand the 'SerioClient Screens' and select 'Incident Logging'. At this point, you'll notice there's another Incident Logging screen called 'Incident Logging (Incident Management)'. This latter version of the screen is used when you are view Incident details after logging, through 'Manage' > 'Incidents'. The 'Incident Logging' field is shown when logging new Incidents. In this case, we want to apply the change to both versions.

7.At the bottom of the 'Incident Logging' form, you'll see the custom 'Lookup 1' field. Right click on the label, and choose 'Properties'. Change the text of the label to 'Project:', and make the label visible.

8.Now right click on the (white) data entry field, and make it visible – also set 'Must complete:' if necessary. Switch to the 'Lookup' tab page of the properties dialog, and set the Windows Title, Left Column Title, and Right Column Title to 'Projects', 'Project', and 'Project Description' respectively.

9.We're not going to use the blue read-only description field to the right of the custom lookup 1 field this time, so leave it as it is. Drag the label and lookup field, e.g. to the convenient gap between the 'Impact' and 'Received' fields.

Tip: You can multiple select using Shift+Click, and align your selection using the 'Control' menu.

10.Turn on the 'Show Tabbing Order' from the 'Control' menu, and sort out the order that your new field will be tabbed to.

11.Make the same changes as above to the 'Incident Logging (Incident Management)' version of the screen.

12.While you're adding your Project field, you might want to make sure it appears correctly elsewhere. You can have it as a column in the Selected Incidents field. To set the title of this field to 'Project', follow the instructions in the help in SerioScribe. In the help, turn to the 'Contents' tab page and see the topic: 'SerioScribe Help' > 'Common Customisation Tasks' > 'Changing the Issue Monitor Column Headings'. The column headings you need to change in this case are 'Issue Lookup 1' and 'Issue Lookup 1 Description'.

13.You can also set the name on 'Issue Selection Criteria' screen for selecting Incidents. Select this screen in SerioScribe – you'll notice it consists of a number of different 'pages'. Scroll right down to the bottom - the Custom issue lookups are shown on the third page from the bottom.

14.Ok, now you need to make sure that users can see your customisation. In SerioAdmin, open a New Serio Explorer from the 'File' menu. Expand 'Agent' and select 'Profiles'. Open up your profile and look on the 'System' page. Make sure that the Screen Set that you have been working on in SerioScribe is selected where it says, 'Customise the Agent screens using the following screen set'. Apply the same change to the other Profiles.

15.While you're in SerioAdmin, you can define your 'Project' codes. Do so by expanding 'Issue' and selecting 'Custom Issue Lookup 1'.

16.Log out of SerioClient and then back in to see your changes!

Wednesday, 05 Sep 2007

This is a follow-up post to Creating your First Change Plan Template. This post, about a week later than I was expecting, is on the subject of Change Plan Templates generally, and the role they play in the Change Management subsystem.

As always, remember that this blog is additional, bite-sized info to help people get started with something new. The full documentation on Change Plan Templates and the entire CM subsystem is distributed with the tool itself, in the HowTo guide. That’s where you should go for more info.

Change Plan Templates (CPT)

Let’s talk for a moment about Change Plan Templates. If you are trying to use this Change subsystem for the first time, don’t skip this theory – it will help you to understand later articles and put them into context.

I mentioned in the last post on this subject that before approaching the Serio tool you should have a clear idea of what (in a business and procedural sense) you want to do, what problems you might be trying to resolve, and what you want to acheive. What I’m talking about is the standard way you’d like to handle certain types of Changes – what the major steps are, who is involved, and how long it should all take.

The Change Plan Template is where you store this knowledge about the standard process you’ve defined. When you have an actual Change you need to perform, like applying a server operating system patch of some kind, you take the Template and attach it to a Change so that Serio knows how the Change should be handled. In effect, you're taking a CPT and saying 'for this Change, do this'.

A Test or Training Server

If you want to get started remember that you’ll need a Test or Training Server – so you can learn what needs to be done in an environment that is not live, and will not interfere with live operations or reporting. Serio don’t charge for such server set-ups, so all you need is a Windows 2000 or 2003 machine, and a database server (ideally running a test database which is a copy of your live system).

Components of a Change Plan Template

CPTs are quite complex things. If you are starting out, it might help to think of them as a flowchart on steroids. See Figure 1 for a representation of a flowchart in the tool. Change Control

Figure 1 - Change Control (Serio Flowchart)

What you’ll find inside a CPT are as follows.

  • Stages
  • Tasks
  • Durations for Tasks
  • Branching
  • Interested parties
  • Special Actions

I’ll post later with a definition for each of these.

Monday, 03 Sep 2007

This is a follow-up to last week’s post about basic Helpdesk/Service desk call handling. In this article, I’m going to discuss some strategies and approaches you can take if you simply don’t have enough staff to handle incoming call volumes.

Just to recap, the situation I’m addressing is a chronic shortage of Helpdesk or Service Desk staff to actually answer the telephones and deal with customers – and no budget with which to expand the team.


Making sure the phone is answered is arguably  the most important, visible and (for customers) easily discernible functions of the Service Desk. So it makes sense on the face of it to transfer staff from other functions into this customer facing role.

I am aware this may be greeted with resistance, particularly in organisations which are organised along hierarchical rather than project (matrix) lines. Staff can object because posting to customer-facing teams, and away from technical roles, because they see it as a demotion, or dare I say it seems like rather hard work, or because their focus is narrow and they don’t see the need.

If you anticipate resistance, I can suggest a few things to try:

  • Make the secondment period a fixed interval of no more than one month. My personal preference is something like one to two weeks.
  • Ensure all staff, including managerial staff, take a turn  - even of it’s for a shorter period. This is usually a very effective ‘neutraliser’ of staff disquiet.

A word of caution. Don’t second staff without proper training first – and that training should include some test calls. I’ll also advise you to have a Script – which I’ve blogged about here, and here.

Staff Hours/Lunch Rotas/Start Times

One of the things the telephone statistics I mentioned in the last post will tell you if there is a problem with your service times. For instance, if you get calls at 7:30am but your Helpdesk/Service Desk starts work at 09:00 you may need to look at adjusting your service times accordingly.

One thing I’ve noticed is that whilst many organisations (particularly in the UK public sector) have introduced flexible working hours, the impact on essential support services has not always been thought through fully.

As a normal response to this I’d say ‘produce a costed proposal for increased service times’, however as this post was prompted by someone with no extra budget, the only thing I can suggest is to try to re-negotiate start times – possibly by offering something like an earlier start/finish, skipping Friday afternoons – anything to make the prospect attractive.

Make sure also that there is a clear rota in operation over lunchtime, giving you the maximum possible cover. Again you may find that some staff will trade a shorter lunchtime interval for an earlier finish.

Define the Role of Front-Line Staff Carefully.

Are your front-line staff trying to ‘first-time fix’ or simply take and make calls? If you go for attempting fixes for some or all calls, then naturally the amount of time each calls takes is likely to rise. Make sure staff are clear on what you want them to do, and remember you can vary what you do at different times of the day.

If you really are thin on the ground, it makes most sense to me to concentrate primarily on call taking, with resolutions attempts limited to the most simple of things such as password resets. 

Wednesday, 29 Aug 2007

I’m prompted to write today by a customer who doesn’t have enough staff on their Service Desk/Helpdesk taking calls from customers, and who is looking for any strategies to help cope with this. The business is both outbound and inbound sales order processing, with a user base in excess of 500.

My first response, naturally enough, is to suggest recruiting more staff. However, our customer is adamant that there is no budget for this.

So where do you start?

First of all, you need to understand what your current position is – just how understaffed on the front-line are you? You can normally find this out from your telephone statistics (yes, if you ask the right people you can get statistics from your telephone system).

There are a few Key Performance Indicators (KPIs) you need to look at in this regard:

Number of rings before pickup. My opinion is that anything below 6 is OK, anything above 10 is poor. Look at the average and standard deviations. Ideally you’ll get this in graph form. This is because incoming call activity for Helpdesks and Service Desks exhibits natural spikes of activity at different times of the day and week.

Call Abandonment Rate. This is the number of calls where the caller has given up, and not surprisingly it’s linked to the number of rings before pickup. You can think of this as the number of unhappy and dissatisfied customers you’ve had, and is a major KPI.

Voicemail cleardown. If you use voicemail (for instance, it kicks in if all lines are busy, or picks-up after a number of rings) then this can muddy the waters somewhat. What you need here is the number of voicemail messages left, and the time taken (again displayed in graph form) to delete a message (deletion usually being an indication that the message has been actioned). The reason I say that it can muddy the waters is that is either replaces or distorts the Call Abandonment Rate KPI I mentioned earlier.

These three statistics will give you your current position in terms of call volumes.

I’ll post later about strategies for dealing with this, but before I do that I just want to issue a word of caution. There seems to be a tendency amongst Service Desk Managers to play-down the importance of telephone statistics (‘they can log it through the web, so what's the problem?’), but I think this is a bad attitude. If you offer a telephone service it should be ‘fit for purpose’. In addition to this, some users prefer to speak to someone particularly if the Incident is important to them.

In the case of the customer who prompted this article, it might be a front-line sales advisor who needs to earn commission on sales, but is having problems with their IT system and wants to speak to someone. Whatever the situation, customer perception will be damaged no matter good other service provision might be.

Monday, 27 Aug 2007

This week, I’m going to look at how you go about creating your first Change Plan Template. Before that, it’s probably time for a recap.

I’ve been blogging about Change Management recently. The recent posts have covered subjects such as Change Management Definitions, Change Management Scope and Change Management Process, all in an effort to ‘set the scene’.

The Change Plan Template I mentioned above this the name we give to the whole process you enter into Serio – it defines the tasks, what is meant to happen when, standard times, exception handling – everything you would expect to be included in a standard Change. As always, for full information and documentation, please consult the HowTo guide which is distributed with Serio products – you’ll find an entire book there documenting the Change Management subsystem.

There seems to be a temptation to simply sit down in front of the Change Explorer in Serio and try to ‘create a template’. This is not the right approach! Before approaching the tool, you need to have a clear idea of what process you’ll be following, what will be involved, who is participating, what your reporting will be, and have some agreement with colleagues.

In reality then, you should have something written down before approaching the tool. This might take the form of a simple flowchart or a textual description. Whatever you decide upon, it will be something you can visualise before approaching the Change Template editor.

Working with Affected Teams

One of the big challenges facing a Change Manager is the fact that he or she might be changing the way that individuals and teams work both with themselves and with each other. The most obvious example of this is when there is no Change Management process in place at all, and so staff that have been able to entirely control whatever tasks they perform suddenly have a process ‘imposed’ on them, causing ill-feeling and conflict.

It’s usually advisable for the Change Manager to work with affected teams. My advice to customers is to avoid working with the team as a whole, but to select one ‘Champion’ or ‘representative’ to work with the Change Manager in developing a process, who can make decisions on behalf of their team (my experience has been that large groups are not good at decision making).

In summary, Change Managers have to be able to work effectively and communicate well with different groups, and handle situations calmly where people don’t see eye-to-eye. It’s not something you can do isolation (though I know some that have tried).

I’ll post later in the week about the key parts of a Change Plan Template.

Tuesday, 21 Aug 2007

This is a follow-on from last week’s post on the subject of Change Advisory Board (CAB, or sometimes Change Board for short) meetings. This post is going to be on the subject of the meetings themselves, and concentrate on some of the pitfalls and look at some ideas I’ve used.

Firstly, the meeting needs to have an effective chairman or chairwoman – ideally the Change Manager. Except to have to spend at least a few hours beforehand preparing, and be clear about how you wish to handle the meetings. If you are new to the role, ask colleagues to allow you to role-play before your first ‘actual’ meeting.


People will be more willing to attend CAB meetings if you develop a reputation for strict timekeeping early-on. Be punctual – if the meeting is for 10:00, book the room from 9:45 so you’ve got time to clear the laggers out who may still be there at 9:50, giving yourself time to be ready to start at 10:00.

Work out a timed agenda. For example, if you have 20 Changes to examine, and 60 minutes in which to do this, it means that each Change warrants 3 minutes. You can also use a grading system, where more complex Changes get 5 minutes, and more simple or straight-forwards were allocated 2 minutes.

My approach was to have variable length meetings, ranging from 1 to 2 hours. 2 hour meetings had a built-in break at the 1 hour interval. When invites were made to the meeting, I stated the duration (the actual duration being driven by the number of Changes under consideration). I also had a clock which I brought into the meeting and placed on the table in front of me.

My own feeling is that no meeting should go over 2 hours. If for some reason the work could not be concluded within two hours I’d adjourn for another day.


Some companies routinely minute Change Board meetings. I’ve never felt the need for this, but if you do want minutes make sure that someone is there whose sole responsibility it to take and distribute minutes – don’t assume that it’s the job of the Change Manager (something I have recently seen at a customer site). The Change Manager will have enough to do.

Recording Outcomes

If you are going to have any chance of sticking to your timetable, have simple outcomes to the consideration of Change: Accept, Reject, Defer. In each case you’ll want to record notes and comments from your colleagues (particularly in respect to scheduling). Deferment simply puts the Change into a ‘holding pattern’ for the next CAB meeting.

Some companies use a formal sign off document. I’ve tended to go for something less formal – giving each member a tick list, with a description of the Change, an Accept/Reject/Defer tick box and a small space in which to write comments.


It’s normal and healthy to have the membership of the CAB meeting alter during the meeting, as different members step in and out according to the Changes under consideration (which you would have streamed accordingly beforehand).

If people don’t get up to leave when they should, remind them with a gentle ‘thanks for coming, that’s all for you’. Smaller numbers, with relevant interest, will help you hold a successful meeting.

Before the Meeting

Send a summary of what is going to be discussed, and your forward schedule of Changes due to be actioned over the next month (or so). Don’t expect everyone to read it – some will pay great attention, others won’t look at it until the meeting starts. You can usually guess how it will be for different groups, and so is something you can factor into your time estimates.

Have spare print-outs ready for everyone.

Stick to the Agenda

Be ruthless in steering conversation away from this week’s hot issue to the items on the Agenda.

After the meeting

Send a concise summary of the outcomes reached, and estimate when the next meeting will be. 

Friday, 17 Aug 2007

What you save on the swings might be lost on the licensing roundabouts writes Tracey Caldwell

Hardware and software are getting divorced or at least having an open relationship if the excitement around virtual environments anything to go by. For believers, the benefits of virtual environments are anything but intangible. For the uninitiated, if there are any left, virtualisation allows computers to run multiple operating systems simultaneously in different partitions called virtual machines. A single server can replace several and software tasks can be moved around from one server to another.

The possibilities seem endless for IT teams: running different operating systems on one machine, making backup copies while trying out different scenarios and installing patches, backing up employee PCs. Support teams meanwhile are shuddering in horror at the flipside of unregulated and constantly shifting software environments causing havoc with hardware and networking set-ups.

Sceptics might also think that hard disk manufacturers must be loving the explosion of interest in virtual environments but the Ethernet savvy can even run an entire virtual SAN. Collect green points too for switching off the power to multiple real world servers and running multiple virtual servers on one hardware platform.

Virtualisation company VMWare is hot property at the moment as parent company EMC issued 10% of VMWare as shares on the New York Stock exchange on Tuesday. The shares were reported to have shot up in value 76% in one day. Intel and Cisco have already grabbed a slice of the action with six figure injections of cash into VMWare announced in July.

In this virtual world Macs can become PCs and VMWare launched the VMFusion virtualisation product for Apple Macs at the beginning of August against the market leading Parallels Desktop 3.0 for Mac product which was promptly put into beta. VMWare is not the only player in the virtual world of course, with SWsoft’s Virtuozzo, Microsoft Virtual Server and open source Xen generating much real world interest.

Every silver lining must have its cloud though and there have been rumblings, mainly around the idea that the costs saved on the swings are lost on the licensing roundabouts. Security is an issue too with some commentators pointing to improved security through virtualisation while others throw their hands up in dismay at the thought of securing multiple free ranging operating systems.

Computer Weekly’s Cliff Saran has highlighted licensing issues in his blog, pointing out that some companies like Oracle and IBM don't recognise software partitions in their licensing, meaning licences have to be bought for each virtual server.

The licensing issue also threatened to get in the way where companies are buying into hosted software as a service. VMWare has just ticked that box by publishing a licence model for hosting companies to offer services based on the company’s virtualisation software. It will charge a monthly fee, as an alternative to the model that forces hosted service providers to pay the same rate for virtual servers, regardless of how many are operating at any one time. 

Thursday, 16 Aug 2007

My post today is on the subject of the Change Advisory Board (CAB). For many involved in IT the name alone is enough to send people running to hide under their desks, conjuring up images of Sir Humphrey-type obfuscation and bureaucracy.

Of course, it can be exactly that – if you don’t plan it correctly, or have an effective chairman. Approached with a little planning and common sense most of the pitfalls can be avoided.

I’ll start by discussing it’s role, and then discussing if the work of the CAB should be on-line or in a meeting over tea. I'll post next week with some ideas for how to host the meeting.

In my earlier post, I described some of the things that might constitute a Change Management process. One of these involves the Change Advisory Board. The basic function of the CAB is to bring a business and user focus to IT Change by involving users in the approval, prioritisation and scheduling of IT change.

In Person or On-Line?

I’ll start by a trend I’ve noticed here amongst our customers here at Serio – using web collaboration to execute authorisations and rejections of Changes. For Serio Service Desk users, this means enabling the authorisation of Changes through the web. In this scenario, the CAB never actually meets. Instead, when Changes require authorisation the members of the CAB are emailed, they log-in and either authorise, reject or defer Changes.

The advantages are clear: if frees up time in people’s calendars, work can be undertaken at times that are flexible (as opposed to a meeting which is more rigid) and offers the potential for things to happen more quickly (because we aren’t always waiting for the next meeting).

Despite all this, I nearly always advise customers that I am working with the have old-fashioned, sit down, face to face meetings if at all possible. My reasons for this are that it encourages better inter-disciplinary and inter-departmental relationships, and it gives people a chance to air concerns off the record, or informally, that interaction through email or a system like SerioWeb does not. Also, if gives the Change Manager (who will normally chair the meeting) a chance to gauge mood and understanding (end users can sometimes be reluctant to say ‘I don’t understand this’).

Of course, you may also get free tea, coffee and cakes in a face to face meeting.

If your volumes dictate that On-Line is the only option, try streaming your Changes into something like ‘routine’ and ‘significant’. Allow routine Changes to be done on-line, whilst reserving the significant Changes for meetings.

As I said, I'll post next week about the meetings themselves.