Basic Management Skills - الصفحة 2

بو حمد · #6 July 18th, 2008, 04:43 PM

To Write Right
by Gerard M Blair

Writing is an essential skill upon which all engineers and managers rely. This article outlines simple design principles for engineering's predominate product: paper.

"Sex, romance, thrills, burlesque, satire, bass ... most enjoyable".

"Here is everything one expects from this author but thricefold and three times as entertaining as anything he has written before".

"A wonderful tissue of outrageous coincidences and correspondences, teasing elevations of suspense and delayed climaxes".

(reviews of Small World by David Lodge)

This has nothing to do with engineering writing. No engineering report will ever get such reviews. The most significant point about engineering writing is that it is totally different from the writing most people were taught - and if you do not recognize and understand this difference, then your engineering writing will always miss the mark. However, this article outlines a methodical approach to writing which will enable anyone to produce great works of engineering literature.

Why Worry?
Writing is the major means of communication within an organisation; paper is thought to be the major product of professional engineers; some estimate that up to 30% of work-time is engaged in written communication. Thus it is absolutely vital for you as a Professional Engineer to actively develop the skill of writing; not only because of the time involved in writing, but also because your project's success may depend upon it. Indeed, since so much of the communication between you and more senior management occurs in writing, your whole career may depend upon its quality.

Two Roles
In an industrial context, writing has two major roles:

it clarifies - for both writer and reader
it conveys information
It is this deliberate, dual aim which should form the focus for all your writing activity.

There are many uses for paper within an organization; some are inefficient - but the power of paper must not be ignored because of that. In relation to a project, documentation provides a means to clarify and explain on-going development, and to plan the next stages. Memoranda are a simple mechanism for suggestions, instructions, and general organisation. The minutes of a meeting form a permanent and definitive record.

Writing is a central part of any design activity. Quality is improved since writing an explanation of the design, forces the designer to consider and explore it fully. For instance, the simple procedure of insisting upon written test-plans forces the designer to address the issue. Designs which work just "because they do" will fail later; designs whose operation is explained in writing may also fail, but the repair will be far quicker since the (documented) design is understood.

If you are having trouble expressing an idea, write it down; you (and possibly others) will then understand it. It may take you a long time to explain something "off the cuff", but if you have explained it first to yourself by writing it down - the reader can study your logic not just once but repeatedly, and the information is efficiently conveyed.

Forget the Past
Professional writing has very little to do with the composition and literature learnt at school: the objectives are different, the audience has different needs, and the rewards in engineering can be far greater. As engineers, we write for very distinct and restricted purposes, which are best achieved through simplicity.

English at school has two distinct foci: the analysis and appreciation of the great works of literature, and the display of knowledge. It is all a question of aim. A novel entertains. It forces the reader to want to know: what happens next. On the other hand, an engineering report is primarily designed to convey information. The engineer's job is helped if the report is interesting; but time is short and the sooner the meat of the document is reached, the better. The novel would start: "The dog grew ill from howling so ..."; the engineer's report would start (and probably end): "The butler killed Sir John with a twelve inch carving knife".

In school we are taught to display knowledge. The more information and argument, the more marks. In industry, it is totally different. Here the wise engineer must extract only the significant information and support it with only the minimum-necessary argument. The expertise is used to filter the information and so to remove inessential noise. The engineer as expert provides the answers to problems, not an exposition of past and present knowledge: we use our knowledge to focus upon the important points.

For the Future
When you approach any document, follow this simple procedure:

Establish the AIM
Consider the READER
Devise the STRUCTURE
DRAFT the text
EDIT and REVISE
That is it. For the rest of this article, we will expand upon these points and explain some techniques to make the document effective and efficient - but these five stages (all of them) are what you need to remember.

Aim
You start with your aim. Every document must have a single aim - a specific, specified reason for being written. If you can not think of one, do something useful instead; if you can not decide what the document should achieve, it will not achieve it.

Once you have established your aim, you must then decide what information is necessary in achieving that aim. The reader wants to find the outcome of your thoughts: apply your expertise to the available information, pick out the very-few facts which are relevant, and state them precisely and concisely.

The Reader
A document tells somebody something. As the writer, you have to decide what to tell and how best to tell it to the particular audience; you must consider the reader.

There are three considerations:

What they already know affects what you can leave out.
What they need to know determines what you include.
Wha
t they want to know suggests the order and emphasis of your writing.
For instance, in a products proposal, marketing will want to see the products differentiation and niche in the market place; finance will be interested in projected development costs, profit margins and risk analysis; and R&D will want the technical details of the design. To be most effective, you may need to produce three different reports for the three different audiences.

The key point, however, is that writing is about conveying information - conveying; that means it has to get there. Your writing must be right for the reader, or it will lost on its journey; you must focus upon enabling the reader's access to the information.

Structure
Writing is very powerful - and for this reason, it can be exploited in engineering. The power comes from its potential as an efficient and effective means of communication; the power is derived from order and clarity. Structure is used to present the information so that it is more accessible to the reader.

In all comes down to the problem of the short attention span. You have to provide the information in small manageable chunks, and to use the structure of the document to maintain the context. As engineers, this is easy since we are used to performing hierarchical decomposition of designs - and the same procedure can be applied to writing a document.

While still considering the aim and the reader, the document is broken down into distinct sections which can be written (and read) separately. These sections are then each further decomposed into subsections (and sub-subsections) until you arrive at simple, small units of information - which are expressed as a paragraph, or a diagram.

Every paragraph in your document should justify itself; it should serve a purpose, or be removed. A paragraph should convey a single idea. There should be a statement of that key idea and (possibly) some of the following:

a development of the idea
an explanation or analogy
an illustration
support with evidence
contextual links to reinforce the structure
As engineers, though, you are allowed to avoid words entirely in places; diagrams are often much better than written text. Whole reports can be written with them almost exclusively and you should always consider using one in preference to a paragraph. Not only do diagrams convey some information more effectively, but often they assist in the analysis and interpretation of the data. For instance, a pie chart gives a quicker comparison than a list of numbers; a simple bar chart is far more intelligible than the numbers it represents. The only problem with diagrams is the writer often places less effort in their design than their information-content merits - and so some is lost or obscure. They must be given due care: add informative labels and titles, highlight any key entries, remove unnecessary information.

Draft, Revise and Edit
When you have decided what to say, to whom you are saying it, and how to structure it; say it - and then check it for clarity and effectiveness. The time spent doing this will be far less than the time wasted by other people struggling with the document otherwise.

The following are a few points to consider as you wield the red pen over your newly created opus.

Layout
The main difference between written and verbal communication is that the reader can choose and re-read the various sections, whereas the listener receives information in the sequence determined by the speaker. Layout should be used to make the structure plain, and so more effective: it acts as a guide to the reader.

Suppose you have three main points to make; do not hide them within simple text - make them obvious. Make it so that the reader's eye jumps straight to them on the page. For instance, the key to effective layout is to use:

informative titles
white space
variety
Another way to make a point obvious is to use a different font.

Style
People in business do not have the time to marvel at your florid turn off phrase or incessant illiteration. They want to know what the document is about and (possibly) what it says; there is no real interest in style, except for ease of access.

In some articles a summary can be obtained by reading the first sentence of each paragraph. The remainder of each paragraph is simply an expansion upon, or explanation of, the initial sentence. In other writing, the topic is given first in a summary form, and then successively repeated with greater detail each time. This is the pyramid structure favoured by newspapers.

A really short and simple document is bound to be read. This has lead to the "memo culture" in which every communication is condensed to one side of A4. Longer documents need to justify themselves to their readers' attention.

The Beginning
Let us imagine the reader. Let us call her Ms X.

Ms X has a lot to do today: she has a meeting tomorrow morning with the regional VP, a call to make to the German design office, several letters to dictate concerning safety regulations, and this months process-data has failed to reach her. She is busy and distracted. You have possibly 20 seconds for your document to justify itself to her. If by then it has not explained itself and convinced her that she needs to read it - Ms X will tackle something else. If Ms X is a good manager, she will insist on a rewrite; if not, the document may never be read. action).

Thus the beginning of your document is crucial. It must be obvious to the reader at once what the document is about, and why it should be read. You need to catch the readers attention but with greater subtlety than this article; few engineering reports can begin with the word sex.

Unlike a novel, the engineering document must not contain "teasing elevations of suspense". Take your "aim", and either state it or achieve it by the end of the first paragraph.

For instance, if you have been evaluating a new software package for possible purchase then your reports might begin: "Having evaluated the McBlair Design Suite, I recommend that ...".

Punctuation
Punctuation is used to clarify meaning and to highlight structure. It can also remove ambiguity: a cross section of customers can be rendered less frightening simply by adding a hyphen (a cross-section of customers).

Engineers tend not to punctuate - which deprives us of this simple tool. Despite what some remember from school, punctuation has simple rules which lead to elegance and easy interpretation. If you want a summary of punctuation, try The Concise Oxford Dictionary (1990); and if you want a full treatise, complete with worked examples (of varying degrees of skill), read You Have A Point There by Eric Partridge.

For now, let us look at two uses of two punctuation marks. If you do not habitually use these already, add them to your repertoire by deliberately looking for opportunities in your next piece of writing.

The two most common uses of the Colon are:

1) To introduce a list which explains, or provides the information promised in, the previous clause.

A manager needs two planning tools: prescience and a prayer.
2) To separate main clauses where the second is a step forward from the first: statement to example, statement to explanation, cause to effect, introduction to main point.
To err is human: we use computers.
The two most common uses of the Semicolon are:
1) to unite sentences that are closely associated, complementary or parallel:

Writing is a skill; one must practise to improve a skill.
Engineers engineer; accountants account for the cost.

2) to act as a stronger comma, either for emphasis or to establish a hierarchy
The report was a masterpiece; of deception and false promises.
The teams were Tom, Dick and Harry; and Mandy, Martha and Mary.

Spelling
For some, spelling is a constant problem. In the last analysis, incorrect speling distracts the reader and detracts from the authority of the author. Computer spell-checking programmes provide great assistance, especially when supported by a good dictionary. Chronic spellers should always maintain a (preferably alphabetical) list of corrected errors, and try to learn new rules (and exceptions!). For instance (in British English) advice-advise, device-devise, licence-license, practice-practise each follow the same pattern: the -ice is a noun, the -ise is a verb.

Simple Errors
For important documents, there is nothing better than a good, old-fashioned proof-read. As an example, the following comes from a national advertising campaign/quiz run by a famous maker of Champagne:

Question 3: Which Country has one the Triple Crown the most times?
Won understands the error, but is not impressed by the quality of that company's product.

Sentence Length
Avoid long sentences. We tend to associate "unit of information" with "a sentence". Consequently when reading, we process the information when we reach the full stop. If the sentence is too long, we lose the information either because of our limited attention span or because the information was poorly decomposed to start with and might, perhaps, have been broken up into smaller, or possibly better punctuated, sentences which would better have kept the attention of the reader and, by doing so, have reinforced the original message with greater clarity and simplicity.

Word Length
It is inappropriate to utilize verbose and bombastic terminology when a suitable alternative would be to: keep it simple. Often the long, complex word will not be understood. Further, if the reader is distracted by the word itself, then less attention is paid to the meaning or to the information you wished to convey.

Jargon
I believe that a digital human-computer-interface data-entry mechanism should be called a keyboard; I don't know why, but I do.

Wordiness
When one is trying hard to write an impressive document, it is easy to slip into grandiose formulae: words and phrases which sound significant but which convey nothing but noise.

You must exterminate. So: "for the reason that" becomes "because"; "with regards to" becomes "about"; "in view of the fact that" becomes "since"; "within a comparatively short period of time" becomes "soon".

Often you can make a sentence sound more like spoken English simply be changing the word order and adjusting the verb. So: "if the department experiences any difficulties in the near future regarding attendance of meetings" becomes "if staff cannnot attend the next few meetings". As a final check, read your document aloud; if it sounds stilted, change it.

Conclusion
Writing is a complex tool, you need to train yourself in its use or a large proportion of your activity will be grossly inefficient. You must reflect upon your writing lest it reflects badly upon you.

If you want one message to take from this article, take this: the writing of a professional engineer should be clear, complete and concise. If your document satisfies these three criteria, then it deserves to be read.

Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh. His book Starting to Manage: the essential skills is published by Chartwell-Bratt (UK) and the Institute of Electrical and Electronics Engineers (USA). He welcomes feedback either by email (gerard@ee.ed.ac.uk) or by any other method found here

بو حمد · #7 July 18th, 2008, 04:45 PM

The Art of Delegation
by Gerard M Blair

Delegation is a skill of which we have all heard - but which few understand. It can be used either as an excuse for dumping failure onto the shoulders of subordinates, or as a dynamic tool for motivating and training your team to realize their full potential.

"I delegate myne auctorite" (Palsgrave 1530)

Everyone knows about delegation. Most managers hear about it in the cradle as mother talks earnestly to the baby-sitter: "just enjoy the television ... this is what you do if ... if there is any trouble call me at ..."; people have been writing about it for nearly half a millennium; yet few actually understand it.

Delegation underpins a style of management which allows your staff to use and develop their skills and knowledge to the full potential. Without delegation, you lose their full value.

As the ancient quotation above suggests, delegation is primarily about entrusting your authority to others. This means that they can act and initiate independently; and that they assume responsibility with you for certain tasks. If something goes wrong, you remain responsible since you are the manager; the trick is to delegate in such a way that things get done but do not go (badly) wrong.

Objective
The objective of delegation is to get the job done by someone else. Not just the simple tasks of reading instructions and turning a lever, but also the decision making and changes which depend upon new information. With delegation, your staff have the authority to react to situations without referring back to you.

If you tell the janitor to empty the bins on Tuesdays and Fridays, the bins will be emptied on Tuesdays and Fridays. If the bins overflow on Wednesday, they will be emptied on Friday. If instead you said to empty the bins as often as necessary, the janitor would decide how often and adapt to special circumstances. You might suggest a regular schedule (teach the janitor a little personal time management), but by leaving the decision up to the janitor you will apply his/her local knowledge to the problem. Consider this frankly: do you want to be an expert on bin emptying, can you construct an instruction to cover all possible contingencies? If not, delegate to someone who gets paid for it.

To enable someone else to do the job for you, you must ensure that:

they know what you want
they have the authority to achieve it
they know how to do it.
These all depend upon communicating clearly the nature of the task, the extent of their discretion, and the sources of relevant information and knowledge.

Information
Such a system can only operate successfully if the decision-makers (your staff) have full and rapid access to the relevant information. This means that you must establish a system to enable the flow of information. This must at least include regular exchanges between your staff so that each is aware of what the others are doing. It should also include briefings by you on the information which you have received in your role as manager; since if you need to know this information to do your job, your staff will need to know also if they are to do your (delegated) job for you.

One of the main claims being made for computerized information distribution is that it facilitates the rapid dissemination of information. Some protagonists even suggest that such systems will instigate changes in managerial power sharing rather than merely support them: that the "enknowledged" workforce will rise up, assume control and innovate spontaneously. You may not believe this vision, but you should understand the premise. If a manager restricts access to information, then only he/she is able to make decisions which rely upon that information; once that access is opened to many others, they too can make decisions - and challenge those of the manager according to additional criteria. The manager who fears this challenge will never delegate effectively; the manager who recognizes that the staff may have additional experience and knowledge (and so may enhance the decision-making process) will welcome their input; delegation ensures that the staff will practise decision-making and will feel that their views are welcome.

Effective control
One of the main phobias about delegation is that by giving others authority, a manager loses control. This need not be the case. If you train your staff to apply the same criteria as you would yourself (by example and full explanations) then they will be exercising your control on you behalf. And since they will witness many more situations over which control may be exercised (you can't be in several places at once) then that control is exercised more diversely and more rapidly than you could exercise it by yourself. In engineering terms: if maintaining control is truly your concern, then you should distribute the control mechanisms to enable parallel and autonomous processing.

Staggered Development
To understand delegation, you really have to think about people. Delegation cannot be viewed as an abstract technique, it depends upon individuals and individual needs. Let us take a lowly member of staff who has little or no knowledge about the job which needs to be done.

Do you say: "Jimmy, I want a draft tender for contract of the new Hydro Powerstation on my desk by Friday"? No. Do you say: "Jimmy, Jennifer used to do the tenders for me. Spend about an hour with her going over how she did them and try compiling one for the new Hydro Powerstation. She will help you for this one, but do come to me if she is busy with a client. I want a draft by Friday so that I can look over it with you"? Possibly.

The key is to delegate gradually. If you present someone with a task which is daunting, one with which he/she does not feel able to cope, then the task will not be done and your staff will be severely demotivated. Instead you should build-up gradually; first a small task leading to a little development, then another small task which builds upon the first; when that is achieved, add another stage; and so on. This is the difference between asking people to scale a sheer wall, and providing them with a staircase. Each task delegated should have enough complexity to stretch that member of staff - but only a little.

Jimmy needs to feel confident. He needs to believe that he will actually be able to achieve the task which has been given to him. This means that either he must have the sufficient knowledge, or he must know where to get it or where to get help. So, you must enable access to the necessary knowledge. If you hold that knowledge, make sure that Jimmy feels able to come to you; if someone else holds the knowledge, make sure that they are prepared for Jimmy to come to them. Only if Jimmy is sure that support is available will he feel confident enough to undertake a new job.

You need to feel confident in Jimmy: this means keeping an eye on him. It would be fatal to cast Jimmy adrift and expect him to make it to the shore: keep an eye on him, and a lifebelt handy. It is also a mistake to keep wandering up to Jimmy at odd moments and asking for progress reports: he will soon feel persecuted. Instead you must agree beforehand how often and when you actually need information and decide the reporting schedule at the onset. Jimmy will then expect these encounters and even feel encouraged by your continuing support; you will be able to check upon progress and even spur it on a little.

When you do talk to Jimmy about the project, you should avoid making decisions of which Jimmy is capable himself. The whole idea is for Jimmy to learn to take over and so he must be encouraged to do so. Of course, with you there to check his decisions, Jimmy will feel freer to do so. If Jimmy is wrong - tell him, and explain very carefully why. If Jimmy is nearly right - congratulate him, and suggest possible modifications; but, of course, leave Jimmy to decide. Finally, unless your solution has significant merits over Jimmy's, take his: it costs you little, yet rewards him much.

Constrained Availability
There is a danger with "open access" that you become too involved with the task you had hoped to delegate. One successful strategy to avoid this is to formalize the manner in which these conversation take place. One formalism is to allow only fixed, regular encounters (except for emergencies) so that Jimmy has to think about issues and questions before raising them; you might even insist that he draw-up an agenda. A second formalism is to refuse to make a decision unless Jimmy has provided you with a clear statement of alternatives, pros and cons, and his recommendation. This is my favourite. It allows Jimmy to rehearse the full authority of decision making while secure in the knowledge that you will be there to check the outcome. Further, the insistence upon evaluation of alternatives promotes good decision making practices. If Jimmy is right, then Jimmy's confidence increases - if you disagree with Jimmy, he learns something new (provided you explain your criteria) and so his knowledge increases. Which ever way, he benefits; and the analysis is provided for you.

Outcomes and Failure
Let us consider your undoubtedly high standards. When you delegate a job, it does not have to be done as well as you could do it (given time), but only as well as necessary: never judge the outcome by what you expect you would do (it is difficult to be objective about that), but rather by fitness for purpose. When you delegate a task, agree then upon the criteria and standards by which the outcome will be judged.

You must enable failure. With appropriate monitoring, you should be able to catch mistakes before they are catastrophic; if not, then the failure is yours. You are the manager, you decided that Jimmy could cope, you gave him enough rope to hang himself, you are at fault. Now that that is cleared up, let us return to Jimmy. Suppose Jimmy gets something wrong; what do you want to happen?

Firstly, you want it fixed. Since Jimmy made the mistake, it is likely that he will need some input to develop a solution: so Jimmy must feel safe in approaching you with the problem. Thus you must deal primarily with the solution rather than the cause (look forward, not backwards). The most desirable outcome is that Jimmy provides the solution.

Once that is dealt with, you can analyse the cause. Do not fudge the issue; if Jimmy did something wrong say so, but only is very specific terms. Avoid general attacks on his parents: "were you born this stupid?", and look to the actual event or circumstance which led to the error: "you did not take account of X in your decision". Your objectives are to ensure that Jimmy:

understands the problem
feels confident enough to resume
implements some procedure to prevent recurrence.
The safest ethos to cultivate is one where Jimmy actually looks for and anticipates mistakes. If you wish to promote such behaviour, you should always praise Jimmy for his prompt and wise action in spotting and dealing with the errors rather that castigate him for causing them. Here the emphasis is placed upon checking/testing/monitoring of ideas. Thus you never criticise Jimmy for finding an error, only for not having safe-guards in place.

What to delegate
There is always the question of what to delegate and what to do yourself, and you must take a long term view on this: you want to delegate as much as possible to develop you staff to be as good as you are now.

The starting point is to consider the activities you used to do before you were promoted. You used to do them when you were more junior, so someone junior can do them now. Tasks in which you have experience are the easiest for you to explain to others and so to train them to take over. You thus use your experience to ensure that the task is done well, rather than to actually perform the task yourself. In this way you gain time for your other duties and someone else becomes as good as your once were (increasing the strength of the group).

Tasks in which your staff have more experience must be delegated to them. This does not mean that you relinquish responsibility because they are expert, but it does mean that the default decision should be theirs. To be a good manager though, you should ensure that they spend some time in explaining these decisions to you so that you learn their criteria.

Decisions are a normal managerial function: these too should be delegated - especially if they are important to the staff. In practice, you will need to establish the boundaries of these decisions so that you can live with the outcome, but this will only take you a little time while the delegation of the remainder of the task will save you much more.

In terms of motivation for your staff, you should distribute the more mundane tasks as evenly as possible; and sprinkle the more exciting onces as widely. In general, but especially with the boring tasks, you should be careful to delegate not only the performance of the task but also its ownership. Task delegation, rather than task assignment, enables innovation. The point you need to get across is that the task may be changed, developed, upgraded, if necessary or desirable. So someone who collates the monthly figures should not feel obliged to blindly type them in every first-Monday; but should feel empowered to introduce a more effective reporting format, to use Computer Software to enhance the data processing, to suggest and implement changes to the task itself.

Negotiation
Since delegation is about handing over authority, you cannot dictate what is delegated nor how that delegation is to be managed. To control the delegation, you need to establish at the beginning the task itself, the reporting schedule, the sources of information, your availability, and the criteria of success. These you must negotiate with your staff: only by obtaining both their input and their agreement can you hope to arrive at a workable procedure.

When all is done for you
Once you have delegated everything, what do you do then?

You still need to monitor the tasks you have delegated and to continue the development of your staff to help them exercise their authority well.

There are managerial functions which you should never delegate - these are the personal/personnel ones which are often the most obvious additions to your responsibilities as you assume a managerial role. Specifically, they include: motivation, training, team-building, organization, praising, reprimanding, performance reviews, promotion.

As a manager, you have a responsibility to represent and to develop the effectiveness of your group within the company; these are tasks you can expand to fill your available time - delegation is a mechanism for creating that opportunity.

Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh. His book Starting to Manage: the essential skills is published by Chartwell-Bratt (UK) and the Institute of Electrical and Electronics Engineers (USA). He welcomes feedback either by email (gerard@ee.ed.ac.uk) or by any other method found here

بو حمد · #8 July 18th, 2008, 04:47 PM

The Human Factor
by Gerard M Blair

In the management of a small team, the human factor is crucial to success. This article considers possible motivators and a simple framework for dealing with people.

When you are struggling with a deadline or dealing with delicate decisions, the last thing you want to deal with is "people". When the fight is really on and the battle is undecided, you want your team to act co-operatively, quickly, rationally; you do not want a disgruntled employee bitching about life, you do not want a worker who avoids work, you do not want your key engineer being tired all day because the baby cries all night. But this is what happens, and as a manager you have to deal with it. Few "people problems" can be solved quickly, some are totally beyond your control and can only be contained; but you do have influence over many factors which affect your people and so it is your responsibility to ensure that your influence is a positive one.

You can only underestimate the impact which you personally have upon the habits and effectiveness of your group. As the leader of a team, you have the authority to sanction, encourage or restrict most aspects of their working day, and this places you in a position of power - and responsibility. This article looks briefly at your behaviour and at what motivates people, because by understanding these you can adapt yourself and the work environment so that your team and the company are both enriched. Since human psychology is a vast and complex subject, we do not even pretend to explain it. Instead, the article then outlines a simple model of behaviour and a systematic approach to analysing how you can exert your influence to help your team to work.

Behaviour
Consider your behaviour. Consider the effect you would have if every morning after coffee you walked over to Jimmy's desk and told him what he was doing wrong. Would Jimmy feel pleased at your attention? Would he look forward to these little chats and prepare simple questions to clarify aspects of his work? Or would he develop a Pavlovian hatred for coffee and be busy elsewhere whenever you pass by? Of course you would never be so destructive - provided you thought about it. And you must; for many seemingly simple habits can have a huge impact upon your rapport with your team.

Take another example: suppose (as a good supportive manager) you often give public praise for independence and initiative displayed by your team, and suppose (as a busy manager) you respond brusquely to questions and interruptions; think about it, what will happen?

Probably your team will leave you alone. They will not raise problems (you will be left in the dark), they will not question your instructions (ambiguities will remain), they will struggle on bravely (and feel unsupported). Your simple behaviour may result in a quagmire of errors, mis-directed activity and utter frustration. So if you do want to hear about problems, tell the team so and react positively when you hear of problems in-time rather than too-late.

Motivation
When thinking about motivation it is important to take the long-term view. What you need is a sustainable approach to maintain enthusiasm and commitment from your team. This is not easy; but it is essential to your effectiveness.

Classic work on motivation was undertaken by F. Herzberg in the 1950's when he formulated the "Motivation-Hygiene" theory. Herzberg identified several factors, such as salary levels, working conditions and company policy, which demotivated (by being poor) rather that motivated (by being good). For example, once a fair level of pay is established, money ceases to be a significant motivator for long term performance. Herzberg called these the "Hygiene" factors to apply the analogy that if the washrooms are kept clean, no one cares if they are scrubbed even harder. The point is that you can not enhance your team's performance through these Hygiene factors - which is fortunate since few team leaders have creative control over company organization or remuneration packages. What you can influence is the local environment and particularly the way in which you interact with your team.

The positive motivators identified by Herzberg are: achievement, recognition, the work itself, responsibility, and advancement. These are what your team needs; loads-o-money is nice but not nearly as good as being valued and trusted.

Achievement
As the manager, you set the targets - and in selecting these targets, you have a dramatic effect upon your team's sense of achievement. If you make them too hard, the team will feel failure; if too easy, the team feels little. Ideally, you should provide a series of targets which are easily recognised as stages towards the ultimate completion of the task. Thus progress is punctuated and celebrated with small but marked achievements. If you stretch your staff, they know you know they can meet that challenge.
Recognition
Recognition is about feeling appreciated. It is knowing that what you do is seen and noted, and preferably by the whole team as well as by you, the manager. In opposite terms, if people do something well and then feel it is ignored - they will not bother to do it so well next time (because "no one cares").
The feedback you give your team about their work is fundamental to their motivation. They should know what they do well (be positive), what needs improving (be constructive) and what is expected of them in the future (something to aim at). And while this is common sense, ask yourself how many on your team know these things, right now? Perhaps more importantly, for which of your team could you write these down now (try it)?

Your staff need to know where they stand, and how they are performing against your (reasonable) expectations. You can achieve this through a structured review system, but such systems often become banal formalities with little or no communication. The best time to give feedback is when the event occurs. Since it can impact greatly, the feedback should be honest, simple, and always constructive. If in doubt, follow the simple formula of:

highlight something good
point out what needs improving
suggest how to improve
You must always look for something positive to say, if only to offer some recognition of the effort which has been put into the work. When talking about improvements, be specific: this is what is wrong, this is what I want/need, this is how you should work towards it. Never say anything as unhelpful or uninformative as "do better" or "shape up" - if you cannot be specific and say how, then keep quiet. While your team will soon realize that this IS a formula, they will still enjoy the benefits of the information (and training). You must not stint in praising good work. If you do not acknowledge it, it may not be repeated simply because no one knew you approved.

The work itself
The work itself should be interesting and challenging. Interesting because this makes your staff actually engage their attention; challenging because this maintains the interest and provides a sense of personal achievement when the job is done. But few managers have only interesting, challenging work to distribute: there is always the boring and mundane to be done. This is a management problem for you to solve. You must actually consider how interesting are the tasks you assign and how to deal with the boring ones. Here are two suggestions.
Firstly, make sure that everyone (including yourself) has a share of the interesting and of the dull. This is helped by the fact that what is dull to some might be new and fascinating to others - so match tasks to people, and possibly share the worst tasks around. For instance, taking minutes in meetings is dull on a weekly basis but quite interesting/educational once every six weeks (and also heightens a sense of responsibility). Secondly, if the task is dull perhaps the method can be changed - by the person given the task. This turns dull into challenging, adds responsibility, and might even improve the efficiency of the team.

Responsibility
Of all of Herzberg's positive motivators, responsibility is the most lasting. One reason is that gaining responsibility is itself seen as an advancement which gives rise to a sense of achievement and can also improve the work itself: a multiple motivation! Assigning responsibility is a difficult judgement since if the person is not confident and capable enough, you will be held responsible for the resulting failure. Indeed, delegating responsibility deserves another article in itself (see the article on Delegation).
Advancement
There are two types of advancement: the long-term issues of promotion, salary rises, job prospects; and the short-term issues (which you control) of increased responsibility, the acquisition of new skills, broader experience. Your team members will be looking for the former, you have to provide the latter and convince them that these are necessary (and possibly sufficient) steps for the eventual advancement they seek. As a manager, you must design the work assignment so that each member of the team feels: "I'm learning, I'm getting on".
Problems
We are going to look at a simple system for addressing people-problems. It is a step-by-step procedure which avoids complex psychological models (which few managers can/should handle) and which focuses upon tangible (and so controllable) quantities.

One work of warning: this technique is often referred to as Behavioural Modification (BM) and many balk at the connotations of management-directed mind control. Do not worry. We are simply recognising that staff behaviour IS modified by the work environment and by your influence upon it. The technique is merely a method for analysing that influence to ensure that it is positive and to focus it to best use.

In any group of people there are bound to be problems - as a manager, you have to solve or at least contain them. You ignore them at your peril. Such problems are usually described in terms like: "Alex is just lazy" or "Brenda is a bad-tempered old has-been". On the one hand, such people can poison the working environment; the other hand, these de******ions are totally unhelpful.

The underlying philosophy of BM is that you should concentrate upon specific, tangible actions over which you have influence. For instance "Alex is lazy" should be transformed into "Alex is normally late with his weekly report and achieves less than Alice does in any one week". Thus we have a starting point and something which can be measured. No generalities; only specific, observable behaviour.

Before proceeding, it is worth checking that the problem is real - some "problems" are more appearance than substance, some are not worth you time and effort. So, stage 1 is to monitor the identified problem to check that it is real and to seek simple explanations. For instance Alex might still be helping someone with his old job.

Stage 2 is often missed - ask Alex for his solution. This sort of interview can be quite difficult because you run the danger of making personal criticism. Now you may feel that Alex deserves criticism, but does it actually help? Your objective is to get Alex to work well, not to indulge in personal tyranny. If you make it personal, Alex will be defensive. He will either deny the problem, blame someone else, blame the weather, tell you that he knows best or some combination of the above. If, on the other hand, you present the situation in terms of the specific events, you can focus upon Alex's own view of the problem (why is this happening?) and Alex's own solution (what can Alex do about it - can you help?).

Stage 2 will sometimes be sufficient. If Alex had not realised there was a problem, he might act quickly to solve it. If he had thought his behaviour would pass unnoticed, he now knows differently. By giving Alex the responsibility for solving his own problem, you can actually motivate him beyond the specific problem: he may suggest on improved reporting system, or a short training course to deal with a technical short-coming. Finally, the demonstration alone that you are interested in Alex's work may be enough to make him improve. Never assume that you know better, always ask first - then if no solution is forthcoming, proceed to ...

Stage 3 is the analysis stage and is based upon a simple model of behaviour: every action is preceded by a trigger, and is followed by a consequence or payoff. Thus baby is hungry (trigger), baby wails (action), baby gets fed (payoff); or the report is due today (trigger), Alex goes for coffee break "to think about it" (action), Alex has a relaxing afternoon (payoff).

Sometimes, good behaviour is blocked by negative payoffs. For instance, if every time Clive informs his boss Diane about a schedule change (action), Diane vents her annoyance on Clive (payoff), then Clive will be less inclined to approach Diane with information in the future. One of the problems with communication in Ancient Greece was that the bearer of bad news was often executed.

Once you have analysed the problem, stage 4 is to find a solution. With most people-problems at work, you will find that the "bad" behaviour is reinforced by a payoff which that person finds attractive. There are two solutions: 1) modify the payoff either by blocking it, or by adding another consequence which is negative, or 2) create a positive payoff for the alternative, desired "good" behaviour. In the long term, the latter is preferable since it is better for motivation to offer encouragement rather than reprimand; optimally you should implement both.

This is where you have to be creative. BM provides a manageable focus and a framework for analysis; you, as manager, must provide the solution. It is best to work on one problem at a time because this simplifies the analysis. Further, by addressing one, other related problems are often affected also. Let us consider "late reporting". Firstly, add a negative consequence to Alex's current behaviour. State explicitly that you need the report by 3.30 on Friday (so that you can prepare your weekly schedule update) - and, if this does not happen, summon Alex at four o'clock to demand the report before he leaves for the weekend. This will probably ruin his "hour before the weekend" and he will wish to avoid it. Secondly, if Alex does get the report in by 3.30 make a habit of responding to it on Monday morning: if there is an issue raised, help Alex to solve it; if there is a schedule change, talk it over - but make it clear (say it) that you are only able to do this because you had time on Friday to read over his report. Thus Alex learns that he will receive help and support IF he gets the report in on time.

Stage 5 is necessary because such plans do not always work. You must continue to monitor the problem and after a trial period, review your progress. If the plan is working, continue; if the plan has failed, devise a new one; if the plan has worked, look for a new problem to solve.

Where to Seek Solutions
The range of problems is so large, that it is impossible to offer more than generalities as advise. Each person is different, each situation is different, so each solution must be carefully crafted. This being said, here are a few ideas.

Look for aspects of motivation - any problem which stems from lack of commitment or interest can only successfully be addressed by providing motivation, and any of the motivators described earlier can be applied.

Be flexible with regards to personal problems. No parent is immune to the "joys" of a new born baby, no one is uneffected by bereavement. When circumstances and the human factor impinge upon your ordered plans, adapt; since you cannot change it, work with it. Focus upon the problem (say, schedule slippage) and deal with that in the existing situation. For instance if you sanction half a day's "sick-leave" to see a solicitor, you might save a week's worry and distraction.

On a larger scale, look carefully at the "systems" which exist in your team, at those work practices which you and they follow through habit. Some of these can work against you, and the team. For instance, the way you hold team meetings may suppress contributions (at 4 o'clock on a Friday, say); the way you reward the exceptional may demotivate those responsible for the mundane.

Take a long term view. Constant pressure will eventually destroy your team members. If you acknowledge that a relaxed yet engaged workforce is (say) 10% more efficient than one which is over-stressed and fretful, then you should realize that this amounts to half-a-day per week. So why not devote half-a-day to: peer-group teaching, brainstorming on enhanced efficiency, visits to customers (internal and external), guest lectures on work tools, or all four on a four-weekly cycle. You lose nothing if you gain a skilled, committed, enthusiastic team.

Finally, look carefully at how you behave and whether the current situation is due to your previous inattention to the human factor: you might be the problem, and the solution.

Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh. His book Starting to Manage: the essential skills is published by Chartwell-Bratt (UK) and the Institute of Electrical and Electronics Engineers (USA). He welcomes feedback either by email (gerard@ee.ed.ac.uk) or by any other method found here

بو حمد · #9 July 18th, 2008, 04:51 PM

CONVERSATION AS COMMUNICATION
by Gerard M Blair

Communication is best achieved through simple planning and control; this article looks at approaches which might help you to do this and specifically at meetings, where conversations need particular care.

Most conversations sort of drift along; in business, this is wasteful; as a manager, you seek communication rather than chatter. To ensure an efficient and effective conversation, there are three considerations:

you must make your message understood
you must receive/understand the intended message sent to you
you should exert some control over the flow of the communication
Thus you must learn to listen as well as to speak. Those who dismis this as a mere platitude are already demonstrating an indisposition to listening: the phrase may be trite, but the message is hugely significant to your effectiveness as a manager. If you do not explicitly develop the skill of listening, you may not hear the suggestion/information which should launch you to fame and fortune.

AMBIGUITY AVOIDANCE
As a manager (concerned with getting things done) your view of words should be pragmatic rather than philosophical. Thus, words mean not what the dictionary says they do but rather what the speaker intended.

Suppose your manager gives to you an instruction which contains an ambiguity which neither of you notice and which results in you producing entirely the wrong product. Who is at fault? The answer must be: who cares? Your time has been wasted, the needed product is delayed (or dead); attributing blame may be a satisfying (or defensive) exercise but it does not address the problem. In everything you say or hear, you must look out for possible misunderstanding and clarify the ambiguity.

The greatest source of difficulty is that words often have different meanings depending upon context and/or culture. Thus, a "dry" country lacks either water or alcohol; "suspenders" keep up either stockings or trousers (pants); a "funny" meeting is either humorous or disconcerting; a "couple" is either a few or exactly two. If you recognize that there is a potential misunderstanding, you must stop the conversation and ask for the valid interpretation.

A second problem is that some people simply make mistakes. Your job is not simply to spot ambiguities but also to counter inconsistencies. Thus if I now advocate that the wise manager should seek out (perhaps humorous) books on entomology (creepy crawlies) you would deduce that the word should have been etymology. More usual, however, is that in thinking over several alternatives you may suffer a momentary confusion and say one of them while meaning another. There are good scientific reasons (to do with the associative nature of the brain) why this happens, you have to be aware of the potential problem and counter for it.

Finally, of course, you may simply mishear. The omission of a simple word could be devastating. For instance, how long would you last as an explosives engineer if you failed to hear a simple negative in: "whatever happens next you must [not] cut the blue wi..."?

So, the problem is this: the word has multiple meanings, it might not be the one intended, and you may have misheard it in the first place - how do you know what the speaker meant?

Rule 1: PLAY BACK for confirmation
Simple, you ask for confirmation. You say "let me see if I have understood correctly, you are saying that ..." and you rephrase what the speaker said. If this "play back" version is acknowledged as being correct by the original speaker, then you have a greater degree of confidence in you own understanding. For any viewpoint/message/decision, there should be a clear, concise and verified statement of what was said; without this someone will get it wrong.
Rule 2: WRITE BACK for confidence
But do not stop there. If your time and effort depend upon it, you should write it down and send it to everyone involved as a double check. This has several advantages:
Further clarification - is this what you thought we agreed?
Consistency check - the act of writing may highlight defects/omissions
A formal stage - a statement of the accepted position provides a spring board from which to proceed
Evidence - hindsight often blurs previous ignorance and people often fail to recall their previous errors
Rule 3: GIVE BACKground for context
When speaking yourself, you can often counter for possible problems by adding information, and so providing a broader context in which your words can be understood. Thus, there is less scope for alternative interpretations since fewer are consistent. When others are speaking, you should deliberately ask questions yourself to establish the context in which they are thinking. When others are speaking, you should deliberately ask questions yourself to establish the context in which they are thinking.
PRACTICAL POINTS
As with all effective communication, you should decide (in advance) on the purpose of the conversation and the plan for achieving it. There is no alternative to this. Some people are proficient at "thinking on their feet" - but this is generally because they already have clear understanding of the context and their own goals. You have to plan; however, the following are a few techniques to help the conversation along.

Assertiveness
The definition of to assert is: "to declare; state clearly". This is your aim. If someone argues against you, even loses their temper, you should be quietly assertive. Much has been written to preach this simple fact and commonly the final message is a three-fold plan of action:
acknowledge what is being said by showing an understanding of the position, or by simply replaying it (a polite way of saying "I heard you already")
state your own point of view clearly and concisely with perhaps a little supporting evidence
state what you want to happen next (move it forward)
Thus we have something like: yes, I see why you need the report by tomorrow; however, I have no time today to prepare the document because I am in a meeting with a customer this afternoon; either I could give you the raw data and you could work on it yourself, or you could make do with the interim report from last week.

You will have to make many personal judgement calls when being assertive. There will certainly be times when a bit of quiet force from you will win the day but there will be times when this will get nowhere, particularly with more senior (and unenlightened) management. In the latter case, you must agree to abide by the decision of the senior manager but you should make your objection (and reasons) clearly known. For yourself, always be aware that your subordinates might be right when they disagree with you and if events prove them so, acknowledge that fact gracefully.

Confrontations
When you have a difficult encounter, be professional, do not lose your self-control because, simply, it is of no use. Some managers believe that it is useful for "discipline" to keep staff a little nervous. Thus, these managers are slightly volatile and will be willing "to let them have it" when the situation demands. If you do this, you must be consistent and fair so that you staff know where they stand. If you deliberately lose your temper for effect, then that is your decision - however, you must never lose control.
Insults are ineffective. If you call people names, then they are unlikely to actually listen to what you have to say; in the short term you may feel some relief at "getting it off your chest", but in the long run you are merely perpetuating the problem since you are not addressing it. This is common sense. There are two implications. Firstly, even under pressure, you have to remember this. Secondly, what you consider fair comment may be insulting to another - and the same problem emerges. Before you say anything, stop, establish what you want as the outcome, plan how to achieve this, and then speak.

Finally, if you are going to criticise or discipline someone, always assume that you have misunderstood the situation and ask questions first which check the facts. This simple courtesy will save you from much embarrassment.

Seeking Information
There are two ways of phrasing any question: one way (the closed question) is likely to lead to a simple grunt in reply (yes, no, maybe), the second way (the open question) will hand over the speaking role to someone else and force them to say something a little more informative.
Suppose you conduct a review of a recently finished (?) project with Gretchen and it goes something like this:

"Have you finished project X Gretchen?"
"Yes"
"If everything written up?"
"Nearly"
"So there is documentation left to do?"
"Some"
"Will it take you long?"
"No, not long"
Before your fingers start twitching to place themselves around Gretchen's neck, consider that your questions are not actually helping the flow of information. The same flow of questions in an open format would be: what is left to do of project X, what about the documentation, when will that be completely finished? Try answering Yes or No to those questions.

Open questions are extremely easy to formulate. You establish in your own mind the topic/aim of the question and then you start the sentence with the words:

WHAT - WHEN - WHICH - WHY - WHERE - HOW
Let others speak
Of course, there is more to a conversation (managed or otherwise) than the flow of information. You may also have to win that information by winning the attention and confidence of the other person. There are many forms of flattery - the most effective is to give people your interest. To get Gretchen to give you all her knowledge, you must give her all your attention; talk to her about her view on the subject. Ask questions: what do you think about that idea, have you ever met this problem before, how would you tackle this situation?
Silence is effective - and much under-used. People are nervous of silence and try to fill it. You can use this if you are seeking information. You ask the question, you lean back, the person answers, you nod and smile, you keep quiet, and the person continues with more detail simply to fill your silence.

To finish
At the end of a conversation, you have to give people a clear understanding of the outcome. For instance, if there has been a decision, restate it clearly (just to be sure) in terms of what should happen and by when; if you have been asking questions, summarize the significant (for you) aspects of what you have learnt.
MEETING MANAGEMENT - PREPARATION
In any organization, "meetings" are a vital part of the organization of work and the flow of information. They act as a mechanism for gathering together resources from many sources and pooling then towards a common objective. They are disliked and mocked because they are usually futile, boring, time-wasting, dull, and inconvenient with nothing for most people to do except doodle while some opinionated has-been extols the virtues of his/her last great (misunderstood) idea. Your challenge is to break this mould and to make your meetings effective. As with every other managed activity, meetings should be planned beforehand, monitored during for effectiveness, and reviewed afterwards for improving their management.

A meeting is the ultimate form of managed conversation; as a manager, you can organize the information and structure of the meeting to support the effective communication of the participants. Some of the ideas below may seem a little too precise for an easy going, relaxed, semi-informal team atmosphere - but if you manage to gain a reputation for holding decisive, effective meetings, then people will value this efficiency and to prepare professionally so that their contribution will be heard.

Should you cancel?
As with all conversations, you must first ask: is it worth your time? If the meeting involves the interchange of views and the communication of the current status of related projects, then you should be generous with your time. But you should always consider canceling a meeting which has little tangible value.
Who should attend?
You must be strict. A meeting loses its effectiveness if too many people are involved: so if someone has no useful function, explain this and suggest that they do not come. Notice, they may disagree with your assessment, in which case they should attend (since they may know something you do not); however, most people are only too happy to be released from yet another meeting.
How long?
It may seem difficult to predict the length of a discussion - but you must. Discussions tend to fill the available time which means that if the meeting is open-ended, it will drift on forever. You should stipulate a time for the end of the meeting so that everyone knows, and everyone can plan the rest of their day with confidence.
It is wise to make this expectation known to everyone involved well in advance and to remind them at the beginning of the meeting. There is often a tendency to view meetings as a little relaxation since no one person has to be active throughout. You can redress this view by stressing the time-scale and thus forcing the pace of the discussion: "this is what we have to achieve, this is how long we have to get it done".

If some unexpected point arises during the meeting then realize that since it is unexpected: 1) you might not have the right people present, 2) those there may not have the necessary information, and 3) a little thought might save a lot of discussion. If the new discussion looks likely to be more than a few moments, stop it and deal with the agreed agenda. The new topic should then be dealt with at another "planned" meeting.

Agenda
The purpose of an agenda is to inform participants of the subject of the meeting in advance, and to structure the discussion at the meeting itself. To inform people beforehand, and to solicit ideas, you should circulate a draft agenda and ask for notice of any other business. Still before the meeting, you should then send the revised agenda with enough time for people to prepare their contributions. If you know in advance that a particular participant either needs information or will be providing information, then make this explicitly clear so that there is no confusion.
The agenda states the purpose of each section of the meeting. There will be an outcome from each section. If that outcome is so complex that it can not be summarized in a few points, then it was probably too complex to be assimilated by the participants. The understanding of the meeting should be sufficiently precise that it can be summarized in short form - so display that summary for all other interested parties to see. This form of display will emphasize to all that meetings are about achieving defined goals - this will help you to continue running efficient meetings in the future.

MEETING MANAGEMENT - CONDUCTING
Whether you actually sit as the Chair or simply lead from the side-lines, as the manager you must provide the necessary support to coordinate the contributions of the participants. The degree of control which you exercise over the meeting will vary throughout; if you get the structure right at the beginning, a meeting can effectively run itself especially if the participants know each other well. In a team, your role may be partially undertaken by others; but if not, you must manage.

Maintaining Communication
Your most important tools are:
Clarification - always clarify: the purpose of the meeting, the time allowed, the rules to be observed (if agreed) by everyone.
Summary - at each stage of the proceedings, you should summarize the current position and progress: this is what we have achieved/agreed, this is where we have reached.
Focus on stated goals - at each divergence or pause, re-focus the proceedings on the original goals.
Code of conduct
In any meeting, it is possible to begin the proceedings by establishing a code of conduct, often by merely stating it and asking for any objections (which will only be accepted if a demonstrably better system is proposed). Thus if the group contains opinionated wind-bags, you might all agree at the onset that all contributions should be limited to two minutes (which focuses the mind admirably). You can then impose this with the full backing of the whole group.
Matching method to purpose
The (stated) purpose of a meeting may suggest to you a specific way of conducting the event, and each section might be conducted differently. For instance, if the purpose is:
to convey information, the meeting might begin with a formal presentation followed by questions
to seek information, the meeting would start with a short (clear) statement of the topic/problem and then an open discussion supported by notes on a display, or a formal brainstorming session
to make a decision, the meeting might review the background and options, establish the criteria to be applied, agree who should make the decision and how, and then do it
to ratify/explain decisions, etc etc
As always, once you have paused to ask yourself the questions: what is the purpose of the meeting and how can it be most effectively achieved; your common sense will then suggest a working method to expedite the proceedings. You just have to deliberately pause. Manage the process of the meeting and the meeting will work.

Support
The success of a meeting will often depend upon the confidence with which the individuals will participate. Thus all ideas should be welcome. No one should be laughed at or dismissed ("laughed with" is good, "laughed at" is destructive). This means that even bad ideas should be treated seriously - and at least merit a specific reason for not being pursued further. Not only is this supportive to the speaker, it could also be that a good idea has been misunderstood and would be lost if merely rejected. But basically people should be able to make naive contributions without being made to feel stupid, otherwise you may never hear the best ideas of all.
Avoid direct criticism of any person. For instance, if someone has not come prepared then that fault is obvious to all. If you leave the criticism as being simply that implicit in the peer pressure, then it is diffuse and general; if you explicitly rebuke that person, then it is personal and from you (which may raise unnecessary conflict). You should merely seek an undertaking for the missing preparation to be done: we need to know this before we can proceed, could you circulate it to us by tomorrow lunch?

Responding to problems
The rest of this section is devoted to ideas of how you might deal with the various problems associated with the volatile world of meetings. Some are best undertaken by the designated Chair; but if he/she is ineffective, or if no one has been appointed, you should feel free to help any meeting to progress. After all, why should you allow your time to be wasted.
If a participant strays from the agenda item, call him/her back: "we should deal with that separately, but what do you feel about the issue X?"

If there is confusion, you might ask: "do I understand correctly that ...?"

If the speaker begins to ramble, wait until an inhalation of breath and jump in: "yes I understand that such and such, does any one disagree?"

If a point is too woolly or too vague ask for greater clarity: "what exactly do you have in mind?"

If someone interrupts (someone other than a rambler), you should suggest that: "we hear your contribution after Gretchen has finished."

If people chat, you might either simply state your difficulty in hearing/concentrating on the real speaker. or ask them a direct question: "what do you think about that point."

If someone gestures disagreement with the speaker (e.g. by a grimace), then make sure they are brought into the discussion next: "what do you think Gretchen?"

If you do not understand, say so: "I do not understand that, would you explain it a little more; or do you mean X or Y?"

If there is an error, look for a good point first: "I see how that would work if X Y Z, but what would happen if A B C?"

If you disagree, be very specific: "I disagree because ..."

CONCLUDING REMARKS
The tower of Babel collapsed because people could no longer communicate; their speech became so different that no one could understand another. You need to communicate to coordinate your own work and that of others; without explicit effort your conversation will lack communication and so your work too will collapse though misunderstanding and error. The key is to treat a conversation as you would any other managed activity: by establishing an aim, planning what to do, and checking afterwards that you have achieved that aim. Only in this way can you work effectively with others in building through common effort.

Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh. His book Starting to Manage: the essential skills is published by Chartwell-Bratt (UK) and the Institute of Electrical and Electronics Engineers (USA). He welcomes feedback either by email (gerard@ee.ed.ac.uk) or by any other method found here

بو حمد · #10 July 18th, 2008, 04:52 PM

PLANNING A PROJECT
by Gerard M Blair

The success of a project will depend critically upon the effort, care and skill you apply in its initial planning. This article looks at the creative aspects of this planning.

THE SPECIFICATION
Before describing the role and creation of a specification, we need to introduce and explain a fairly technical term: a numbty is a person whose brain is totally numb. In this context, numb means "deprived of feeling or the power of unassisted activity"; in general, a numbty needs the stimulation of an electric cattle prod to even get to the right office in the morning. Communication with numbties is severely hampered by the fact that although they think they know what they mean (which they do not), they seldom actually say it, and they never write it down. And the main employment of numbties world-wide is in creating project specifications. You must know this - and protect your team accordingly.

A specification is the definition of your project: a statement of the problem, not the solution. Normally, the specification contains errors, ambiguities, misunderstandings and enough rope to hang you and your entire team. Thus before you embark upon the the next six months of activity working on the wrong project, you must assume that a numbty was the chief author of the specification you received and you must read, worry, revise and ensure that everyone concerned with the project (from originator, through the workers, to the end-customer) is working with the same understanding. The outcome of this deliberation should be a written definition of what is required, by when; and this must be agreed by all involved. There are no short-cuts to this; if you fail to spend the time initially, it will cost you far more later on.

The agreement upon a written specification has several benefits:

the clarity will reveal misunderstandings
the completeness will remove contradictory assumptions
the rigour of the analysis will expose technical and practical details which numbties normally gloss over through ignorance or fear
the agreement forces all concerned to actually read and think about the details
The work on the specification can seen as the first stage of Quality Assurance since you are looking for and countering problems in the very foundation of the project - from this perspective the creation of the specification clearly merits a large investment of time.

From a purely defensive point of view, the agreed specification also affords you protection against the numbties who have second thoughts, or new ideas, half way through the project. Once the project is underway, changes cost time (and money). The existence of a demonstrably-agreed specification enables you to resist or to charge for (possibly in terms of extra time) such changes. Further, people tend to forget what they originally thought; you may need proof that you have been working as instructed.

The places to look for errors in a specification are:

the global context: numbties often focus too narrowly on the work of one team and fail to consider how it fits into the larger picture. Some of the work given to you may actually be undone or duplicated by others. Some of the proposed work may be incompatible with that of others; it might be just plain barmy in the larger context.

the interfaces: between your team and both its customers and suppliers, there are interfaces. At these points something gets transferred. Exactly what, how and when should be discussed and agreed from the very beginning. Never assume a common understanding, because you will be wrong. All it takes for your habitual understandings to evaporate is the arrival of one new member, in either of the teams. Define and agree your interfaces and maintain a friendly contact throughout the project.

time-scales: numbties always underestimate the time involved for work. If there are no time-scales in the specification, you can assume that one will be imposed upon you (which will be impossible). You must add realistic dates. The detail should include a precise understanding of the extent of any intermediate stages of the task, particularly those which have to be delivered.

external dependencies: your work may depend upon that of others. Make this very clear so that these people too will receive warning of your needs. Highlight the effect that problems with these would have upon your project so that everyone is quite clear about their importance. To be sure, contact these people yourself and ask if they are able to fulfil the assumptions in your specification.

resources: the numbty tends to ignore resources. The specification should identify the materials, equipment and manpower which are needed for the project. The agreement should include a commitment by your managers to allocate or to fund them. You should check that the actual numbers are practical and/or correct. If they are omitted, add them - there is bound to be differences in their assumed values.
This seems to make the specification sound like a long document. It should not be. Each of the above could be a simple sub-heading followed by either bullet points or a table - you are not writing a brochure, you are stating the definition of the project in clear, concise and unambiguous glory.

Of course, the specification may change. If circumstances, or simply your knowledge, change then the specification will be out of date. You should not regard it as cast in stone but rather as a display board where everyone involved can see the current, common understanding of the project. If you change the content everyone must know, but do not hesitate to change it as necessary.

PROVIDING STRUCTURE
Having decide what the specification intends, your next problem is to decide what you and your team actually need to do, and how to do it. As a manager, you have to provide some form of framework both to plan and to communicate what needs doing. Without a structure, the work is a series of unrelated tasks which provides little sense of achievement and no feeling of advancement. If the team has no grasp of how individual tasks fit together towards an understood goal, then the work will seem pointless and they will feel only frustration.

To take the planning forward, therefore, you need to turn the specification into a complete set of tasks with a linking structure. Fortunately, these two requirements are met at the same time since the derivation of such a structure is the simplest method of arriving at a list of tasks.

Work Breakdown Structure
Once you have a clear understanding of the project, and have eliminated the vagaries of the numbties, you then describe it as a set of simpler separate activities. If any of these are still too complex for you to easily organise, you break them down also into another level of simpler de******ions, and so on until you can manage everything. Thus your one complex project is organised as a set of simple tasks which together achieve the desired result.
The reasoning behind this is that the human brain (even yours) can only take in and process so much information at one time. To get a real grasp of the project, you have to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units.

In planning any project, you follow the same simple steps: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure to make it sound more formal and impressive. Without following this formal approach you are unlikely to remember all the niggling little details; with this procedure, the details are simply displayed on the final lists.

One common fault is to produce too much detail at the initial planning stage. You should be stop when you have a sufficient de******ion of the activity to provide a clear instruction for the person who will actually do the work, and to have a reasonable estimate for the total time/effort involved. You need the former to allocate (or delegate) the task; you need the latter to finish the planning.

Task Allocation
The next stage is a little complicated. You now have to allocate the tasks to different people in the team and, at the same time, order these tasks so that they are performed in a sensible sequence.
Task allocation is not simply a case of handing out the various tasks on your final lists to the people you have available; it is far more subtle (and powerful) than that. As a manager you have to look far beyond the single project; indeed any individual project can be seen as merely a single step in your team's development. The allocation of tasks should thus be seen as a means of increasing the skills and experience of your team - when the project is done, the team should have gained.

In simple terms, consider what each member of your team is capable of and allocate sufficient complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the ones on your finals lists, they are adapted to better suit the needs of your team's development; tasks are moulded to fit people, which is far more effective than the other way around. For example, if Arthur is to learn something new, the task may be simplified with responsibility given to another to guide and check the work; if Brenda is to develop, sufficient tasks are combined so that her responsibility increases beyond what she has held before; if Colin lacks confidence, the tasks are broken into smaller units which can be completed (and commended) frequently.

Sometimes tasks can be grouped and allocated together. For instance, some tasks which are seemingly independent may benefit from being done together since they use common ideas, information, talents. One person doing them both removes the start-up time for one of them; two people (one on each) will be able to help each other.

The ordering of the tasks is really quite simple, although you may find that sketching a sequence diagram helps you to think it through (and to communicate the result). Pert charts are the accepted outcome, but sketches will suffice. Getting the details exactly right, however, can be a long and painful process, and often it can be futile. The degree to which you can predict the future is limited, so too should be the detail of your planning. You must have the broad outlines by which to monitor progress, and sufficient detail to assign each task when it needs to be started, but beyond that - stop and do something useful instead.

Guesstimation
At the initial planning stage the main objective is to get a realistic estimate of the time involved in the project. You must establish this not only to assist higher management with their planning, but also to protect your team from being expected to do the impossible. The most important technique for achieving this is known as: guesstimation.
Guesstimating schedules is notoriously difficult but it is helped by two approaches:

make your guesstimates of the simple tasks at the bottom of the work break down structure and look for the longest path through the sequence diagram
use the experience from previous projects to improve your guesstimating skills
The corollary to this is that you should keep records in an easily accessible form of all projects as you do them. Part of your final project review should be to update your personal data base of how long various activities take. Managing this planning phase is vital to your success as a manager.

Some people find guesstimating a difficult concept in that if you have no experience of an activity, how can you make a worthwhile estimate? Let us consider such a problem: how long would it take you to walk all the way to the top of the Eiffel Tower or the Statue of Liberty? Presuming you have never actually tried this (most people take the elevator part of the way), you really have very little to go on. Indeed if you have actually seen one (and only one) of these buildings, think about the other. Your job depends upon this, so think carefully. One idea is to start with the number of steps - guess that if you can. Notice, you do not have to be right, merely reasonable. Next, consider the sort of pace you could maintain while climbing a flight of steps for a long time. Now imagine yourself at the base of a flight of steps you do know, and estimate a) how many steps there are, and b) how long it takes you to climb them (at that steady pace). To complete, apply a little mathematics.

Now examine how confident you are with this estimate. If you won a free flight to Paris or New York and tried it, you would probably (need your head examined) be mildly surprised if you climbed to the top in less than half the estimated time and if it took you more than double you would be mildly annoyed. If it took you less than a tenth the time, or ten times as long, you would extremely surprised/annoyed. In fact, you do not currently believe that that would happen (no really, do you?). The point is that from very little experience of the given problem, you can actually come up with a working estimate - and one which is far better than no estimate at all when it comes to deriving a schedule. Guesstimating does take a little practice, but it is a very useful skill to develop.

There are two practical problems in guesstimation. First, you are simply too optimistic. It is human nature at the beginning of a new project to ignore the difficulties and assume best case scenarii - in producing your estimates (and using those of others) you must inject a little realism. In practice, you should also build-in a little slack to allow yourself some tolerance against mistakes. This is known as defensive scheduling. Also, if you eventually deliver ahead of the agreed schedule, you will be loved.

Second, you will be under pressure from senior management to deliver quickly, especially if the project is being sold competitively. Resist the temptation to rely upon speed as the only selling point. You might, for instance, suggest the criteria of: fewer errors, history of adherence to initial schedules, previous customer satisfaction, "this is how long it takes, so how can you trust the other quotes".

ESTABLISHING CONTROLS
When the planning phase is over (and agreed), the "doing" phase begins. Once it is in motion, a project acquires a direction and momentum which is totally independent of anything you predicted. If you come to terms with that from the start, you can then enjoy the roller-coaster which follows. To gain some hope, however, you need to establish at the start (within the plan) the means to monitor and to influence the project's progress.

There are two key elements to the control of a project

milestones (clear, unambiguous targets of what, by when)
established means of communication
For you, the milestones are a mechanism to monitor progress; for your team, they are short-term goals which are far more tangible than the foggy, distant completion of the entire project. The milestones maintain the momentum and encourage effort; they allow the team to judge their own progress and to celebrate achievement throughout the project rather than just at its end.

The simplest way to construct milestones is to take the timing information from the work breakdown structure and sequence diagram. When you have guesstimated how long each sub-task will take and have strung them together, you can identify by when each of these tasks will actually be completed. This is simple and effective; however, it lacks creativity.

A second method is to construct more significant milestones. These can be found by identify stages in the development of a project which are recognisable as steps towards the final product. Sometimes these are simply the higher levels of your structure; for instance, the completion of a market-evaluation phase. Sometimes, they cut across many parallel activities; for instance, a prototype of the eventual product or a mock-up of the new brochure format.

If you are running parallel activities, this type of milestone is particularly useful since it provides a means of pulling together the people on disparate activities, and so:

they all have a shared goal (the common milestone)
their responsibility to (and dependence upon) each other is emphasised
each can provide a new (but informed) viewpoint on the others' work
the problems to do with combining the different activities are highlighted and discussed early in the implementation phase
you have something tangible which senior management (and numbties) can recognise as progress
you have something tangible which your team can celebrate and which constitutes a short-term goal in a possibly long-term project
it provides an excellent opportunity for quality checking and for review
Of course, there are milestones and there are mill-stones. You will have to be sensitive to any belief that working for some specific milestone is hindering rather than helping the work forward. If this arises then either you have chosen the wrong milestone, or you have failed to communicate how it fits into the broader structure.

Communication is your everything. To monitor progress, to receive early warning of danger, to promote cooperation, to motivate through team involvement, all of these rely upon communication. Regular reports are invaluable - if you clearly define what information is needed and if teach your team how to provided it in a rapidly accessible form. Often these reports merely say "progressing according to schedule". These you send back, for while the message is desired the evidence is missing: you need to insist that your team monitor their own progress with concrete, tangible, measurements and if this is done, the figures should be included in the report. However, the real value of this practice comes when progress is not according to schedule - then your communication system is worth all the effort you invested in its planning.

THE ARTISTRY IN PLANNING
At the planning stage, you can deal with far more than the mere project at hand. You can also shape the overall pattern of your team's working using the division and type of activities you assign.

Who know best?
Ask your team. They too must be involved in the planning of projects, especially in the lower levels of the work breakdown structure. Not only will they provide information and ideas, but also they will feel ownership in the final plan.
This does not mean that your projects should be planned by committee - rather that you, as manager, plan the project based upon all the available experience and creative ideas. As an initial approach, you could attempt the first level(s) of the work breakdown structure to help you communicate the project to the team and then ask for comments. Then, using these, the final levels could be refined by the people to whom the tasks will be allocated. However, since the specification is so vital, all the team should vet the penultimate draft.

Dangers in review
There are two pitfalls to avoid in project reviews:
they can be too frequent
they can be too drastic
The constant trickle of new information can lead to a vicious cycle of planning and revising which shakes the team's confidence in any particular version of the plan and which destroys the very stability which the structure was designed to provide. You must decide the balance. Pick a point on the horizon and walk confidently towards it. Decide objectively, and explain beforehand, when the review phases will occur and make this a scheduled milestone in itself.

Even though the situation may have changed since the last review, it is important to recognise the work which has been accomplished during the interim. Firstly, you do not want to abandon it since the team will be demotivated feeling that they have achieved nothing. Secondly, this work itself is part of the new situation: it has been done, it should provide a foundation for the next step or at least the basis of a lesson well learnt. Always try to build upon the existing achievements of your team.

Testing and Quality
No plan is complete without explicit provision for testing and quality. As a wise manager, you will know that this should be part of each individual phase of the project. This means that no activity is completed until it has passed the (objectively) defined criteria which establishes its quality, and these are best defined (objectively) at the beginning as part of the planning.
When devising the schedule therefore you must include allocated time for this part of each activity. Thus your question is not only: "how long will it take", but also: "how long will the testing take". By asking both questions together you raise the issue of "how do we know we have done it right" at the very beginning and so the testing is more likely to be done in parallel with the implementation. You establish this philosophy for your team by include testing as a justified (required) cost.

Fitness for purpose
Another reason for stating the testing criteria at the beginning is that you can avoid futile quests for perfection. If you have motivated your team well, they will each take pride in their work and want to do the best job possible. Often this means polishing their work until is shines; often this wastes time. If it clear at the onset exactly what is needed, then they are more likely to stop when that has been achieved. You need to avoid generalities and to stipulate boundaries; not easy, but essential.
The same is also true when choosing the tools or building-blocks of your project. While it might be nice to have use of the most modern versions, or to develop an exact match to your needs; often there is an old/existing version which will serve almost as well (sufficient for the purpose), and the difference is not worth the time you would need to invest in obtaining or developing the new one. Use what is available whenever possible unless the difference in the new version is worth the time, money and the initial, teething pains.

A related idea is that you should discourage too much effort on aspects of the project which are idiosyncratic to that one job. In the specification phase, you might try to eliminate these through negotiation with the customer; in the implementation phase you might leave these parts until last. The reason for this advice is that a general piece of work can be tailored to many specific instances; thus, if the work is in a general form, you will be able to rapidly re-use it for other projects. On the other hand, if you produce something which is cut to fit exactly one specific case, you may have to repeat the work entirely even though the next project is fairly similar. At the planning phase, a manager should bare in mind the future and the long-term development of the team as well as the requirements of the current project.

Fighting for time
As a manager, you have to regulate the pressure and work load which is imposed upon your team; you must protect them from the unreasonable demands of the rest of the company. Once you have arrived at what you consider to be a realistic schedule, fight for it. Never let the outside world deflect you from what you know to be practical. If they impose a deadline upon you which is impossible, clearly state this and give your reasons. You will need to give some room for compromise, however, since a flat NO will be seen as obstructive. Since you want to help the company, you should look for alternative positions.
You could offer a prototype service or product at an earlier date. This might, in some cases, be sufficient for the customer to start the next stage of his/her own project on the understanding that your project would be completed at a later date and the final version would then replace the prototype.

The complexity of the product, or the total number of units, might be reduced. This might, in some cases, be sufficient for the customer's immediate needs. Future enhancements or more units would then be the subject of a subsequent negotiation which, you feel, would be likely to succeed since you will have already demonstrate your ability to deliver on time.

You can show on an alternative schedule that the project could be delivered by the deadline if certain (specified) resources are given to you or if other projects are rescheduled. Thus, you provide a clear picture of the situation and a possible solution; it is up to your manager then how he/she proceeds.

Planning for error
The most common error in planning is to assume that there will be no errors in the implementation: in effect, the schedule is derived on the basis of "if nothing goes wrong, this will take ...". Of course, recognising that errors will occur is the reason for implementing a monitoring str