The week before Christmas

The sky outside my window is a uniform greyish-white. The road and pavements are damp with moisture from the fog and overnight dew, and the temperature barely claws its way above zero. There is little incentive to venture outside.

Inside, triggered by the thermostat, the central heating clicks on and the radiators warm up, meaning I stay toasty in my tracksuit bums and tee-shirt. The lights on the christmas tree glow and fade at regular intervals, bringing a cozy atmosphere to the living room. The cat is going whizzy, scampering from one room to the next in frenzied bursts, apparently also frustrated by the weather.

I'm bored. Or is that obvious?

There is such a thing as having too much holiday.

Moving into management

I remember the event as if it was yesterday, but I cannot remember when it occurred; at least 12 years ago, though. But it was one of the defining moments in my career, and to this day I still look back on that day, and wonder....

I had spent many months pondering my career path. In terms of my grade, there was little left on the ladder I was on. I was a Senior Systems Analyst or some other meaningless title, and there was now little chance of promotion. In addition, there was little of any substance left to learn in the job I had been doing for a number of years.

I finally decided that a move into management was the answer.

So one day, during a relative lull in activity, I left my little cube and walked into my manager's office.

"Vijay, I have decided to go into management," I told him.

He smiled and looked across his desk, on which were strewn small piles of papers. Even as he spoke, his desktop printer spewed still more pages of colourful spreadsheets. "Why would you want to do that?" he asked.

I briefly explained my situation. Then he sat back and sighed.

"You think I am a manager?" he asked rhetorically. "I am nothing but an administrator, a bureaucrat, a paper-pusher. I am not really managing anything".

Vijay went on to explain that he was accountable for all the work that his team did, but felt that he had no control over it. He was constantly asked by his boss for reports about project progress, budgets, plans for the next year, appraisals... the list went on and on. None of it did he find enjoyable.

As he spoke, I grew more and more disheartened. Was this all there was left for me? Where could I go now? What would I do?

Any of you who are already managers will recognise that either Vijay's view of his job was blinkered, or he was doing the wrong things.

I decided to put my technical skills to use in the contract market. I spent some time in the USA, then Portugal, before settling here in the UK, where a dozen years after that conversation in my manager's office, I had a similar conversation that proceeded somewhat differently.

"Q, Steve is leaving us," said my boss, John.

Steve was a project manager, to whom John assigned larger projects that needed dedicated management. Most of the work we did involved small tasks that the team leaders like myself could run.

"I want you to take over his position."

I was shocked. Firstly, there were more senior people than me on the team, to whom he could have offered the post. Secondly, I was a contractor, and favouring contractors over permanent staff was just not done. But, it turned out, he had already offered the job to the only permanent person who he felt might want it, and she turned it down. I accepted on the spot.

And there began my management career. I will never forget John for that offer - he could just as easily have got someone else in to do the job. But he gave me the oppotunity I needed to get my foot on that first rung of the ladder.

Vijay, I realise now, was doing the wrong things. He failed to recognise what management was all about - and it's not paperwork and writing reports.

John recognised that it's about people. About making a diverse group of people into a team, even if it's a temporary one, in order to achieve something bigger than any one of them individually, perhaps greater than the sum of all of them.

Management, done properly (can one do management?), can bring enormous rewards. There are various styles of management, and you will naturally fall into one, but consider this: management is about achieving things through others. It's about people. Never forget that.

Party time

Over the last few weeks, I have received invitations to a number of Christmas parties.

There was the official black tie company party at a swish country manor. I decided to take Mark Horstman's advice and had just one drink (well, actually it was two glasses of red wine, but that's the same as one beer, right?). I went home at 11:10, thoroughly bored because all my colleagues were drinking, dancing and partying like crazy, while I sat and chatted with those who either couldn't dance or weren't being asked to. Oh, well. Next time, I'll book a hotel room, and leave the car at home like everyone else did.

Then there was the team Christmas lunch at a local pub. The team has a long-running tradition of awarding prizes for the silliest saying of the year. There were some great candidates :
"It's a secret; I could tell you but I would have to kiss you", "Don't drown, you'll never want to swim again" and the winner "If I get fired, it will be a good reason to leave the company."

Another team tradition is the good old 'secret santa'. My present was one of the most thoughtful, relevant and humorous presents I have ever received. I don't know who got it for me, but whoever it was put a lot of thought and effort into it, and I am truly touched by it.

Another lunch was arranged for all the IT PMs in the company (which I couldn't make because of a Condor workshop), and an after-hours do was arranged for the Condor project team (which I missed due to a clash with the team one). I was invited to one by one of the agencies we use to recruit our contract workforce (which was held on Thursday evening and I missed that due to working late on my presentation to a Condor workshop the next day).

It's good to spend some quality social time with people you work with, and I particularly enjoy that aspect of the festive season.

Happy Holidays, everyone.

Management blogging community - tagged.

When I hear the words 'tagging' or 'tags', I think about the tags added to the search strings in web pages for tracking the success of online marketing campaigns. I hadn't considered the childhood game of tag, until I read Wayne Turmel's post about the blogging equivalent.

I'm 'IT' apparently.

Well, here are 5 things about me that few people know:

1) Despite leading a very active life as a child (jumping off the garage roof, riding bikes with no hands, etc), I have never broken a bone, nor have I ever spent a night in hospital. The worst injury I have ever sustained required 6 stitches, the result of catching my ankle on a broken milk bottle at the age of about 11. Let's hope my luck continues, eh?

2) I was once a member of Toastmasters, the best club in the world for helping people with their public speaking, thinking and listening skills. I achieved Competent Toastmaster status, but still have unfinished business there.

3) Apart from my current location in greater London, I have also worked in Johannesburg, Lisbon, Minneapolis/St Paul, and Dallas, TX. And turned down a job in Hong Kong.

4) I served 2 years in the military. After basic training, I was posted to a medical depot in Namibia as a storeman/driver/computer operator, and was promoted to the best rank in the army - lance corporal.

5) I enjoy shooting. I was once lucky enough to sample a Lee Enfield 0.303 calibre rifle, modified for Bisley competition. Putting 6 shots in a man-shaped piece of paper 600 yards away takes a lot of skill, and is an awesome feeling. I used to own a handgun and enjoyed going to a shooting range every couple of weeks (when I could afford the ammunition), but got rid of it when I realised that it was more likely that someone would get accidentally shot, or I would shoot someone I was not legally entitled to shoot. So I sold it.

There you go Wayne.

Ton up !

This is the one-hundredth post for the upwardly mobile manager (!), and I will use the occasion to review what has happened since I started this little online journey.

I started this blog back in July, at a point when I had just started work on a Strategic Options Analysis. The business were looking at introducing a new online Brand into the Group. This project goes (here anyway) by the code-name Condor. We spent a couple of months looking at how the basic business brief might be put into practice. The project has now been launched and we are in the requirements gathering and analysis phase, while simultaneously mobilising a project team and doing some high-level planning. My initial hopes of managing the entire project were dashed when The Parent Company decided to take it upon themselves to build the online business as a strategic enabler for future business options. My part was reduced to providing the functionality and interface into our part of the business. It's about 20% of the total project, but my part alone has been estimated at about £1.8 million.

This blog has also been the perfect forum for my thoughts on the subjects of appraisals, staff engagement (a very popular post, that one), rants about silly surveys - here and here - engaging the business, my Prince2 course, motivating managers, and requirements specifications.

It has been an enjoyable journey so far. Here's to the next 100 posts.

Tower Bridge

I have made a few trips into central London over the last week or two, and decided on Wednesday evening to see what the latest in camera phones are capable of. The results are quite impressive, I think.

Workplace Politics harming the project

Back in September, I alluded to the impact that politics was having on project Condor. That impact reached a peak yesterday.

The Parent Company (TPC) have spent the last few weeks gathering requirements. It has, truth be told, been quite successful. Representatives from the outsourcing company in India have shown themselves to be slightly ignorant of how our business operates, but their knowledge of Use Cases has been encouraging and really helpful.

The problem is that this requirements gathering exercise has focused purely on what Condor's front-end application will do. No attention has been paid to the back-end core systems. They have assumed that everything below the web services interface layer is within my scope.... but it isn't. I have been given - on more than one occasion - a strictly limited scope and instruction not to 'get mugged' by taking on additional work. Politics. I have twice been told that we do not want to take the blame when something goes wrong. Aaaaarrrrrgh!!!

When I expressed my concerns over the gap in scope, no-one took any notice. Until yesterday.

My boss and I were talking about this scope gap, when he wondered aloud who our Business Unit thought was paying for this stuff - them or TPC. So I phoned the lovely K and asked.

She replied that they were paying for all the changes necessary for the product to work. Heartened, I explained about my enforced limitations, and my concerns that significant areas of requirements had not been included in anyone's scope nor budget. She thanked me and immediately got on the phone to G, my boss's boss. Later that afternoon, he came upstairs to talk to me and my boss about the situation. It didn't take long to convince him that it was 'reasonable' to expect us to do that work, since the outsourcing company were not going to do it, and it was our system, after all.

The upshot of it all is that I now have most of what I wanted in the first place. It would have been nice to manage the entire project, but I will still be responsible for providing the core functionality required for launch.

Although the project is still highly commercially sensitive - hence my use of the Condor code-name (not the real one) - once it is launched to the public, I will be able to reveal my involvement. I can now enjoy my weekend, and look forward to my final 5 hectic days at work before the holiday break.

Specifying Requirements

Now that project Condor has begun, one of the first workstreams - and arguably the most important - is specifying the Business requirements. Normally, IT projects are only started once we receive a Requirements Specification from the business area, and we start the analysis process. Requirements are often incomplete, ambiguous, stated without context, duplicated or reflect a suggested solution rather than a business need.

It is an oft-quoted statistic that the later in the life-cycle of a project - any project - that errors are spotted and eliminated, the more costly it is to do so. To quote an extreme example, one error in a requirements specification spotted during User Acceptance Testing can require weeks and cost tens of thousands of pounds to rectify, but only a few minutes if spotted before the specification is baselined.

In order to have any chance of meeting the tight deadlines imposed on this project, I have arranged for an analyst to be assigned to the business team drawing up the requirements. The project team assigned other people as well, and set up dedicated office space where everyone could work together, and arranged a series of workshops to draw out requirements on specific topics before they were documented.

Specifying business requirements - or user requirements - is not a difficult thing to do, but it's also very easy to do it badly, and make the developer's job a nightmare. We are not always understood when we explain something verbally, but it's even more difficult to get the message across accurately when we have to write it down.

Here are 8 simple rules about good requirements. Whether you are someone who specifies requirements, or someone who receives them, make sure the Requirements Specification you end up with follows these principles, and your project will be off to a good start.

1. Source - Identify who originated the requirement, so that any queries can be addressed to the right person.
2. User - Identify who will benefit from each requirement.
3. Clear and concise - Eradicate any possible ambiguity.
4. Unique - Eliminate duplication.
5. Identifiable - Each requirement must have a reference to ensure traceability (see below).
6. Prioritised - Each requirement must be assigned a priority to distinguish between the ones that are essential for the business case, and which are 'nice-to-have'. The MoSCoW method is widely used for this purpose and is easy to understand.
7. Verifiable - It must be possible to verify, by inspection or testing, that a requirement has been met. If you cannot verify it, you should not be specifying it.
8. Genuine - Specify the requirement, not a suggested solution.

Traceability must also be maintained from each requirement, through design, to individual test cases. The ability to track a test case back to a requirement ensures that all requirements are delivered and verified. But more on this another time.

Rules for Productive meetings

There are numerous resources, both in print and on the net, that express ways of making meetings less onerous and more productive. Here are mine.

• Work out how many man-hours (meeting length times the number of attendees) will be consumed during the meeting. If that number exceeds the potential benefits of the meeting itself, the meeting isn't worth it.
• How do most people treat the reminders that Outlook pops up? Most click 'Snooze' until the time the meeting starts, then leave their desks. The intention is to give yourself enough time to get to the meeting on time. Make sure you and your attendees use the tool for what it was intended and be there on time. Always start the meeting promptly, and don't pander to those who arrive late by going back over what has already been stated.
• When inviting someone who has a really busy calendar with back-to-back meetings, try starting your meeting at ten minutes past the hour, giving him/her time to transition between meetings.
• AOB. This can generate sufficient unplanned conversation to push the meeting over it's scheduled finish time. Don't bother with this on the agenda, it has little purpose. If people bring up items not on the agenda, put them in a 'parking lot' instead. Record these items and discuss them 'offline' or add them to the agenda for the next meeting.
• You can persuade people to come to a lunchtime meeting by providing lunch. If your meeting is important enough, arrange for sandwiches and fruit to be brought in to the meeting room at an appropriate point.
  

Feel free to add your own 'rules' in the comments.

Ethical Blogging

This little article got me thinking.

"...responsible bloggers should recognize that they are publishing words publicly, and therefore have certain ethical obligations to their readers, the people they write about, and society in general."

I am not for one second advocating controlling or censoring the internet, but I think it would be a good thing for bloggers to voluntarily take it upon themselves to follow a code of ethics similar to this one. I'm all for it.

I would welcome any comments - positive or negative - about my own conduct in this blog.

Motivated Managers

I have always been motivated to perform. It's the sense of achievement that comes from a successful implementation that makes us strive to do it all over again next time. The buzz that comes from being able to update our CVs (resumes) with our accomplishments fuels us for the challenges that follow. Often, little more is needed to motivate a manager than to give him/her a challenging assignment, provide the resources necessary, and watch him/her get on with it.

Yesterday was R's last day at work, and over a swift farewell pint at our local pub, someone asked him what were his best and worst memories of the last seven years. His best memory was the time he worked on the launch of a new online business. It was a time of intense pressure, but also tremendous progress. Everybody worked together, putting in very long hours, but they did so willingly. All IT professionals I have ever met, including the managers are especially motivated to do whatever is necessary simply by being made to feel worthwhile, that they are adding value to the company.

Provided that effort is recognised.

If the company does not recognise or reward the accomplishments of it's staff in at least some small way, all the best people will bleed their way out of the organisation, and the intellectual capital and teamwork will dry up and vanish.

Executives of the world, hear this - give your staff a challenge, tell them how they can make a real contribution, and then recognise and reward their achievements. You will reap more than you sow.