People Management

I’m going to go off topic here, but this is a blog so I’m getting down my thoughts as they arrive. The reason behind this blog is yet another article on how to let people go. Ok, so it’s about alternatives first, but it is about letting people go, and there are many commentaries and opinions on this topic appearing at the moment. Of course there are. It’s a fact of the present economic situation that cost-cutting is occurring and therefore people are being ‘let go’.

I find these articles to be somewhat of an exercise in rationalisation, much like buying an expensive pair of shoes then presenting yourself with reasons why you had to have them. I’ve made some people redundant, and here’re all the reasons I had to. They weren’t pulling their weight, they’d got stuck in a rut, they were overpriced compared to their peer group average, they weren’t right for the job. The articles themselves are presenting post-activity excuses that can be used in defending a hard decision.

Who cut the rut?

What is never explained in articles about the right way to let people go is why those people were there in the first place. It is not only a management decision to fit a person to a position, but also to create the position in the first place. The litmus test of whether a position should exist should be whether that position is of benefit to the company in the worst of economic situations. Can we survive without this position? Then, and only then, can we achieve without this position? It’s a hierarchy of needs, but the same one that should be used when making positions redundant. If you create a ‘luxury’ position, then expect to make that position redundant when the time comes. Moreover, when you appoint a person into that position, let them know what they are getting themselves into, otherwise you will have a very disgruntled employee when the bad times come along. Don’t create luxury positions in the first place – don’t respond to large budgets by using them – and you won’t need to release people.

Use it or lose it!

Inflated budgets lead to inflated spending measures, included inflated teams to massage inflated egos. Any company that has a use it or lose it attitude to budgets is lining themselves up for a fall, or a number of falls, when budgets have to be tightened. It is a bureaucratic insistence on reporting on spending that leads to this use it or lose it situation. Alfred P. Sloan ran General Motors as separate divisions each responsible for its own budget whilst he asked for a simple return. As long as he received that return from the division, the division was not required to report in detail how it got there. The divisions were responsible for their own accounts. This may be one of the factors that kept GM above Ford from the 1930s for over 70 years. Autonomy.

Why not allow divisions that don’t spend all of their budgets on their business to spend the remains, the ‘profits’, on themselves, their people. This provides a greater incentive to streamline the division and yet produce the optimum profit. Spurious positions will not be created, and filled with people who will have to be moved on in hard times.

Imagine that, a company with everyone bought in, and no need to lay-off when the going outside gets tough.

Requirements in the Organisation

Shoulds, coulds, woulds, mays, mights. Dotted around lessons, tutorials, papers, books, blogs on how to write requirements. Every expert on requirements wants them to be specific, well defined, exact. And so they should be, because a black-and-white, success/failure test needs to be created based upon them. So why do writers consistently use “should be written as”, “would be best if” and the like?

People.

You can’t get away from them. Business Analysts are people. Clients are people. Experts are people. Now this ‘would’ be a point that we ‘could’ stop at and leave it there: you can’t perfect requirements because there are imperfect objects involved in their definition. But we can’t make excuses for an imperfect solution when it is finally presented to our client.

There are many frameworks for designing perfect requirements. Concise, correct, isolate, necessary, unambiguous, predicated, bounded, testable. But the client’s picture of requirements is a melange of functional statements, emotive comments, and ‘ingenious’ solutions weighed down with ingenuous pride. I worked with one client for whom we coined the word ‘solutionising’. I’m sure I’m not the only person to have used it. For us it meant defining the solution as the requirement. “We want a database table to store all our customers alongside their products indexed by date purchased.” “You should use a hyperlink in the email to record responses.” By presenting the ‘nonsense’ word it made the avoidance of defining solutions as requirements something of a game. An alternative is to present alternatives to the solution, but this is something of a ‘but’ situation. Nobody wants to be presented with a but. It gets their goat up, makes them stand their ground, argue their case. What you really want to get at is the requirement behind the solution, or the reason for the emotion.

Why?

You remember that game you used to play with your parents? “But why, Daddy?” Eventually the answer would come back as “just because”, or some version of the same. When you can’t go any further with the question, the reason is the last good answer that you received.
“We want it indexed by date purchased.”
“Why?”
“All our users search on a date parameter for the latest product.”
“Why?”
“The software we sell is versioned, so clients calling in tend to say the name without knowing the version they have – we check for them.”
“Why?”
“That’s the way we work.”
“Okay, so you want to be able to present the user with the client’s version number for their software when they call in for technical support?”
And so forth… The last situation, admittedly not yet a true requirement as it would be documented, is what the client really wants. And the solution might not be quite what they considered.

The Business Analyst is translating between people and machines, between conversation and code, and ‘why?’, I believe, is one of the most powerful tools to enable this.

The Data Management Association states that data management is the process of developing data architectures, practices and procedures dealing with data and then executing these aspects on a regular basis. So which bit failed when the personal details of more than 2,300 crime victims were lost in the post or discs containing personal information on almost 18,000 NHS staff have gone missing. The stories make it appear obvious, that discs containing personal data were sent in the post and went missing. But hang on just one second, that's a lot of discs going missing in a short period of time!

The Royal Mail says that there are 14.4 million items of 'lost post', which we can compare to 21 billion items that are delivered every year (2004 figures, see also the Consumer Focus website). I make that about 2 losses per 3,000 items. Yes, that's a lot, and I wouldn't trust sending personal data through this particular medium - that's one part of the story. But statistically thinking, does this mean that in the time period of the above two stories, there were about 3,000 items of post carried by the Royal Mail containing discs holding personal data? I don't claim to know whether envelopes containing discs are lost more or less often, or whether some other quirk of their nature means that they are badly addressed, but it is highly probable that a lot of personal data is getting sent this way.

Why?

I don't just mean why does someone stick the disc of data in an envelope, stick on a stamp and post it in the red post box. In both of the above cases, someone lost their job for doing just that. I have no knowledge of whether these persons truly made a gross error of conduct, but they were just cogs in the process of getting personal data from A to B. What I want to know is why was this data, valuable, personal data, being moved from A to B? This process failed, but why was this process instituted in the first place? What was the true fundamental, economic, business reason for getting this data from A to B?

If we knew the answer to that question, we could validate it. Is it an institutionalised process? Does it need to be updated? Does it need to happen at all? In my experience it is often found that it doesn't need to happen at all, so before sending data, go back to square one, and ask why?