Brainstorming and problem solving

It has long been thought that, in order to generate ideas or solve problems - indeed any activity requiring a lot of thought - that it is better to do so in a group. 'Two heads are better than one', right?

Well, yes and no.

Here is an interesting article which says that it is sometimes better to put a problem to a number of people individually first, then ask them to get together to discuss their ideas.

The researchers speculate that when a group of people receives information, the inclination is to discuss it. The more times one option is said aloud, the harder it is for individuals to recall other options.

I have an upcoming design workshop planned - the perfect opportunity to try out the theory.

Directing people

A friend once told me that to succeed as a manager, you need to command. It's not the only criterion, but being able to command both attention and respect go a long way towards getting what you want. That and providing direction. Command and Direct. That, in a nutshell, is what managers do.

Today was a case in point. The boss (who is actually pretty good at this stuff) was away today, so I was able to do some commanding and directing of my own.
During a workshop intended to clarify some concerns with our requirements specification, it became clear that we were still unable to get answers to all our questions. On a project with deadlines as tight as this one, further delays are just not good enough. So, I directed. I commanded. I said, "minute the agreements, assumptions and actions we have agreed here today, then put all the unknowns in the Functional Specification under the heading of 'Out of Scope'. Then focus all your attention on all the stuff you do know about".

Unfortunately, this has the side effect of potentially delaying things even further, because with the requirements baselined, any changes will now need to be assessed via the change control process. This might be considered an overhead, but it's the only way of ensuring that the high priority requirements are delivered on time.

Attention must be focused on what's really important.

Priority Projects

In an organisation that runs a lot of projects at any given time, it is important to prioritise those projects, so that key resources - both financial and human - can be directed to where they will have the most benefit.

As a project manager, there is nothing worse that being assigned to a large, costly project with a low priority. Everyone's focus is on the higher-priority projects, and when it comes to looking for experienced people to work on your project, they all get stolen by the PMs with the higher-priority projects. It sucks.

Condor has been good in that respect. The benefits are in the tens of millions and the CEO of the parent company himself has said "Make It So".

So when, a couple of weeks ago, I mentioned that one of the people I wanted had been assigned elsewhere, I played the 'priority' card. I escalated my request to senior management, and they assessed the relative priorities of the two projects. I got the man I wanted, and he starts on Monday.

Of course, this competition does not win you a lot of friends among your peers, and it also removes one possible excuse, should you fail to deliver the project. But, to be selfish, I don't care. The important thing for me is to have the priority (important, beneficial, high-profile) projects, and to have the tools (the people, time and money) to succeed.

Getting the priority that you need gets you halfway there.

Secretarial pool for managers

I moved desks yesterday.

Actually, I was evicted from my old desk because someone else was drafted in to help out with a project in crisis. So I was asked to move to another floor entirely.

As most of you will probably know, desk moves have their pros and cons. I my case, they were mostly cons. My old desk was on the same floor as the key members of my team. My tech lead was right beside me and the lead analyst directly opposite.

Remember those old secretarial pools they used to have in the days before desktop computers? Well I am now in the secretarial pool for managers.

You see, the 9th floor is made up almost entirely of managers. There are one or two senior analysts around, but mostly it's just project and programme managers. Quite why anyone would decide to seat so many managers away from their teams is completely beyond me. Anyway, hopefully this is just temporary.

The usual up side of a desk move involves a process I call upgrading. The idea is to have the best workstation in the building - and it can take years.

Even in today’s corporate world of uniformity, there are often small differences between workstations. When a new batch of office chairs comes in because loads of new people are starting, they are very quickly swapped for old ones by the sharpest of incumbents. When one of those incumbents is asked to move desks because one of the newbies needs to sit where he is, he takes his new chair with him. See how it works? These people are upgrading. Accumulating office 'wealth'. When someone leaves the organisation, there is a swift reaction from the old hands. They immediately compare the 'wealth' of the leaver with their own, and very quickly they pounce on the optical mouse that the other guy left behind, or swap their own 1.6Ghz CPU for a 2Ghz one. That grimy keyboard with the sticky 'G' key (the result of a coffee spillage last year) is swapped for the newer, cleaner one. You get the picture.

So when I packed up my books, files and papers, loaded them onto my fancy new chair and wheeled it up to the 9th floor, I was disappointed to see a slower processor, dirtier keyboard and older mouse with no wheel!

The only up side I can see is that I have a better view out of the window. Of the building across the street.

And it's quieter. That's good.