I passed!
Yep, I got my letter on Wednesday confirming that I had passed the Practitioner exam.
I am chuffed, but not surprised. I knew the day I wrote the paper that I would pass it, but it is nice to have it confirmed in writing.
Of course, it's also nice to use the principles in day-to-day project work, it's REAL value lies in my increased credibility if and when I decide to seek employment elsewhere.
Saturday, November 25, 2006
Condor approved !
My portion of project Condor - the mainframe back-end bit - was granted formal approval this week. Even better, since Condor is currently the only approved project planning to build and utilise web services, I have been given additional funding to implement whatever web services Condor requires.
My total budget is now £1.6 million - more than enough, I think. It should give me plenty of flexibility to not only design services specifically for Condor, but also services that the current web application can use. After all, that is the point of web services - re-use.
This is an exciting time. It's going to get really busy really quickly.
I need to build up two teams - one for the mainframe work and one for the web services work.
I need to create a detailed project plan, draft a Terms of Reference, establish a project Board, define a stakeholder map, and a million other things that a project requires just to start functioning.
I love this part of a project - it's exciting. It's all about possibilities, and nothing has gone wrong... yet.
My total budget is now £1.6 million - more than enough, I think. It should give me plenty of flexibility to not only design services specifically for Condor, but also services that the current web application can use. After all, that is the point of web services - re-use.
This is an exciting time. It's going to get really busy really quickly.
I need to build up two teams - one for the mainframe work and one for the web services work.
I need to create a detailed project plan, draft a Terms of Reference, establish a project Board, define a stakeholder map, and a million other things that a project requires just to start functioning.
I love this part of a project - it's exciting. It's all about possibilities, and nothing has gone wrong... yet.
Contractors - the forgotten learning curve
As with most big organisations, we have a large number of contractors. Officially, we do this to 'flex' our capability, increasing the headcount with contractors to meet demand over peak periods and releasing them when demand is low. With a lot of those contracts soon to expire, we are once again having to carefully consider whom to renew and for how long. Obviously we need projects on the workstack to justify - and pay for - these people. The problem is that there is currently not sufficient authorised work to justify keeping them on. This is a deficiency in the planning process, as by the time we DO get authorisation to build the teams for these projects, we will already have let some of our people go, and will need to get others in to replace them.
Contractors are generally viewed by HR and senior management as just 'pluggable' resources. Expendable people who can be acquired and discarded at two weeks notice for whatever task we need. The truth is quite different. The reality is that some of these contractors are a lot better than any of the permanent employees, and their knowledge and skills become very valuable. We have accumulated a number of such people who have been here a number of years; the best are usually renewed ad infinitum..
Current thinking does not take into account the knowledge of the applications that the contractors have built up during their time here. While the hard skills of design, coding and testing can easily be replaced, knowledge of how your applications work cannot. The learning curve required to get a new contractor up to 100% productivity can take anything from a few weeks to a number of months, depending on the size and complexity of your systems. No-one factors that into their resourcing models.
Contractors are generally viewed by HR and senior management as just 'pluggable' resources. Expendable people who can be acquired and discarded at two weeks notice for whatever task we need. The truth is quite different. The reality is that some of these contractors are a lot better than any of the permanent employees, and their knowledge and skills become very valuable. We have accumulated a number of such people who have been here a number of years; the best are usually renewed ad infinitum..
Current thinking does not take into account the knowledge of the applications that the contractors have built up during their time here. While the hard skills of design, coding and testing can easily be replaced, knowledge of how your applications work cannot. The learning curve required to get a new contractor up to 100% productivity can take anything from a few weeks to a number of months, depending on the size and complexity of your systems. No-one factors that into their resourcing models.
Friday, November 17, 2006
Being ill sucks
The worst part about being ill is worrying about what's happening at work while you're not there.
Or is it that illnesses seem to coincide with lousy weather, so you can't even enjoy being off work?
No, the worst part is not having any good books to read while you're ill.
No, the worst part is the offerings on tv during the day.
Actually, no the worst part is hearing all the neighbourhood dogs going nuts every time somebody walks past the fence. Especially when you're trying to sleep.
Aaaarrgh! I'm bored!!
Or is it that illnesses seem to coincide with lousy weather, so you can't even enjoy being off work?
No, the worst part is not having any good books to read while you're ill.
No, the worst part is the offerings on tv during the day.
Actually, no the worst part is hearing all the neighbourhood dogs going nuts every time somebody walks past the fence. Especially when you're trying to sleep.
Aaaarrgh! I'm bored!!
Interview: What's your biggest weakness?
Have you ever been asked about your weakness/es in an interview? How did you answer? Did you blab something meaningless about paying too much attention to detail, say with a completely straight face that you don't have any, or did you laugh and say you have a weakness for Belgian chocolate?
This article in CNN's Money column presents some advice on the subject, which is promptly castigated as "exceptionally bad advice" by Mark and Mike at Manager Tools. I can't wait to hear what they have to say on the subject.
This article in CNN's Money column presents some advice on the subject, which is promptly castigated as "exceptionally bad advice" by Mark and Mike at Manager Tools. I can't wait to hear what they have to say on the subject.
Wednesday, November 15, 2006
Don't manage my expectations
The term 'managing expectations' has seemingly come into more and more frequent use around here lately. It seems to mean ensuring that someone does not expect too much, to avoid disappointment later. I have heard project managers talk about "managing business expectations" in the sense that they are probably planning to deliver less than the business asked for. When used in a third-person context, when both parties understand that it's not their expectations that are being managed, it's probably a good thing to do.
But I heard the term mentioned at a meeting the other day in a way that made me cringe! A programme manager said to someone at a higher level than himself "... I just want to manage your expectations here...".
If I had been the recipient of that remark, I would have been more than a little peeved - more so if that person was my subordinate. How do you know what my expectations are, and how dare you suggest that you are somehow managing them?
I know he did not mean to cause offense, but it could have been expressed better.
But I heard the term mentioned at a meeting the other day in a way that made me cringe! A programme manager said to someone at a higher level than himself "... I just want to manage your expectations here...".
If I had been the recipient of that remark, I would have been more than a little peeved - more so if that person was my subordinate. How do you know what my expectations are, and how dare you suggest that you are somehow managing them?
I know he did not mean to cause offense, but it could have been expressed better.
Tuesday, November 14, 2006
Creating a Productive Environment
I am guessing that, if you are reading this, you are working in a knowledge-based business area. The value that you provide to the company you work for lies in the knowledge and experience you have, more than in what you do/produce. The people you employ are required to think more than anything else. This is especially true in an IT environment. It stands to reason therefore, that it should be incumbent upon the company to provide an environment conducive to productive thought and communication.
But how many do? How many of you work in open-plan offices in which at least one telephone seems to be ringing at any given moment? Where other people's conversations and clicking keyboards vie for your attention, and you try desperately to demote everything to background noise? Ever wondered why so many of your staff work with iPods plugged into their ears? Wonder no more! But this is nothing compared to the worst offender of them all.
Think of a time in your project where your best people were at their most productive, generating complex designs or program code, brainstorming ideas, or trying to resolve testing defects. Now just at that point where productivity is at it's highest.....
TTTTTTTRRRRRRRRIIIIIIINNNGGGGGGGGG.
The fire alarm goes off. No, the building is not on fire, it's just the regular weekly test, scheduled at exactly the point where people are busiest - mid-morning.
Some time ago, being below the level of authority required to change such things, I nevertheless tracked down the person responsible for the fire alarm tests, and asked if they could be conducted out of hours, so as not to disrupt people's work. The answer I received was that it needed to be tested during the day so that as many people as possible would know what it sounds like, so that they will recognise the real thing(!). As if anyone could mistake it for anything else.
Please, people, if you have any control whatsoever over this sort of thing, please give your people the environment in which to do what they do best.
But how many do? How many of you work in open-plan offices in which at least one telephone seems to be ringing at any given moment? Where other people's conversations and clicking keyboards vie for your attention, and you try desperately to demote everything to background noise? Ever wondered why so many of your staff work with iPods plugged into their ears? Wonder no more! But this is nothing compared to the worst offender of them all.
Think of a time in your project where your best people were at their most productive, generating complex designs or program code, brainstorming ideas, or trying to resolve testing defects. Now just at that point where productivity is at it's highest.....
TTTTTTTRRRRRRRRIIIIIIINNNGGGGGGGGG.
The fire alarm goes off. No, the building is not on fire, it's just the regular weekly test, scheduled at exactly the point where people are busiest - mid-morning.
Some time ago, being below the level of authority required to change such things, I nevertheless tracked down the person responsible for the fire alarm tests, and asked if they could be conducted out of hours, so as not to disrupt people's work. The answer I received was that it needed to be tested during the day so that as many people as possible would know what it sounds like, so that they will recognise the real thing(!). As if anyone could mistake it for anything else.
Please, people, if you have any control whatsoever over this sort of thing, please give your people the environment in which to do what they do best.
Taking on the Load
I am currently being torn between the desire to take on as much of the Condor project work as I can get (I love a challenge), and the opposing need to limit our involvement to what can be achieved within the current budget and resource capability.
You see, ever since this project somehow acquired the target of a mid-2007 delivery date (I am still unsure how that happened), the focus has been on 'how can we deliver this quickly?'. It is no longer 'my' project, and I will be managing only a portion of it. Disappointing. It is also clear that, since our business area has the requirements, and our development team have the expertise, the key to rapid design and build is probably to utilise what has gone before as far as possible. I am therefore tempted to take on as much work as I can get away with, but I am under strict instructions to preserve the other projects on the portfolio. In other words, I can utilise only those people not already allocated to higher-priority projects.
You see my problem. To be fair, when I asked if I could expand my present scope and the number of resources assigned, provided it did not affect other projects, I was told that was fine, as long as TPC pay for it.
We must, however, be seen to make the maximum effort to meet this (frankly unrealistic) target. To that end, we need to come up with ways to make most efficient use of the standard project methodology, modifying things where necessary, and re-use as much of the current intellectual and software capital already in place. The current method - sorry, framework - assumes a waterfall approach to managing the phases of a project. A set of requirements is delivered by the Business, an application design is created, followed by an Infrastructure design, followed by build.... you get the picture.
We are going to have to adopt a more overlapping approach to things, specifying dependencies at a much lower level. I have already suggested that we adopt a JAD approach to the requirements definition phase. I envisage defining requirements categories, each being specified in parallel, but not wholly in isolation, with significant IT involvement, since the so-called business analysts don't actually have any analysis training.
We will also need to combine the design phases, producing application and infrastructure designs in parallel.
Any of you managers used to delivering software projects will recognise the challenges inherent in meeting a mid-2007 deadline with an estimated spend of £6m. We need to get a quite phenomenal 'burn-rate' to obtain that sort of productivity.
You see, ever since this project somehow acquired the target of a mid-2007 delivery date (I am still unsure how that happened), the focus has been on 'how can we deliver this quickly?'. It is no longer 'my' project, and I will be managing only a portion of it. Disappointing. It is also clear that, since our business area has the requirements, and our development team have the expertise, the key to rapid design and build is probably to utilise what has gone before as far as possible. I am therefore tempted to take on as much work as I can get away with, but I am under strict instructions to preserve the other projects on the portfolio. In other words, I can utilise only those people not already allocated to higher-priority projects.
You see my problem. To be fair, when I asked if I could expand my present scope and the number of resources assigned, provided it did not affect other projects, I was told that was fine, as long as TPC pay for it.
We must, however, be seen to make the maximum effort to meet this (frankly unrealistic) target. To that end, we need to come up with ways to make most efficient use of the standard project methodology, modifying things where necessary, and re-use as much of the current intellectual and software capital already in place. The current method - sorry, framework - assumes a waterfall approach to managing the phases of a project. A set of requirements is delivered by the Business, an application design is created, followed by an Infrastructure design, followed by build.... you get the picture.
We are going to have to adopt a more overlapping approach to things, specifying dependencies at a much lower level. I have already suggested that we adopt a JAD approach to the requirements definition phase. I envisage defining requirements categories, each being specified in parallel, but not wholly in isolation, with significant IT involvement, since the so-called business analysts don't actually have any analysis training.
We will also need to combine the design phases, producing application and infrastructure designs in parallel.
Any of you managers used to delivering software projects will recognise the challenges inherent in meeting a mid-2007 deadline with an estimated spend of £6m. We need to get a quite phenomenal 'burn-rate' to obtain that sort of productivity.
Saturday, November 11, 2006
Condor to be outsourced.
A workshop was held yesterday, the purpose of which was to work out an action plan for the next 30 days. Why 30 days? Well, that takes us to virtually the end of the year.
The new programme manager for Condor, E, said that in order to have even the remotest chance of getting this project implemented by mid-year, we need to have some requirements and some high-level designs by the end of this year. And he's right! So what do we need to to do achieve that?
The group identified several separate work streams - Requirements, Design, Testing, Business Operating Model, etc. A team leader was appointed to each, and other people allocated to each work stream according to who the group felt was best suited to performing the tasks identified in each. It's a decent enough approach. For me the biggest disappointment of the day was seeing representatives from an outsourcing company in India present. It is obvious that E has already made the decision to outsource a large amount of the development work.
The end of the meeting was by far the most revealing.
On a flip chart, someone drew a mini Gantt chart showing, against the project timeline, the major activities and milestones that we would need to hit to make the plan work. The level of overlap between activities made it obvious that, either we were simply not going to do it, or we were letting ourselves in for the mother of all managerial nightmares.
E finished up the meeting by saying that while it appeared as if the plan was... um... challenging, he was not prepared to go back to his boss and say it was not do-able, until the various work streams generated the estimates to prove it. Smart cookie. E is no fool, and is obviously a very experienced and competent manager. He is surrounding himself with people he trusts and who he knows can do the job.
The new programme manager for Condor, E, said that in order to have even the remotest chance of getting this project implemented by mid-year, we need to have some requirements and some high-level designs by the end of this year. And he's right! So what do we need to to do achieve that?
The group identified several separate work streams - Requirements, Design, Testing, Business Operating Model, etc. A team leader was appointed to each, and other people allocated to each work stream according to who the group felt was best suited to performing the tasks identified in each. It's a decent enough approach. For me the biggest disappointment of the day was seeing representatives from an outsourcing company in India present. It is obvious that E has already made the decision to outsource a large amount of the development work.
The end of the meeting was by far the most revealing.
On a flip chart, someone drew a mini Gantt chart showing, against the project timeline, the major activities and milestones that we would need to hit to make the plan work. The level of overlap between activities made it obvious that, either we were simply not going to do it, or we were letting ourselves in for the mother of all managerial nightmares.
E finished up the meeting by saying that while it appeared as if the plan was... um... challenging, he was not prepared to go back to his boss and say it was not do-able, until the various work streams generated the estimates to prove it. Smart cookie. E is no fool, and is obviously a very experienced and competent manager. He is surrounding himself with people he trusts and who he knows can do the job.
Communicating with staff
Apparently, UK companies are generally not very good at communicating with their junior employees. Gee, now there's a surprise.
Even in my company, where senior management have made a serious attempt to improve communications, morale and staff engagement, there is room for improvement.
There are a number of factors that help or hinder the process:
Have a good weekend everyone.
Even in my company, where senior management have made a serious attempt to improve communications, morale and staff engagement, there is room for improvement.
There are a number of factors that help or hinder the process:
- Is communications one-way or is there a forum for staff to generate ideas?
- Are those ideas considered by senior managemet and the good ones implemented! Only if staff believe that their contributions have a chance of making a difference will they feel encouraged to contribute in the first place.
- Are ideas filtered or prioritised? If so, how? I once participated in a session in which some really good ideas came up, but were discarded by the facilitator, because in his opinion they were either too costly, or would take too long to implement. There was pressure on him to select only a few ideas out of the many that were generated, and he selected the ones that were easiest to implement, not the ones that would generate the most benefit. It is important that contributors feel that their ideas are getting a fair hearing, and discarded only because someone else has a better idea.
Have a good weekend everyone.
Over budget is fine
"When it comes to project finance, there are only two states that raise concerns in my mind," said my Boss to S, our newbie PM.
"One - you come in exactly on budget. That says you are being very creative with the figures and are managing the budget not your project. And Two - you come in under budget."
Wait a minute - under budget doesn't concern you?
Yep. In an organisation like ours, in which project costs comprise solely the man-day rate applicable to the people working on the project, if you get the number of people right and the duration of the project right, you should come in pretty darn close to your budget. Easy.
If you come in under budget, you have over-estimated. If you are a little over-budget (within contingency), you have done your job. If you are a lot over-budget, you didn't do your job properly, because you did not get authorisation for the additional spend - change control, dummy!
The 'fun' part of managing IT projects around here is in dealing with all the minor crises that inevitably arise that cause your beautifully crafted plan to gradually evolve into something virtually unrecognisable from the version that was originally approved.
"One - you come in exactly on budget. That says you are being very creative with the figures and are managing the budget not your project. And Two - you come in under budget."
Wait a minute - under budget doesn't concern you?
Yep. In an organisation like ours, in which project costs comprise solely the man-day rate applicable to the people working on the project, if you get the number of people right and the duration of the project right, you should come in pretty darn close to your budget. Easy.
If you come in under budget, you have over-estimated. If you are a little over-budget (within contingency), you have done your job. If you are a lot over-budget, you didn't do your job properly, because you did not get authorisation for the additional spend - change control, dummy!
The 'fun' part of managing IT projects around here is in dealing with all the minor crises that inevitably arise that cause your beautifully crafted plan to gradually evolve into something virtually unrecognisable from the version that was originally approved.
Thursday, November 09, 2006
Planning to Fail
When I posted (here and then here) that I was sceptical about the plan to deliver Condor in 6 months, it now appears that I was not the only one. At a meeting earlier this evening, it transpired that I am being instructed to limit our involvement in the project not only to protect the other projects on the portfolio - although there is an element of that in the mix - but also to limit the damage should the project fail.
It was even suggested that the web front-end component should be outsourced to India. This would have two benefits - relieving us of the need to resource it ourselves, and providing someone else to blame when the plan slips.
The fact that The Parent Company is willing to fund and resource a large part of this project means that our part of the company is happy for them to go ahead and get their noses bloodied, while we merrily go on delivering the other planned projects on our workstack.
Why can they not create a realistic and workable plan to succeed, rather than playing political games to limit the damage of failure? Perhaps the fallout from the US mid-term elections has had consequences far beyond the boundaries of the United States, in ways no-one predicted.
This project is starting to get a distinctly nasty smell attached to it.
It is situations like this that make me glad I am publishing these comments anonymously.
It was even suggested that the web front-end component should be outsourced to India. This would have two benefits - relieving us of the need to resource it ourselves, and providing someone else to blame when the plan slips.
The fact that The Parent Company is willing to fund and resource a large part of this project means that our part of the company is happy for them to go ahead and get their noses bloodied, while we merrily go on delivering the other planned projects on our workstack.
Why can they not create a realistic and workable plan to succeed, rather than playing political games to limit the damage of failure? Perhaps the fallout from the US mid-term elections has had consequences far beyond the boundaries of the United States, in ways no-one predicted.
This project is starting to get a distinctly nasty smell attached to it.
It is situations like this that make me glad I am publishing these comments anonymously.
Friday, November 03, 2006
Appraisal time again.
Am I the only person who finds the process of self-appraisal very difficult?
It is, of course, that time of year again, and we are being asked to complete our self-appraisal forms, as well as for those we are assessing.
In my case, I had a load of people to do mid-year, but most of them do not seem to have asked me again at the end of the year - a sign I don't do it well? Anyway, I also have the time available at the moment to give it a good go. The only problem is that, having spent the last ten years as a contractor, I am out of practice at this self-appraisal thing.
There are two reasons I find this process difficult:
So, despite reading the best advice on the subject I can find, I still find it difficult.
It is, of course, that time of year again, and we are being asked to complete our self-appraisal forms, as well as for those we are assessing.
In my case, I had a load of people to do mid-year, but most of them do not seem to have asked me again at the end of the year - a sign I don't do it well? Anyway, I also have the time available at the moment to give it a good go. The only problem is that, having spent the last ten years as a contractor, I am out of practice at this self-appraisal thing.
There are two reasons I find this process difficult:
- I find it difficult to 'blow my own trumpet', even though I know it's a very necessary part of managing my own career. Where do you draw the line between just-doing-my-job and going-above-and-beyond? At my grade, I am supposed to be doing things I am not getting the opportunity to do, and I do not believe I am doing anything special.
- There is a sizeable part of me that thinks this will have absolutely no bearing on the size of my increase (assuming any of us get one) or my bonus, nor will it alter my chances of a promotion, nor my chances of getting assigned to juicy jobs.
So, despite reading the best advice on the subject I can find, I still find it difficult.
Meetings - last one in
Further to my last post on punctuality at meetings, I thought I'd let you know about something I am trialling in this team.
The weekly team meetings we have are not project-related, but programme. They are attended by the Programme Manager (my direct boss), three other PMs who report to him, plus a couple of senior techies.
Every meeting starts late! Every week, someone is either talking on the phone or MIA when the meeting is due to start. Last week, I suggested that the last person to arrive buy some nibbles (biscuits, donuts, cake, whatever) for the following week's meeting. The boss loved the idea (despite the fact that he's no less guilty than anyone else) and offered to buy the first round.
The weekly team meetings we have are not project-related, but programme. They are attended by the Programme Manager (my direct boss), three other PMs who report to him, plus a couple of senior techies.
Every meeting starts late! Every week, someone is either talking on the phone or MIA when the meeting is due to start. Last week, I suggested that the last person to arrive buy some nibbles (biscuits, donuts, cake, whatever) for the following week's meeting. The boss loved the idea (despite the fact that he's no less guilty than anyone else) and offered to buy the first round.
I'll let you know how it goes.
Yesterday, with one of our PMs off ill, we were supposed to have a shorter meeting, with a longer resourcing discussion today. Again we started late (and NH will be getting in the nibbles next week), but the meeting still lasted 90 minutes! The majority of the time was taken up by arguing over what to do about a perceived slide in software quality control. That will be the subject of a later post, but my point is that the boss, who is supposed to be chairing and therefore controlling the meeting, was getting embroiled in heated discussions that actually were best handled in a separate workshop in a more structured manner.
I think I should give him some feedack, so I will be brushing up on how best to do that here and suggesting that he listen to this.
Bullying in the workplace
This article in Management Issues quotes that "one fifth of all employees in the UK claim to have experienced some form of bullying over the last two years".
As far as I can remember, the only incident of bullying I can ever remember happened last year.
Three members of my project team (Pete, Anna and Mike) were working in another building, and apparently Mike had promoted to the Test environment a program with an inherent bug. The bug caused a problem in the overnight batch. The guy who was called in to support the batch that night fixed the problem, and the next morning came over to where Mike, Anna and Pete were sitting and said
"Which of you f@&%ed up my batch last night?"
Of course, they were flabbergasted and took offense. When the incident was drawn to my attention - thanks to Pete's email - I escalated the matter to my Delivery Manager, frankly not expecting very much. To my surprise and relief, I got a phone call from him a few days later to say that he had called the offender into his office and given him a lecture, and a warning that if any similar incident involving him came to light, he would be immediately dismissed.
I was at once relieved to hear that I was able to protect my team, and gratified to know that the company was not prepared to tolerate such behaviour.
As far as I can remember, the only incident of bullying I can ever remember happened last year.
Three members of my project team (Pete, Anna and Mike) were working in another building, and apparently Mike had promoted to the Test environment a program with an inherent bug. The bug caused a problem in the overnight batch. The guy who was called in to support the batch that night fixed the problem, and the next morning came over to where Mike, Anna and Pete were sitting and said
"Which of you f@&%ed up my batch last night?"
Of course, they were flabbergasted and took offense. When the incident was drawn to my attention - thanks to Pete's email - I escalated the matter to my Delivery Manager, frankly not expecting very much. To my surprise and relief, I got a phone call from him a few days later to say that he had called the offender into his office and given him a lecture, and a warning that if any similar incident involving him came to light, he would be immediately dismissed.
I was at once relieved to hear that I was able to protect my team, and gratified to know that the company was not prepared to tolerate such behaviour.
Fashionably late
One of my pet peeves is punctuality. I am almost never late for meetings, and consider it downright rude to keep people waiting. I had cause to consider this twice yesterday.
The first was a meeting scheduled for 1:30, at which I sat down - along with one other attendee - at 1:29 and waited for the rest to arrive. We waited four minutes, which is not bad considering. I have waited longer before. At a company I used to work for, a senior techie, who was always very busy, was such a stickler for punctuality that if the chairman had not arrived within 5 minutes of the scheduled start, he would get up and leave the meeting. Gotta love it.
The second occasion I had to consider the subject of punctuality yesterday was later in the afternoon. A social event had been arranged at a local bar for 5:30. Being an early bird, and not exactly overloaded with work at the moment, I left the office at 5:20 and get there at 5:30 almost exactly.
There were three people in the bar, none of whom I recognised. After a short wait, I realised that most people had either gone home earlier, or would be arriving later. As I couldn't be bothered to drink alone waiting for someone to talk to, I left.
There are undoubtedly times when fashionably late is the ideal time to arrive.
The first was a meeting scheduled for 1:30, at which I sat down - along with one other attendee - at 1:29 and waited for the rest to arrive. We waited four minutes, which is not bad considering. I have waited longer before. At a company I used to work for, a senior techie, who was always very busy, was such a stickler for punctuality that if the chairman had not arrived within 5 minutes of the scheduled start, he would get up and leave the meeting. Gotta love it.
The second occasion I had to consider the subject of punctuality yesterday was later in the afternoon. A social event had been arranged at a local bar for 5:30. Being an early bird, and not exactly overloaded with work at the moment, I left the office at 5:20 and get there at 5:30 almost exactly.
There were three people in the bar, none of whom I recognised. After a short wait, I realised that most people had either gone home earlier, or would be arriving later. As I couldn't be bothered to drink alone waiting for someone to talk to, I left.
There are undoubtedly times when fashionably late is the ideal time to arrive.
