Project Management Tutorial

The Secret Of Successful Project Management

2011-09-14T03:52:00.000-07:00

By Jessica Paul

Speak to an experienced project manager, and they can give you a wealth of good advice on the do's and don'ts to successfully manage any project. All this advice, in a nutshell, would be about how to manage the people doing the work (that includes you too), to deliver their results on time and to a budget, while keeping the risk of failure to a minimum.

It really doesn't sound that difficult to do, but for some reason, many people think that project management is a massive overhead to any project. I often hear phrases like "oh, don't waste your time planning the work, just do it!" or "why are you wasting your time writing the objectives, we all know what needs to be done!".

So the number one secret to successfully manage any project is:

"Understand the few essential brief documents you need to create and regularly review during the life of your project."

DOCUMENT #1 - THE PROJECT CHARTER

For example, at the beginning of your project, you need to create a one-page document called the Project Charter. This document will make sure that you and your customer understand the general goals of the project. After all, if you don't know where you are going, how are you going to get there? Remember, you could also be your own customer!

To get this information, have a meeting with your customer and ask the following 3 essential questions:

1. What are the objectives of your project?
2. What do you want to produce or deliver?
3. What is the business reason for doing this project?

After the meeting write the answers to these questions in your Project Charter and email this back to your customer and ask them for their approval.

You have now successfully completed the most important aspect of any project, and that is to understand and agree with your customer where you are going with this project.

If you look at the time spent to achieve this important step in a project, you are looking at one or two meetings and about 30 minutes to write up the information, say 2 hours in total for a small project. Not a big overhead at all.

DOCUMENT #2 - THE PLAN

You can now get on and create the second document call the plan. This will include a list of the work that needs to be done (also referred to as the scope of work), who will do it, the cost and time to do this work, and finally a simple review of what will go wrong (known as a risk assessment).

DOCUMENT #3 - THE PROGRESS REPORT

On a regular basis, anything from weekly to monthly, you need to create a progress report and deliver this to your customer. They want to know what work was done, when, and how much was spent. They also want to know if you need their help to solve any problems. Your major challenge is just collecting this information so that you can create your regular progress report.

A FINAL THOUGHT

I have described the absolute minimum information you need to manage any project, and the secret to success is understanding the few essential brief documents you need to create with this information - the Project Charter, the Plan and the Progress Report. I hope it leads you to success in your projects.

Problems Not Solved by CMMI nor Agile

2011-09-14T00:23:00.000-07:00

This article is extension of ours previous articles for CMMI and Aglie methodologies. You can check them by choosing CMMI and Agile from Categories/Menu.

Part One of each CMMI model describes three aspects of development projects as (1) processes, (2) technology, and (3) people. CMMI makes no secret that it focuses on processes.

Meanwhile, Agile methods clearly focus on people and allow people to determine technology and processes. Regardless of the focus of CMMI or Agile, neither can entirely prevent simple human error, departure of key personnel, impact of incompetent personnel, active or passive insubordination, or deliberate sabotage. Neither can prevent the effect of an employee’s personal life on his or her job performance. Each body of knowledge can have mechanisms to catch and manage such matters, but neither can prevent them any more than either can prevent the local economy from creating a scarcity of qualified employees.

Most organizations have experienced ill-fitting employees and the corresponding challenges in placing them or keeping them employed or happy. Most organizations have had to deal with employee losses, loss of project funding, evaporation of technology resources or suppliers, supply and demand in the marketplace, premature obsolescence of core architectural components, and other issues beyond their immediate control.

While derived and adapted abilities can positively influence the non-development aspects of product and service development, there are many aspects to development that neither CMMI nor Agile, as a first tier implementation, are meant to affect. The conclusion here is that neither CMMI nor Agile are panaceas to all that may hinder development.

Perhaps simply a special guidebook for appraising Agile organizational units or projects or a set of Agile alternative practices associated with CMMI goals accompanied by an overview of Agile values and practices would prove useful.

Fundamentally, misuse is a problem for both CMMI and Agile. One of the original signatories of the Agile Manifesto recently wrote that he was hired to perform due diligence by a venture capital firm that had decided to invest only in companies practicing Agile methods. He found that of the companies he visited and examined, only three percent of those claiming to use Agile methods were actually doing so. (Whether another signatory would judge a similar percent is of course a different, though related issue.)

One of many forms of misuse includes aspects of practice introduction entirely unrelated to either Agile or CMMI. Introducing new practices poorly will likely result in failed implementations regardless of what is being introduced. During a panel session on Agile at SEPG 2006, an audience member asked the panel about an Agile implementation failure at his company. The context of the question was that the adoption of Agile was an executive edict with unrealistic expectations of return on investment, disconnected goals, absent the Agile principles, and devoid of the cultural necessities of long-term change success.. This situation was an organizational behavior matter that neither CMMI nor Agile could immediately resolve.

Project Management Humor

2011-08-22T07:30:00.001-07:00

1. Any task, no matter how complex, can be estimated accurately, once it's completed.
2. The most valuable, and least used, word in a project manager's vocabulary is "no".
3. Nothing is impossible for the person who doesn't have to do it.
4. You can bully a project manager into committing to an impossible project completion date, but you cannot bully him into meeting it.
5. Too few people on a project can't solve the problems - too many create more problems than they solve.
6. A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.
7. A user will tell you anything you ask about, but nothing more.
8. A user is somebody who tells you what they really want the day you give them what they first asked for.
9. The conditions attached to a promise are forgotten, only the promise is remembered.
10. There's never enough time to do it right first time, but there's always enough time to go back and do it again.
11. I know that you believe that you understand what you think I said, but I am not sure you realize that what you heard is not what I meant.
12. The sooner you rush into coding, the later you finish the project.
13. If project scope is allowed to change freely, the rate of change will exceed the rate of progress.
14. Change is inevitable, except from vending machines.
15. The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
16. The bitterness of poor product quality lingers long after the celebration of meeting the project date is forgotten.
17. A verbal contract isn't worth the paper it's written on.
18. What has not been put on paper has not been said.
19. If you fail to plan the project, you are planning to fail the project.
20. The more you plan the project, the luckier you get.
21. If you can keep your head while all about you are losing theirs, you haven't understood the project plan.
22. If you don't attack the project risks, the project risks will attack you.
23. A little bit of project risk management saves a lot of fan cleaning.
24. The sooner you fall behind the project schedule, the more time you have to make it up.
25. When all's said and done, a lot more was said then was done

Existing Project Management Methodologies and Software Development Processes

2011-07-01T00:29:00.000-07:00

There have been a lot of software development processes created over the years. In “Rapid Development”, most of the companies identifies a number of categories of process - most real-life projects employ a blend of these:

Pure waterfall
Code-and-fix
Spiral
Modified Waterfalls
Evolutionary Prototyping
Staged Delivery
Evolutionary Delivery
Design-to-Schedule
Design-to-Tools
Commercial Off-the-shelf Software

With the exception of code-and-fix, these processes have a few things in common – they assume that software development is analogous to a defined industrial process; they are based on physical engineering processes; they are predictive; and they assume that people can be treated as abstract resources. “It is typical to adopt the defined (theoretical) modelling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice”– Process Dynamics, Modelling, and Control, Ogunnaike and Ray, Oxford University Press, 1992

In process control theory, a “defined” process is one that can be designed and run repeatedly with predictable results. In particular, the inputs to the process and the process itself must have very low levels of noise. When a process cannot be defined precisely enough to guarantee predictable results it is known as a “complex” process. Complex processes require an empirical control model. An empirical control model entails frequent inspection and adaptive response.

Software development is not a defined process, at the very least because the main inputs to the process activities are people. Traditional methodologies contain lists of activities and processes that are depicted as reliable and repeatable, however we all know from experience that this isn't the case. Ask two different groups of people to come up with class diagrams from the same requirements and you'll get two quite different results. The problems with treating software development as a defined process are discussed further by Schwaber and Beedle1.

Physical engineering processes consist of distinct phases. Thed esign phase is difficult to predict and requires creativity and imagination. The primary activities in the design phase are intellectual. The design phase is followed by planning for the construction phase, and then by the construction phase itself. The primary activities in the construction phase are physical, and it is much easier to plan and predict than the design phase. In many physical engineering disciplines construction is much bigger in both cost and time than design and planning. For example, when you build a bridge, the cost of design is about 10% of the total job, with the rest being construction.

For the analogy between software development and physical engineering to hold, we need to be able to separate design from construction, be able to produce a predictable schedule, design artefacts that are complete enough for construction to be straightforward, and be able to perform construction with people of lower skills (who are hopefully cheaper to employ). Construction also needs to be sufficiently large in time and effort to make this worthwhile. The situation in software development is quite different. The most of software development companies reports the following breakdown of software development by activity:

Analysis 16%
Design 17%
Code/Unit Test 34%
System/Integration Test 18%
Documentation 8%
Implementation/Install 7%

In an even more extreme analysis proposed by Jack Reeves - he suggests that code is analogous to an engineering design, and that software is “constructed” by running a compiler. Accordingly, the construction stage in a software development project is essentially free.

Regardless of the exact numbers, it's clear that as a percentage of the overall project effort, construction is much less significant in software development than it is in physical engineering. If construction is analogous to coding, our experience indicates that it's very difficult and expensive to

“Agile Software Development with Scrum”, Ken Schwaber and Mike Beedle, Prentice Hall, 2002
“The New Methodology”, Martin Fowler,http://www.martinfowler.com/articles/newMethodology.html
“Worldwide Benchmark Project Report”, Howard Rubin, Rubin Systems Inc., 1995
“What is software design?”, Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

produce design artefacts detailed enough for construction to be straightforward. If construction is analogous to compilation, then we can effectively ignore the construction effort. In either case, processes based on analogies with physical engineering should be treated with suspicion.

The power of communication

2011-06-29T05:18:00.000-07:00

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).

How to make quality estimations

2011-06-22T05:17:00.000-07:00

In this article you will find how you should deal with poorly defined work and what to do when management thinks it should cost less or take less time.

Dealing with Poorly Defined Work
In order to introduce the basic concepts of effort estimating, we limited the discussion to developing an estimate for a single, reasonably well-defined activity. Although this type of work may prevail in some project environments, most projects will have a significant amount of work to estimate that is not well-defined. In this section, I will cover some approaches to those situations.

No one on the team has experience with this kind of work. Here are some ideas that should help:

Find someone who does have experience, e.g., a consultant or someone in the organization who is not on your team.
Use a wider range estimate to reflect the greater uncertainty. Unless the unknown work represents a significant percentage of the total work, your overall project budget will not be greatly affected. Remember that we are willing to tolerate budget variances in individual work items as long as the project total is acceptable.
Break the work down into smaller units. Often, you will find that you do have experience with much of the work. The aspects that you don’t have experience with can be handled with a wider range estimate.
Develop some experience. It may be possible to have one or two team members do a couple of “practice” activities as part of the project planning process. I used this approach quite successfully as part of a database conversion project several years ago.

This is truly state-of-the-art stuff. See previous paragraph, especially the last bullet.

We really have no idea of what’s required or we don’t know enough at this point to define the work. Neither of these two complaints is an estimating issue; they are both either a scoping issue or a risk management issue. They might also be a defensive response to a skeptical manager. If so, see below.

Conflicting Estimates
Did you ever have two team members who differed widely in their opinions of the likely amount of effort required to complete a work item? Range estimates can help, particularly if the individuals involved are inherently optimistic or pessimistic — if their ranges overlap, it is usually much easier to reach agreement.

But the root cause of such difference is most likely to be the presence of conflicting assumptions. For example, a team member who assumes that previous design work can be reused will produce a lower estimate than one who does not. By surfacing the conflicting assumptions, the team can discuss the alternatives and decide what to do.

One particularly pervasive assumption is the skill level of the person doing the work. Estimating is often done by more senior staff, and they tend to think in terms of “how much effort would I personally have to expend to complete this work.” This is likely to produce an estimate that it too low. At the same time, they may become aware of their tendency to overestimate and overcompensate. I recommend that you remind your estimators to constantly assume an “average” resource, and to recognize that it will take 2-3 projects of comparing actuals to estimates for them to get good at knowing what “average” really is.

Converting Effort into Duration
I know that I am going to get a lot of flak from some of my colleagues about this next point. The technically correct answer about how to estimate duration is that you should do just that — look at the effort estimates and develop a three-point range estimate of the duration for each work item. For example, with an effort estimate of 30, 40, and 80 hours to be performed by a single individual working fulltime on the project, I think it is reasonable to predict that this person may need more than two full weeks to get this item done if it ends up requiring 80 hours of effort.
In addition, since virtually all network analysis techniques (Critical Path, Critical Chain, PERT, etc.) underestimate the most likely duration of the project, many would also argue that a Monte Carlo simulation is a necessity. And I would agree … if you’ve got the budget.

If not, take the easy way out — take the effort budget (the expected value of the effort estimate) and convert that into a single-point duration budget based on the availability of the individual assigned.

Maintaining Your Estimates
If the work of the project changes via an approved change order, you will need to estimate the new work and update your budget as well.

If any of the assumptions that went into your estimates are changed, you should also update your estimates. In this case, you may not be able to modify the budget, but you should still re-estimate the work. For example, if one of your most skilled staffers was supposed to work on Work-item D, and due to circumstance beyond your control D is being done by an intern from the local community college, you better reset everyone’s expectations about how long it is going to take.

Management Cuts It in Half
The first thing you have to do is find out why. Most such management actions are created by one of the following misunderstandings:

Your manager may not understand the difference between an estimate and a budget. Educate them. But in the nicest way possible if you want to keep your job.
Your manager may view your estimate as a negotiating position. Some managers assume that you have “padded” your estimate to provide negotiating room. Again, educate them — explain how the suggested cuts will either reduce quality or increase the risk of an overrun.
Your manager’s cuts may be a negotiating position. Most good managers understand that a more difficult task (where the target is aggressive) can serve to motivate the project team. But even good managers often fail to appreciate that an impossible task (where the target is so aggressive that it is clearly impossible) is a powerful DEMOTIVATOR.

Summary and the most important!
Underestimating will drive you crazy. You will spend endless hours explaining why you are over budget and behind schedule. You will spend endless hours dealing with unhappy customers and stressed out team members. Overestimating may not be much better. Your projects will not get approved because they will be seen as too expensive. You may even lose your job if your padding is viewed as unethical.

How to became a great project manager

2011-05-14T00:20:00.000-07:00

by Gerard M Blair

The first steps to becoming a really great manager are simply common sense; but common sense is not very common. This article suggests some common-sense ideas on the subject of great management.

The major problem when you start to manage is that you do not actually think about management issues because you do not recognize them. Put simply, things normally go wrong not because you are stupid but only because you have never thought about it. Management is about pausing to ask yourself the right questions so that your common sense can provide the answers.

When you gain managerial responsibility, your first option is the easy option: do what is expected of you. You are new at the job, so people will understand. You can learn (slowly) by your mistakes and probably you will try to devote as much time as possible to the rest of your work (which is what your were good at anyway). Those extra little "management" problems are just common sense, so try to deal with them when they come up.

Your second option is far more exciting: find an empty telephone box, put on a cape and bright-red underpants, and become a SuperManager.

When you become a manager, you gain control over your own work; not all of it, but some of it. You can change things. You can do things differently. You actually have the authority to make a huge impact upon the way in which your staff work. You can shape your own work environment.

In a large company, your options may be limited by the existing corporate culture - and my advice to you is to act like a crab: face directly into the main thrust of corporate policy, and make changes sideways. You do not want to fight the system, but rather to work better within it. In a small company, your options are possibly much wider (since custom is often less rigid) and the impact that you and your team has upon the company's success is proportionately much greater. Thus once you start working well, this will be quickly recognized and nothing gains faster approval than success. But wherever you work, do not be put off by the surprise colleagues will show when you first get serious about managing well.

STARTING A REVOLUTION

The idea of starting alone, however, may be daunting to you; you may not see yourself as a David against the Goliath of other peoples' (low) expectations. The bad news is that you will meet resistance to change. Your salvation lies in convincing your team (who are most effected) that what you are doing can only do them good, and in convincing everyone else that it can do them no harm. The good news is that soon others might follow you.

There is precedent for this. For instance, when a British firm called Unipart wanted to introduce Japanese methods (Honda's to be precise) into their Oxford plan (The Economist - 11th April 1992 - page 89) they sent a small team to Japan to learn what exactly this meant. On their return, they were mocked by their workmates who saw them as management pawns. So instead they were formed into their own team and sent to work in a corner of the plant where they applied their new knowledge in isolation. Slowly, but surely, their example (and missionary zeal) spread through the factory and changes followed. Now Unipart have opened a new factory and the general manger of the first factory attributes the success to "releasing talent already on the shop floor". Of course one can always find case studies to support any management idea, but it does exemplify the potential of a small cell of dedicated zealots - led by you.

THREE FACES OF A MANAGER

The manger of a small team has three major roles to play:

Planner

A Manager has to take a long-term view; indeed, the higher you rise, the further you will have to look. While a team member will be working towards known and established goals, the manager must look further ahead so that these goals are selected wisely. By thinking about the eventual consequences of different plans, the manager selects the optimal plan for the team and implements it. By taking account of the needs not only of the next project but the project after that, the manager ensures that work is not repeated nor problems tackled too late, and that the necessary resources are allocated and arranged.

Provider

The Manager has access to information and materials which the team needs. Often he/she has the authority or influence to acquire things which no one else in the team could. This role for the manager is important simply because no one else can do the job; there is some authority which the manager holds uniquely within the team, and the manager must exercise this to help the team to work.

Protector

The team needs security from the vagaries of less enlightened managers. In any company, there are short-term excitements which can deflect the work-force from the important issues. The manager should be there to guard against these and to protect the team. If a new project emerges which is to be given to your team, you are responsible for costing it (especially in terms of time) so that your team is not given an impossible deadline. If someone in your team brings forward a good plan, you must ensure that it receives a fair hearing and that your team knows and understands the outcome. If someone is in your team has a problem at work, you have to deal with it.

Version Two

That was rather formal. If you like formal, then you are happy. If you do not like formal then here is an alternative answer, a manager should provide:

VISION - VALUES - VERVE

Vision in that the future must be seen and communicated to the team; Values in that the team needs a unifying code of practice which supports and enhances co-operation; Verve in that positive enthusiasm is the best way of making the work exciting and fun. If you do not think your work is exciting, then we have found a problem. A better word than Verve might be Chutzpah (except that it does not begin with a "V") which means "shameless audacity". Is that not refreshing? Inspiring even? A manager should dare to do what he/she has decided to do and to do it with confidence and pride.

VISION

One of the most cited characteristics of successful managers is that of vision. Of all the concepts in modern management, this is the one about which the most has been written. Of course different writters use it in different ways. One usage brings it to mean clairvoyance as in: "she had great vision in foreseeing the demise of that market". This meaning is of no use to you since crystal balls are only validated by hindsight and this article is concerned with your future.

The meaning of vision which concerns you as a manager is: a vivid idea of what the future should be. This has nothing to do with prediction but everything to do with hope. It is a focus for the team's activity, which provides sustained long-term motivation and which unites your team. A vision has to be something sufficiently exciting to bind your team with you in common purpose. This implies two things:

you need to decide where your team is headed
you have to communicate that vision to them

Communicating a vision is not simply a case of painting it in large red letters across your office wall (although, as a stunt, this actually might be quite effective), but rather bringing the whole team to perceive your vision and to begin to share it with you. A vision, to be worthy, must become a guiding principle for the decision and actions of your group.

Now, this vision thing, it is still a rather nebulous concept, hard to pin down, hard to define usefully; a vision may even be impractical (like "zero defects"). And so there is an extra stage which assists in its communication: once you have identified your vision, you can illustrate it with a concrete goal, a mission. Which leads to the creation of the famous "mission statement". Let us consider first what is a mission, and then return to a vision.

A mission has two important qualities:

it should be tough, but achievable given sufficient effort
it must be possible to tell when it has been achieved

To maintain an impetus, it might also have a time limit so that people can pace their activity rather than getting winded in the initial push. The scope of your vision depends upon how high you have risen in the management structure, and so also does the time limit on your mission statement. Heads of multinational corporations must take a longer view of the future than the project leader in divisional recruitment; the former may be looking at a strategy for the next twenty-five years, the latter may be concerned with attracting the current crop of senior school children for employment in two-three years. Thus a new manager will want a mission which can be achieved within one or two years.

If you are stuck for a mission, think about using Quality as a focus since this is something on which you can build. Similarly, any aspects of great management which are not habitual in your team at the moment could be exemplified in a mission statement. For instance, if your team is in product design, your mission might be to fully automate the test procedures by the next product release; or more generally, your team mission might be to reduce the time spent in meetings by half within six months.

Once you have established a few possible mission statements, you can try to communicate (or decide upon) your vision. This articulates your underlying philosophy in wanting the outcomes you desire. Not, please note, the ones you think you should desire but an honest statement of personal motivation; for it is only the latter which you will follow with conviction and so of which you will convince others. In general, your vision should be unfinishable, with no time limit, and inspirational; it is the driving force which continues even when the mission statement has been achieved. Even so, it can be quite simple: Walt Disney's vision was "to make people happy". As a manager, yours might be something a little closer to your own team: mine is "to make working here exciting".

There is no real call to make a public announcement of your vision or to place it on the notice board. Such affairs are quite common now, and normally attract mirth and disdain. If your vision is not communicated to your team by what you say and do, then you are not applying it yourself. It is your driving motivation - once you have identified it, act on it in every decision you make.

PRESCIENCE

Prescience is something for which you really have to work at. Prescience is having foreknowledge of the future. Particularly as a Protector, you have to know in advance the external events which impact upon your team. The key is information and there are three type:

information you hear (tit-bits about travel, meetings, etc)
information you gather (minutes of meetings, financial figure, etc)
information you infer (if this happens then my team will need ...)

Information is absolutely vital. Surveys of decision making in companies reveal that the rapid and decisive decisions normally stem not from intuitive and extraordinary leadership but rather from the existence of an established information system covering the relevant data. Managers who know the full information can quickly reach an informed decision.

The influences upon you and your team stem mostly from within the company and this is where you must establish an active interest. Let us put that another way: if you do not keep your eyes open you are failing in your role as Protector to you team. Thus if your manager comes back from an important meeting, sit down with him/her afterwards and have a chat. There is no need to employ subterfuge, merely ask questions. If there are answers, you hear them; if there are none, you know to investigate elsewhere. If you can provide your manager with suggestions/ideas then you will benefit from his/her gratitude and future confidence(s). You should also talk to people in other departments; and never forget the secretaries who are normally the first to know everything.

Now some people love this aspect of the job, it makes them feel like politicians or espionage agents; others hate it, for exactly the same reasons. The point is that it must be done or you will be unprepared; but do not let it become a obsession.

Gathering information is not enough on its own: you have to process it and be aware of implications. The trick is to try to predict the next logical step from any changes you see. This can get very complicated, so try to restrict yourself to guessing one step only. Thus if the sales figures show a tailing off for the current product (and there are mutterings about the competition) then if you are in development, you might expect to be pressured for tighter schedules; if you are in publicity, then there may soon be a request for launch material; if you are in sales, you might be asked to establish potential demand and practical pricing levels. Since you know this, you can have the information ready (or a schedule defence prepared) for when it is first requested, and you and your team will shine.

Another way of generating information is to play "what if" games. There are dreadfully scientific ways of performing this sort of analysis, but reasonably you do not have the time. The sort of work this article is suggesting is that you, with your team or other managers (or both), play "what if" over coffee now and then. All you have to do is to postulate a novel question and see how it runs.

A productive variation on the "what if" game is to ask: "what can go wrong?" By deliberately trying to identify potential problems at the onset, you will prevent many and compensate for many more. Set aside specific time to do this type of thinking. Call it contingency planning and put in in your diary as a regular appointment.

FLEXIBILITY

One of the main challenges in management is in avoiding pat answers to everyday questions. There is nothing so dull, for you and your team, as you pulling out the same answer to every situation. It is also wrong. Each situation, and each person, is unique and no text-book answer will be able to embrace that uniqueness - except one: you are the manager, you have to judge each situation with a fresh eye, and you have to create the response. Your common sense and experience are your best guide in analysing the problem and in evolving your response.

Even if the established response seems suitable, you might still try something different. This is simple Darwinism. By trying variations upon standard models, you evolve new and potentially fitter models. If they do not work, you do not repeat them (although they might be tried in other circumstances); if they work better, then you have adapted and evolved.

This deliberate flexibility is not just an academic exercise to find the best answer. The point is that the situation and the environment are continually changing; and the rate of change is generally increasing with advancing technology. If you do not continually adapt (through experimentation) to accommodate these changes, then the solution which used to work (and which you still habitually apply) will no longer be appropriate. You will become the dodo. A lack of flexibility will cause stagnation and inertia. Not only do you not adapt, but the whole excitement of your work and your team diminish as fresh ideas are lacking or lost.

Without detracting from the main work, you can stimulate your team with changes of focus. This includes drives for specific quality improvements, mission statements, team building activities, delegated authority, and so on. You have to decide how often to "raise excitement" about new issues. On the one hand, too many focuses may distract or prevent the attainment of any one; on the other hand, changes in focus keep them fresh and maintain the excitement.

By practising this philosophy yourself, you also stimulate fresh ideas from your team because they see that it is a normal part of the team practice to adopt and experiment with innovation. Thus not only are you relieved of the task of generating the new ideas, but also your team acquire ownership in the whole creative process.

The really good news is that even a lousy choice of focus can have a beneficial effect. The most famous experiments in management studies were conducted between 1927 and 1932 by E Mayo and others at the Hawthorne works of the Western Electric Company in Chicago. The study was originally motivated by a failed experiment to determine the effect of lighting conditions on the production rates of factory workers. This experiment "failed" because when the lighting conditions were changed for the experimental group, production also increased in the control group where no changes had been made. Essentially, Mayo took a small group of workers and varied different conditions (number and duration of breaks, shorter hours, refreshments, etc) to see how these actually affected production. The problem was not that production was uneffected but rather that whatever Mayo did, production increased; even when conditions were returned to the original ones, production increased.

After many one-to-one interviews, Mayo deduced that the principal effect of his investigations had been to establish a team spirit amongst the group of workers. The girls (sic) who had formally worked with large numbers of others were now a small team, they were consulted on the experiments, and the researchers displayed a keen interest in the way the girls were working and feeling about their work. Thus their own involvement and the interest shown in them were the reasons for the girl's increased productivity.

By providing changes of focus you build and motivate your team. For if you show in these changes that you are actively working to help them work, then they will feel that their efforts are recognized. If you also include their ideas in the changes, then they will feel themselves to be a valued part of the team. If you pace these changes correctly, you can stimulate "multiple Hawthorne effects" and continually increase productivity. And notice, this is not slave driving. The increased productivity of a Hawthorne effect comes from the enthusiasm of the workforce; they actually want to work better.

A GENERAL APPROACH

In management there is always a distant tune playing in the background. Once you hear this tune, you will start humming it to yourself: in the shower, in the boardroom, on the way to work, when watching the sunrise. It is a simple tune which repeats again and again in every aspect of your managerial life; if goes:

PLAN - MONITOR - REVIEW

Before you start any activity you must STOP and THINK about it: what is the objective, how can it be achieved, what are the alternatives, who needs to be involved, what will it cost, is it worth doing? When you have a plan you should STOP and THINK about how to ensure that your plan is working. You must find ways of monitoring your progress, even if it is just setting deadlines for intermediate stages, or counting customer replies, or tracking the number of soggy biscuits which have to be thrown away, whatever: choose something which displays progress and establish a procedure to ensure that happens. But before you start, set a date on which you will STOP again and reTHINK your plan in the light of the evidence gathered from the monitoring.

Whenever you have something to do, consider not only the task but first the method. Thus if there is a meeting to decide the marketing slogan for the new product you should initially ignore anything to do with marketing slogans and decide: 1) how should the meeting be held, 2) who can usefully contribute, 3) how will ideas be best generated, 4) what criteria are involved in the decision, 5) is there a better way of achieving the same end, 6) etc. If you resolve these points first, all will be achieved far more smoothly. Many of these decisions do not have a single "right" answer, the point is that they need to have "an" answer so that the task is accomplished efficiently. It is the posing of the questions in the first place which will mark you out as a really great manager - the solutions are available to you through common sense.

Once the questions are posed, you can be creative. For instance, "is there a better way of producing a new slogan?" could be answered by a quick internal competition within the company (answers on a postcard by tomorrow at noon) asking everybody in the company to contribute an idea first. This takes three minutes and a secretary to organise, it provides a quick buzz of excitement throughout the whole company, it refocuses everyone's mind on the new product and so celebrates its success, all staff feel some ownership of the project, and you start the meeting with several ideas either from which to select a winner or to use as triggers for further brainstorming. Thus with a simple -- pause -- from the helter-skelter of getting the next job done, and a moment's reflection, you can expedite the task and build team spirit throughout the entire company.

It is worth stressing the relative importance of the REVIEW. In an ideal world where managers are wise, information is unambiguous and always available, and the changes in life are never abrupt or large; it would be possible for you to sit down and to plan the strategy for your group. Unfortunately, managers are mortals, information is seldom complete and always inaccurate (or too much to assimilate), and the unexpected always arrives inconveniently. The situation is never seen in black and white but merely in a fog of various shades of grey. Your planning thus represents no more than the best guess you can make in the current situation; the review is when you interpret the results to deduce the emerging, successful strategy (which might not be the one you had expected). The review is not merely to fine-tune your plan, it is to evaluate the experiment and to incorporate the new, practical information which you have gathered into the creation of the next step forward; you should be prepared for radical changes.

LEADERSHIP

There is a basic problem with the style of leadership advocated in this article in that nearly every historic "Leader" one can name has had a completely different approach; Machiavelli did not advocate being a caring Protector as a means of becoming a great leader but rather that a Prince ought to be happy with "a reputation for being cruel in order to keep his subjects unified and loyal". Your situation, however, is a little different. You do not have the power to execute, nor even to banish. The workforce is rapidly gaining in sophistication as the world grows more complex. You cannot effectively control through fear, so you must try another route. You could possibly gain compliance and rule your team through edict; but you would lose their input and experience, and gain only the burdens of greater decision making. You do not have the right environment to be a despot; you gain advantage by being a team leader.

A common mistake about the image of a manager is that they must be loud, flamboyant, and a great drinker or golfer or racket player or a great something social to draw people to them. This is wrong. In any company, if you look hard enough, you will find quiet modest people who manager teams with great personal success. If you are quiet and modest, fear not; all you need is to talk clearly to the people who matter (your team) and they will hear you.

The great managers are the ones who challenge the existing complacency and who are prepared to lead their teams forward towards a personal vision. They are the ones who recognise problems, seize opportunities, and create their own future. Ultimately, they are the ones who stop to think where they want to go and then have the shameless audacity to set out.

Build High Quality Team with Minimum Effort

2011-02-27T13:04:00.000-08:00

by Gerard M Blair

Quality is primarily viewed in terms of corporate culture, multi-departmental ad-hoc task forces and the salvation of entire companies. This article, instead, will view these ideas as they might be applied by a Team Leader with a small permanent staff.

Quality has become the philosophers' stone of management practice with consultants and gurus vying to charm lead-laden corporations into gold-winning champions. Stories abound of base companies with morose workers and mounting debts being transformed into happy teams and healthy profits; never a day goes by without a significant improvement, a pounds-saving suggestion or a quantum leap in efficiency. With this professed success of "Quality" programmes, there has evolved a proscriptive mythology of correct practise which has several draw backs:

the edicts call for nothing less than a company wide, senior-management led programme
the adherence to a single formula has a limited effect, precludes innovation outside these boundaries, and reduces the differentiation which such programmes profess to engender
the emphasis on single-task, specially formed groups shifts the focus away from the ordinary, daily bread-and-butter

Of course, these criticisms do not invalidate the ideas of Quality but are simply to suggest that the principles might well be viewed from a new angle - and applied at a different level. This article attempts to provide a new perspective by re-examining some of the tenets of Quality in the context of a small, established team: simply, what could a Team Leader do with his/her staff.

What is "Quality"?

In current management writings "Quality" has come to refer to a whole gambit of practices which themselves have resulted in beneficial side-effects; as a Team Leader, you will want to take advantage of these benefits also.

The Customer

In simple terms, attaining Quality has something to do with satisfying the expectations of the customer. Concern for the wishes and needs of customers becomes the focus for every decision. What the customer wants, the company provides. This is not philanthropy, this is basic survival. Through careful education by competitors, the customer has begun to exercise spending power in favour of quality goods and services; and while quality is not the sole criterion in selecting a particular supplier, it has become an important differentiator.

If one ten-pence ball-point runs dry in one month and another ten-pence ball-point lasts for three then the second ball-point is the make which the customer will buy again and which he/she recommends to others - even if it costs a little more. The makers of the first ball-point may have higher profit margins, but eventually no sales; without quality in the product, a company sacrifices customers, revenue and ultimately its own existence. In practical terms, Quality is that something extra which will be perceived by the customer as a valid reason for either paying more or for buying again.

In the case where the product is a service, Quality is equated with how well the job is done and especially with whether the customer is made to feel good about the whole operation. In this respect Quality often does cost more, but the loss is recouped in the price customers are prepared to pay and in the increase of business.

Reliability

The clearest manifestation of Quality is in a product's reliability: that the product simply works. To prevent problems from arising after the product is shipped, the quality must be checked before-hand - and the best time to check quality is throughout the whole design and manufacturing cycle. The old method of quality control was to test the completed product and then to rework to remove the problems. Thus while the original production time was short, the rework time was long. The new approach to quality simply asserts that if testing becomes an integral part of each stage of production, the production time may increase but the rework time will disappear. Further, you will catch and solve many problems which the final "big-bang" quality-check would miss but which the customer will find on the first day.

To achieve this requires an environment where the identification of errors is considered to be "a good thing", where the only bad bugs are the ones which got away. One of the most hallowed doctrines of Quality is that of zero defects. "Zero defects" is a focus, it a glorious objective, it is the assertion that nothing less will suffice and that no matter how high the quality of a product, it can still be improved. It is a paradox in that it is an aim which is contrary to reason, and like the paradoxes of many other religions it holds an inner truth. This is why the advocates of Quality often seem a little crazy: they are zealots.

People as Resource

While Quality has its own reward in terms of increased long-term sales, the methods used to achieve this Quality also have other benefits. In seeking to improve the quality of the product, manufacturers have found that the people best placed to make substantial contributions are the workforce: people are the most valuable resource. It is this shift in perspective from the management to the workforce which is the most significant consequence of the search for quality. From it has arisen a new managerial philosophy aimed at the empowerment of the workforce, decision-making by the front line, active worker involvement in the company's advancement; and from this new perspective, new organizational structures have evolved, exemplified in "Quality Circles".

Without digressing too much, it is important to examine the benefits of this approach. For such delegation to be safely and effectively undertaken, the management has to train the workforce; not necessarily directly, and not all at once, but often within the Quality Circles themselves using a single "facilitator" or simply peer-coaching. The workforce had to learn how to hold meetings, how to analyse problems, how to take decisions, how to present solutions, how to implement and evaluate change. These traditionally high-level managerial prerogatives are devolved to the whole staff. Not only does this develop talent, it also stimulates interest. Staff begin to look not only for problems but also for solutions. Simple ideas become simply implemented: the secretary finally gets the filing cabinet moved closer to the desk, the sales meetings follow an agenda, the software division creates a new bulletin board for the sports club. The environment is created where people see problems and fix 'em.

Larger problems have more complex solutions. One outcome of the search for Quality in Japan is the system of Just-In-Time flow control. In this system, goods arrive at each stage of the manufacturing process just before they are needed and are not made until they are needed by the next stage. This reduces storage requirements and inventory costs of surplus stock. Another outcome has been the increased flexibility of the production line. Time to change from one product run to the next was identified as a major obstacle in providing the customer with the desired range of products and quantities, and so the whole workforce became engaged in changing existant practices and even in redesigning the machinery.

The Long Term

However, I believe that the most significant shift in perspective which accompanies the introduction of Quality is that long term success is given precedence over short term gains. The repeat-sale and recommendation are more important than this month's sales figures; staff training and development remain in place despite immediate schedule problems; the product's reliability is paramount even over time-to-market. Time is devoted today to saving time in the future and in making products which work first and every time.

Team Quality

While the salvation of an entire corporation may rest primarily with Senior Management, the fate of a team rests with the Team Leader. The Team Leader has the authority, the power to define the micro-culture of the work team. It is by the deliberate application of the principles of Quality that the Team Leader can gain for the team the same benefits which Quality can provide for a corporation.

The best ideas for any particular team are likely to come from them - the aim of the Team Leader must be to act as a catalyst through prompts and by example; the following are possible suggestions.

Getting Started

There will be no overnight success. To be lasting, Quality must become a habit and a habit is accustomed practise. This takes time and training - although not necessarily formal training but possibly the sort of reinforcement you might give to any aspect of good practise. To habituate your staff to Quality, you must first make it an issue. Here are two suggestions.

The first idea is to become enthusiastic about one aspect at a time, and initially look for a quick kill. Find a problem and start to talk about it with the whole team; do not delegate it to an individual but make it an issue for everybody. Choose some work-related problem like "how to get the right information in time" and solicit everybody's views and suggestions - and get the problem solved. Demand urgency against a clear target. There is no need to allocate large amounts of resource or time to this, simply raise the problem and make a fuss. When a solution comes, praise it by rewarding the whole team, and ensure that the aspects of increased efficiency/productivity/calm are highlighted since this will establish the criteria for "success". Next, find another problem and repeat.

The second idea is the regular weekly meeting to discuss Quality. Of course meetings can be complete time wasters, so this strategy requires care. The benefits are that regularity will lead to habit, the formality will provide a simple opportunity for the expression of ideas, and the inclusion of the whole group at the meeting will emphasize the collective responsibility. By using the regular meeting, you can establish the "ground rules" of accepted behaviour and at the same time train the team in effective techniques.

One problem is that the focus on any one particular issue may quickly loose its efficacy. A solution is to have frequent shifts in focus so that you maintain the freshness and enthusiasm (and the scope for innovative solutions). Further benefits are that continual shifts in emphasis will train your team to be flexible, and provide the opportunity for them to raise new issues. The sooner the team takes over the definition of the "next problem", the better.

Initial Phases

The initial phases are delicate. The team will be feeling greater responsibility without extra confidence. Thus you must concentrate on supporting their development. Essentially you will be their trainer in management skills. You could get outside help with this but by undertaking the job yourself, you retain control: you mould the team so that they will reflect your own approach and use your own criteria. Later they will develop themselves, but even then they will understand your thinking and so your decisions.

One trap to avoid is that the team may focus upon the wrong type of problem. You must make it clear any problem which they tackle should be:

related to their own work or environment
something which they can change

This precludes gripe sessions about wages and holidays.

As with all group work, the main problem is clarity. You should provide the team with a notice board and flip-charts specifically for Quality problems. These can then be left on display as a permanent record of what was agreed.

If you can, steer the group first to some problem which has a simple solution and with obvious (measurable) benefits. A quick, sharp success will motivate.

Team Building

To succeed, a Quality push must engage the enthusiasm of the entire team; as Team Leader, you must create the right atmosphere for this to happen. Many aspects of team building can be addressed while Quality remains the focus.

You must create the environment where each team member feels totally free to express an idea or concern and this can only be done if there is no stigma attached to being incorrect. No idea is wrong - merely non-optimal. In each suggestion there is at least a thread of gold and someone should point it out and, if possible, build upon it. Any behaviour which seeks laughter at the expense of others must be swiftly reprimanded.

One crude but effective method is to write down agreed ground rules and to display them as a constant reminder for everyone, something like:

all criticism must be kind and constructive
all our-problems are all-our problems
BUGS WANTED: DEAD OR ALIVE (but not for long)
if it saves time later, do it now

Another method is to constantly talk about the group as the plural pronoun: "we decided", "we can do this", "we'll get back to you". This is especially effective if it is used in conversation with outsiders (especially management) within ear-shot of the team. Praise and reward the whole team; get the team wider fame by a success story in an internal newspaper.

Most importantly, you must enable failure. If the team is unable to try out ideas without rebuke for errors, then the scope of their solutions will be severely limited. Instead, a failure should be an opportunity to gain knowledge and to praise any safe-guards which were included in the plan.

Mutual Coaching

An important aspect of team interaction is the idea of mutual support. If you can instill the idea that all problems are owned by the entire team then each member will be able to seek help and advice when needed from every other team member. One promoter of this is to encourage mutual coaching. If one team member knows techniques or information which would be useful to the rest, then encourage him/her to share it. Specifically this will raise the profile, confidence and self-esteem of the instructor at the same time as benefiting the entire group. And if there is one member who might never have anything useful to impart - send him/her to a conference or training session to find something.

Statistics

One of the central tenets of Quality programmes is the idea of monitoring the problem being addressed: Statistical Quality Control. Quite simply, if you can't measure an improvement, it probably isn't there. Gathering statistics has several benefits in applying Quality:

it identifies (the extent of) the problem
it allows progress to be monitored
it provides an objective criterion for the abandonment of an idea
it can justify perceived expense in terms of observed savings/improvements
it motivates staff by providing a display of achievement

and, of course, some problems simply disappear when you try to watch them.

The statistics must be gathered in an objective and empirical manner, the outcome should be a simple table or graph regularly updated to indicate progress, and these results must be displayed where all the team can watch. For example, if your team provides product support, then you might monitor and graph the number of repeat enquiries or the average response time. Or if you are in product development, you might want to monitor the number of bugs discovered (i.e. improvement opportunities).

In the long term, it may be suitable to implement the automatic gathering of statistics on a wide range of issues such as complaints, bug reports, machine down-time, etc. Eventually these may either provide early warning of unexpected problems, or comparative data for new quality improvement projects. It is vital, however, that they focus upon an agreed problem and not upon an individual's performance or else all the positive motivation of staff involvement will be lost.

Projects

Clarity of purpose - this is the key to success. You need a simple, stated objective which everybody understands and which everybody can see achieved.

Any plan to improve the quality or effectiveness of the group must contain:

the objective
the method
the statistical display for monitoring the outcome
the agreed criteria for completion or curtailment

By insisting on this format, you provide the plan-owners with a simple mechanism for peer recognition (through the displayed notice board) and yet enable them to manage their own failure with grace.

For a small established team, the "customer" includes any other part of the company with which the team interacts. Thus any themes regarding customer satisfaction can be developed with respect to these so called internal customers. In the end, the effectiveness of your team will be judged by the reports of how well they provide products for others.

A simple innovation might be for a member of your team to actually talk to someone from each of these internal customer groups and to ask about problems. The interfaces are usually the best place to look for simply solved problems. The immediate benefit may be to the customer, but in the long run better communications will lead to fewer misunderstandings and so less rework.

Building Quality

Quality costs less than its lack; look after the pennies and the profits will take care of themselves. To build a quality product, you must do two things:

worry the design and the procedures
include features to aid quality checking

It is a question of attitude. If one of the team spots a modification in the design or the procedures which will have a long term benefit, then that must be given priority over the immediate schedule. The design is never quite right; you should allocate time specifically to discussing improvement. In this you should not aim at actual enhancements in the sense of added features or faster performance, but towards simplicity or predicting problem areas. This is an adjunct to the normal design or production operations - the extra mile which lesser teams would not go.

Many products and services do not lend themselves to quality monitoring. These should be enhanced so that the quality becomes easily tracked. This may be a simple invitation for the "customer" to comment, or it could be a full design modification to provide self-checking or an easy testing routine. Any product whose quality can not be tracked should naturally become a source of deep anxiety to the whole team - until a mechanism is devised.

One of the least-used sources of quality in design and production in the engineering world is documentation. This is frequently seen as the final inconvenience at product release, sometimes even delegated to another (non-technical) group - yet the writing of such documentation can be used as an important vehicle for the clarification of ideas. It also protects the group from the loss of any single individual; the No.7 bus, or the head-hunter, could strike at any time.

In devising a mechanism for monitoring quality, many teams will produce a set of test procedures. As bugs emerge, new procedures should be added which specifically identify this problem and so check the solution. Even when the problem is solved the new procedures should remain in the test set; the problem may return (perhaps as a side effect of a subsequent modification) or the procedure may catch another. Essentially the test set should grow to cover all known possibilities of error and its application should, where possible, be automated.

Role Change

As your team develops, your role as leader changes subtly. You become a cross between a priest and a rugby captain, providing the vision and the values while shouting like crazy from the centre of the field. Although you retain the final say (that is your responsibility), the team begins to make decisions. The hardest part, as with all delegation, is in accepting the group decision even though you disagree. You must never countermand a marginal decision. If you have to over-rule the team, it is imperative that you explain your reasons very clearly so that they understand the criteria; this will both justify your intervention and couch the team in (hopefully) good decision-making practices.

Another role which you assume is that of both buffer and interface between the team and the rest of the company: a buffer in that you protect the team from the vagaries of less enlightened managers; an interface in that you keep the team informed about factors relevant to their decisions. Ultimately, the team will be delegating to you (!) tasks which only you, acting as manager, can perform on its behalf.

How to work with me - general list of rules of working in the team

2011-02-08T05:14:00.000-08:00

In short, this is a general list of rules if you're working with me. Starting:

I prefer to work fast, minimize bullshit, get to the point.
You will sometimes have bad news for me. I want it immediately. I can usually show you how to fix it. And I never blame the messenger.
Bring pen and paper to every meeting with me. Pay attention to what I say; I'll try to speak with care. If I frequently must repeat instructions, or remind you of something I've already told you, you will not work with me again.
If I've scheduled a weekly meeting with you, don't assume that this meeting is the only time to raise issues with me; Interrupt me for time critical issues.
If you have a meeting with me at an assigned time, and I am in another meeting with my door closed, interrupt me. I stack meetings, and each meeting leads into the next.
I like "micro-meetings". Get in quick, bring only the necessary parties to the table, make a decision, get out. Five minutes or less. Make these effective by knowing what decision needs to be made before you start, and presenting the decision criteria ahead of time to all participants.
Stand during micro-meetings.
I don't like email, particularly for discussing complex topics. If a decision needs to be made, do a micro-meeting. If a problem needs to be discussed, ask the person with the most depth to prepare something, an agenda, have a whiteboard, and work through it quickly.
One exception to the above: I like "micro-updates": Quick emails confirming time critical commitments and mutual understanding. These are especially useful after we hold a meeting and I give you a set of directives: I always like to hear our agreed-upon commitments echoed back to me. I may not respond, but I will read it. Keep these emails short: Spare me the greetings, thank yous, regards.
Be consistent in your communication. Use words consistently. Use email headers consistently. Strive to make your work immediately comprehensible.
If you disagree with me, voice your differences. I welcome and invite dissent. If this makes you uncomfortable, feel free to prepare your thoughts after the meeting and then later return to make your case.
Ego-driven debates annoy me. Check your ego at the door: I'm only interested in reaching the best, most elegant solution —I don't care if it's your idea or mine.
Don't be afraid to ask questions if you're not clear. I have more patience for explaining and clarifying my position before you start than I do patience for fixing a wasteful, incorrect approach after the fact.
Don't tell me something is in the process of being done without telling me when it will be done. I'm more interested in the time commitment than the fact that an effort exists.
Always give me options, informed by an economic analysis where possible (if there are dollars involved, an analysis is mandatory), and then make your recommendation. Don't tell me there's a problem without offering a solution. Don't offer me multiple solutions without giving me your best and final recommendation.
If you must prepare reports for me, review spreadsheets I've created. Copy the style and format.
Don't send me long documents. I like precision and concision. Say it on one page (or less).

This author of this article is @darkgoyle

Time Management for Busy Managers

2011-01-24T02:50:00.000-08:00

by Gerard M Blair

Time passes, quickly. This article looks at the basics of Personal Time Management and describes how the Manager can assume control of this basic resource.

The "Eff" words

The three "Eff" words are [concise OED]:

Effective - having a definite or desired effect
Efficient - productive with minimum waste or effort
Effortless -

seemingly without effort; natural, easy

Personal Time Management is about winning the "Eff" words: making them apply to you and your daily routines.

What is Personal Time Management?

Personal Time Management is about controlling the use of your most valuable (and undervalued) resource. Consider these two questions: what would happen if you spent company money with as few safeguards as you spend company time, when was the last time you scheduled a review of your time allocation?

The absence of Personal Time Management is characterized by last minute rushes to meet dead-lines, meetings which are either double booked or achieve nothing, days which seem somehow to slip unproductively by, crises which loom unexpected from nowhere. This sort of environment leads to inordinate stress and degradation of performance: it must be stopped.

Poor time management is often a symptom of over confidence: techniques which used to work with small projects and workloads are simply reused with large ones. But inefficiencies which were insignificant in the small role are ludicrous in the large. You can not drive a motor bike like a bicycle, nor can you manage a supermarket-chain like a market stall. The demands, the problems and the payoffs for increased efficiency are all larger as your responsibility grows; you must learn to apply proper techniques or be bettered by those who do. Possibly, the reason Time Management is poorly practised is that it so seldom forms a measured part of appraisal and performance review; what many fail to foresee, however, is how intimately it is connected to aspects which do.

Personal Time Management has many facets. Most managers recognize a few, but few recognize them all. There is the simple concept of keeping a well ordered diary and the related idea of planned activity. But beyond these, it is a tool for the systematic ordering of your influence on events, it underpins many other managerial skills such as Effective Delegation and Project Planning.

Personal Time Management is a set of tools which allow you to:

eliminate wastage

be prepared for meetings

refuse excessive workloads

monitor project progress

allocate resource (time) appropriate to a task's importance

ensure that long term projects are not neglected

plan each day efficiently

plan each week effectively

and to do so simply with a little self-discipline.

Since Personal Time Management is a management process just like any other, it must be planned, monitored and regularly reviewed. In the following sections, we will examine the basic methods and functions of Personal Time Management. Since true understanding depends upons experience, you will be asked to take part by looking at aspects of your own work. If you do not have time to this right now - ask yourself: why not?

Current Practice

What this article is advocating is the adoption of certain practices which will give you greater control over the use and allocation of your primary resource: time. Before we start on the future, it is worth considering the present. This involves the simplistic task of keeping a note of how you spend your time for a suitably long period of time (say a week). I say simplistic since all you have to do is create a simple table, photocopy half-a-dozen copies and carry it around with you filling in a row every time you change activity. After one week, allocate time (start as you mean to go on) to reviewing this log.

Waste Disposal

We are not looking here to create new categories of work to enhance efficiency (that comes later) but simply to eliminate wastage in your current practice. The average IEE Chartered Engineer earns about 27,000 pounds per annum: about 12.50 pounds per hour, say 1 pound every 5 minutes; for how many 5 minute sections of your activity would you have paid a pound? The first step is a critical appraisal of how you spend your time and to question some of your habits. In your time log, identify periods of time which might have been better used.

There are various sources of waste. The most common are social: telephone calls, friends dropping by, conversations around the coffee machine. It would be foolish to eliminate all non-work related activity (we all need a break) but if it's a choice between chatting to Harry in the afternoon and meeting the next pay-related deadline ... Your time log will show you if this is a problem and you might like to do something about it before your boss does.

In your time log, look at each work activity and decide objectively how much time each was worth to you, and compare that with the time you actually spent on it. An afternoon spent polishing an internal memo into a Pulitzer prize winning piece of provocative prose is waste; an hour spent debating the leaving present of a colleague is waste; a minute spent sorting out the paper-clips is waste (unless relaxation). This type of activity will be reduced naturally by managing your own time since you will not allocate time to the trivial. Specifically, if you have a task to do, decide before hand how long it should take and work to that deadline - then move on to the next task.

Another common source of waste stems from delaying work which is unpleasant by finding distractions which are less important or unproductive. Check your log to see if any tasks are being delayed simply because they are dull or difficult.

Time is often wasted in changing between activities. For this reason it is useful to group similar tasks together thus avoiding the start-up delay of each. The time log will show you where these savings can be made. You may want then to initiate a routine which deals with these on a fixed but regular basis.

Doing Subordinate's Work

Having considered what is complete waste, we now turn to what is merely inappropriate. Often it is simpler to do the job yourself. Using the stamp machine to frank your own letters ensures they leave by the next post; writing the missing summary in the latest progress report from your junior is more pleasant than sending it back (and it lets you choose the emphasis). Rubbish!

Large gains can be made by assigning secretarial duties to secretaries: they regularly catch the next post, they type a lot faster than you. Your subordinate should be told about the missing section and told how (and why) to slant it. If you have a task which could be done by a subordinate, use the next occasion to start training him/her to do it instead of doing it yourself - you will need to spend some time monitoring the task thereafter, but far less that in doing it yourself.

Doing the work of Others

A major impact upon your work can be the tendency to help others with their's. Now, in the spirit of an open and harmonious work environment it is obviously desirable that you should be willing to help out - but check your work log and decide how much time you spend on your own work and how much you spend on others'. For instance, if you spend a morning checking the grammar and spelling in the training material related to you last project, then that is waste. Publications should do the proof-reading, that is their job, they are better at it than you; you should deal at the technical level.

The remaining problem is your manager. Consider what periods in your work log were used to perform tasks that your manager either repeated or simply negated by ignoring it or redefining the task, too late. Making your manager efficient is a very difficult task, but where it impinges upon your work and performance you must take the bull by the horns (or whatever) and confront the issue.

Managing your manager may seem a long way from Time Management but no one impacts upon your use of time more than your immediate superior. If a task is ill defined - seek clarification (is that a one page summary or a ten page report?). If seemingly random alterations are asked in your deliverables, ask for the reasons and next time clarify these and similar points at the beginning. If the manager is difficult, try writing a small specification for each task before beginning it and have it agreed. While you can not tactfully hold your manager to this contract if he/she has a change of mind, it will at least cause him/her to consider the issues early on, before you waste your time on false assumptions.

External Appointments

The next stage of Personal Time Management is to start taking control of your time. The first problem is appointments. Start with a simple appointments diary. In this book you will have (or at least should have) a complete list of all your known appointments for the forseeable future. If you have omitted your regular ones (since you remember them anyway) add them now.

Your appointments constitute your interaction with other people; they are the agreed interface between your activities and those of others; they are determined by external obligation. They often fill the diary. Now, be ruthless and eliminate the unnecessary. There may be committees where you can not productively contribute or where a subordinate might be (better) able to participate. There may be long lunches which could be better run as short conference calls. There may be interviews which last three times as long as necessary because they are scheduled for a whole hour. Eliminate the wastage starting today.

The next stage is to add to your diary lists of other, personal activity which will enhance your use of the available time. Consider: what is the most important type of activity to add to your diary? No:- stop reading for a moment and really, consider.

The single most important type of activity is those which will save you time: allocate time to save time, a stitch in time saves days. And most importantly of all, always allocate time to time management: at least five minutes each and every day.

For each appointment left in the diary, consider what actions you might take to ensure that no time is wasted: plan to avoid work by being prepared. Thus, if you are going to a meeting where you will be asked to comment on some report, allocate time to read it so avoiding delays in the meeting and increasing your chances of making the right decision the first time. Consider what actions need to be done before AND what actions must be done to follow-up. Even if the latter is unclear before the event, you must still allocate time to review the outcome and to plan the resulting action. Simply mark in your diary the block of time necessary to do this and, when the time comes, do it.

Scheduling Projects

The most daunting external appointments are deadlines: often, the handover of deliverables. Do you leave the work too late? Is there commonly a final panic towards the end? Are the last few hectic hours often marred by errors? If so, use Personal Time Management.

The basic idea is that your management of personal deadlines should be achieved with exactly the same techniques you would use in a large project:

check the specification - are you sure that you agree on what is to be delivered

break the task down into small sections so that you can estimate the time needed for each, and monitor progress

schedule reviews of your progress (e.g. after each sub-task) so that you can respond quickly to difficulties

Like most management ideas, this is common sense. Some people, however, refute it because in practise they find that it merely shows the lack of time for a project which must be done anyway. This is simply daft! If simple project planning and time management show that the task can not be done, then it will not be done - but by knowing at the start, you have a chance to do something about it.

An impossible deadline affects not only your success but also that of others. Suppose a product is scheduled for release too soon because you agree to deliver too early. Marketing and Sales will prepare customers to expect the product showing why they really need it - but it will not arrive. The customers will be dissatisfied or even lost, the competition will have advanced warning, and all because you agreed to do the impossible.

You can avoid this type of problem. By practising time management, you will always have a clear understanding of how you spend your time and what time is unallocated. If a new task is thrust upon you, you can estimate whether it is practical. The project planning tells you how much time is needed and the time management tells you how much time is available.

There are four ways to deal with impossible deadlines:

Get the deadline extended

Scream for more resources

Get the Deliverable redefined to something practical

State the position clearly so that your boss (and his/her boss) have fair warning

If this simple approach seems unrealistic, consider the alternative. If you have an imposed, but unobtainable, deadline and you accept it; then the outcome is your assured failure. Of course, there is a fifth option: move to a company with realistic schedules.

One defence tactic is to present your superior with a current list of your obligations indicating what impact the new task will have on these, and ask him/her to assign the priorities: "I can't do them all, which should I slip?". Another tactic is to keep a data base of your time estimates and the actual time taken by each task. This will quickly develop into a source of valuable data and increase the accuracy of your planning predictions.

There is no reason why you should respond only to externally imposed deadlines. The slightly shoddy product which you hand-over after the last minute rush (and normally have returned for correction the following week) could easily have been polished if only an extra day had been available - so move your personal deadline forward and allow yourself the luxury of leisured review before the product is shipped.

Taking this a step further, the same sort of review might be applied to the product at each stage of its development so that errors and rework time are reduced. Thus by allocating time to quality review, you save time in rework; and this is all part of project planning supported and monitored by your time management.

Finally, for each activity you should estimate how much time it is worth and allocate only that amount. This critical appraisal may even suggest a different approach or method so that the time matches the task's importance. Beware of perfection, it takes too long - allocate time for "fitness for purpose", then stop.

Monitoring Staff

Your Personal Time Management also effects other people, particularly your subordinates. Planning projects means not only allocating your time but also the distribution of tasks; and this should be done in the same planned, monitored and reviewed manner as your own scheduling.

Any delegated task should be specified with an (agreed) end date. As a Manager, you are responsible for ensuring that the tasks allocated to your subordinates are completed successfully. Thus you should ensure that each task is concluded with a deliverable (for instance, a memo to confirm completion) - you make an entry in your diary to check that this has arrived. Thus, if you agree the task for Tuesday, Wednesday should have an entry in your diary to check the deliverable. This simple device allows you to monitor progress and to initiate action as necessary.

Long term Objectives

There are many long term objectives which the good Manager must achieve, particularly with regard to the development, support and motivation of his/her work-team. Long term objectives have the problem of being important but not urgent; they do not have deadlines, they are distant and remote. For this reason, it is all too easy to ignore them in favour of the urgent and immediate. Clearly a balance must be struck.

The beauty of Time Management is that the balance can be decided objectively (without influence from immediate deadlines) and self-imposed through the use of the diary. Simply, a manager might decide that one hour a week should be devoted to personnel issues and would then allocate a regular block of time to that activity. Of course if the factory is on fire, or World War III is declared, the manager may have to re-allocate this time in a particular week - but barring such crises, this time should then become sacrosanct and always applied to the same, designated purpose.

Similarly, time may be allocated to staff development and training. So if one afternoon a month is deemed to be a suitable allocation, then simply designate the second Thursday (say) of each month and delegate the choice of speakers. The actual time spent in managing this sort of long term objective is small, but without that deliberate planning it will not be achieved.

Once you have implemented Personal Time Management, it is worth using some of that control to augment your own career. Some quiet weekend, you should sketch out your own long term objectives and plan a route to them. As you would any long term objective, allocate time to the necessary sub-tasks and monitor your progress. If you do not plan where you want to go, you are unlikely to get there.

Concluding Remarks.

Personal Time Management is a systematic application of common sense strategies. It requires little effort, yet it promotes efficient work practices by highlighting wastage and it leads to effective use of time by focusing it on your chosen activities. Personal Time Management does not solve your problems; it reveals them, and provides a structure to implement and monitor solutions. It enables you to take control of your own time - how you use it is then up to you.

Project Groups that Work

2011-01-23T13:17:00.000-08:00

by Gerard M Blair

Groups form a basic unit of work activity throughout engineering and yet the underlying process is poorly managed. This article looks at the basics of group work and suggests ways to accelerate development.

In the beginning, God made an individual - and then he made a pair. The pair formed a group, together they begat others and thus the group grew. Unfortunately, working in a group led to friction, the group disintegrated in conflict and Caian settled in the land of Nod - there has been trouble with groups ever since.

When people work in groups, there are two quite separate issues involved. The first is the task and the problems involved in getting the job done. Frequently this is the only issue which the group considers. The second is the process of the group work itself: the mechanisms by which the group acts as a unit and not as a loose rabble. However, without due attention to this process the value of the group can be diminished or even destroyed; yet with a little explicit management of the process, it can enhance the worth of the group to be many times the sum of the worth of its individuals. It is this synergy which makes group work attractive in corporate organization despite the possible problems (and time spent) in group formation.

This article examines the group process and how it can best be utilized. The key is that the group should be viewed as an important resource whose maintenance must be managed just like any other resource and that this management should be undertaken by the group itself so that it forms a normal part of the group's activities.

What is a Group?

A group of people working in the same room, or even on a common project, does not necessarily invoke the group process. If the group is managed in a totally autocratic manner, there may be little opportunity for interaction relating to the work; if there is factioning within the group, the process may never evolve. On the other hand, the group process may be utilized by normally distant individuals working on different projects; for instance, at IEE colloquia.

In simple terms, the group process leads to a spirit of cooperation, coordination and commonly understood procedures and mores. If this is present within a group of people, then their performance will be enhanced by their mutual support (both practical and moral). If you think this is a nebulous concept when applied to the world of industry, consider the opposite effect that a self-opinionated, cantankerous loud-mouth would have on your performance and then contrast that to working with a friendly, open, helpful associate.

Why a Group?

Groups are particularly good at combining talents and providing innovative solutions to possible unfamiliar problems; in cases where there is no well established approach/procedure, the wider skill and knowledge set of the group has a distinct advantage over that of the individual.

In general, however, there is an overriding advantage in a group-based work force which makes it attractive to Management: that it engenders a fuller utilization of the work force.

A group can be seen as a self managing unit. The range of skills provided by its members and the self monitoring which each group performs makes it a reasonably safe recipient for delegated responsibility. Even if a problem could be decided by a single person, there are two main benefits in involving the people who will carry out the decision. Firstly, the motivational aspect of participating in the decision will clearly enhance its implementation. Secondly, there may well be factors which the implementer understands better than the single person who could supposedly have decided alone.

More indirectly, if the lowest echelons of the workforce each become trained, through participation in group decision making, in an understanding of the companies objectives and work practices, then each will be better able to solve work-related problems in general. Further, they will also individually become a safe recipient for delegated authority which is exemplified in the celebrated right of Japanese car workers to halt the production line.

From the individual's point of view, there is the added incentive that through belonging to a group each can participate in achievements well beyond his/her own individual potential. Less idealistically, the group provides an environment where the individual's self-perceived level of responsibility and authority is enhanced, in an environment where accountability is shared: thus providing a perfect motivator through enhanced self-esteem coupled with low stress.

Finally, a word about the much vaunted "recognition of the worth of the individual" which is often given as the reason for delegating responsibility to groups of subordinates. While I agree with the sentiment, I am dubious that this is a prime motivator - the bottom line is that the individual's talents are better utilized in a group, not that they are wonderful human beings.

Group Development

It is common to view the development of a group as having four stages:

Forming
Storming
Norming
Performing

Forming is the stage when the group first comes together. Everybody is very polite and very dull. Conflict is seldom voiced directly, mainly personal and definitely destructive. Since the grouping is new, the individuals will be guarded in their own opinions and generally reserved. This is particularly so in terms of the more nervous and/or subordinate members who may never recover. The group tends to defer to a large extent to those who emerge as leaders (poor fools!).

Storming is the next stage, when all Hell breaks loose and the leaders are lynched. Factions form, personalities clash, no-one concedes a single point without first fighting tooth and nail. Most importantly, very little communication occurs since no one is listening and some are still unwilling to talk openly. True, this battle ground may seem a little extreme for the groups to which you belong - but if you look beneath the veil of civility at the seething sarcasm, invective and innuendo, perhaps the picture come more into focus.

Then comes the Norming. At this stage the sub-groups begin to recognize the merits of working together and the in-fighting subsides. Since a new spirit of co-operation is evident, every member begins to feel secure in expressing their own view points and these are discussed openly with the whole group. The most significant improvement is that people start to listen to each other. Work methods become established and recognized by the group as a whole.

And finally: Performing. This is the culmination, when the group has settled on a system which allows free and frank exchange of views and a high degree of support by the group for each other and its own decisions.

In terms of performance, the group starts at a level slightly below the sum of the individuals' levels and then drops abruptly to its nadir until it climbs during Norming to a new level of Performing which is (hopefully) well above the start. It is this elevated level of performance which is the main justification for using the group process rather than a simple group of staff.

Group Skills

The group process is a series of changes which occur as a group of individuals form into a cohesive and effective operating unit. If the process is understood, it can be accelerated.

There are two main sets of skills which a group must acquire:

Managerial Skills
Interpersonal Skills

and the acceleration of the group process is simply the accelerated acquisition of these.

As a self-managing unit, a group has to undertake most of the functions of a Group Leader - collectively. For instance, meetings must be organized, budgets decided, strategic planning undertaken, goals set, performance monitored, reviews scheduled, etc. It is increasingly recognized that it is a fallacy to expect an individual to suddenly assume managerial responsibility without assistance; in the group it is even more so. Even if there are practiced managers in the group, they must first agree on a method, and then convince and train the remainder of the group.

As a collection of people, a group needs to relearn some basic manners and people-management skills. Again, think of that self-opinionated, cantankerous loud-mouth; he/she should learn good manners, and the group must learn to enforce these manners without destructive confrontation.

Accelerating Development

It is common practice in accelerating group development to appoint, and if necessary train, a "group facilitator". The role of this person is to continually draw the groups' attention to the group process and to suggest structures and practices to support and enhance the group skills. This must be only a short-term training strategy, however, since the existence of a single facilitator may prevent the group from assuming collective responsibility for the group process. The aim of any group should be that facilitation is performed by every member equally and constantly. If this responsibility is recognised and undertaken from the beginning by all, then the Storming phase may be avoided and the group development passed straight into Norming.

The following is a set of suggestions which may help in group formation. They are offered as suggestions, no more; a group will work towards its own practices and norms.

Focus

The two basic foci should be the group and the task.

If something is to be decided, it is the group that decides it. If there is a problem, the group solves it. If a member is performing badly, it is the group who asks for change.

If individual conflicts arise, review them in terms of the task. If there is initially a lack of structure and purpose in the deliberations, impose both in terms of the task. If there are disputes between alternative courses of action, negotiate in terms of the task.

Clarification

In any project management, the clarity of the specification is of paramount importance - in group work it is exponentially so. Suppose that there is a 0.8 chance of an individual understanding the task correctly (which is very high). If there are 8 members in the group then the chance of the group all working towards that same task is 0.17. And the same reasoning hold for every decision and action taken throughout the life of the group.

It is the first responsibility of the group to clarify its own task, and to record this understanding so that it can be constantly seen. This mission statement may be revised or replaced, but it should always act as a focus for the groups deliberations and actions.

The mouse

In any group, there is always the quiet one in the corner who doesn't say much. That individual is the most under utilized resource in the whole group, and so represents the best return for minimal effort by the group as a whole. It is the responsibility of that individual to speak out and to contribute. It is the responsibility of the group to encourage and develop that person, to include him/her in the discussion and actions, and to provide positive reinforcement each time that happens.

The loud-mouth

In any group, there is always a dominant member whose opinions form a disproportionate share of the discussion. It is the responsibility of each individual to consider whether they are that person. It is the responsibility of the group to ask whether the loud-mouth might like to summarize briefly, and then ask for other views.

The written record

Often a decision which is not recorded will become clouded and have to be rediscused. This can be avoided simply by recording on a large display (where the group can clearly see) each decision as it is made. This has the further advantage that each decision must be expressed in a clear and concise form which ensures that it is clarified.

Feedback (negative)

All criticism must be neutral: focused on the task and not the personality. So rather than calling Johnie an innumerate moron, point out the error and offer him a calculator. It is wise to adopt the policy of giving feedback frequently, especially for small things - this can be couched as mutual coaching, and it reduces the destructive impact of criticism when things go badly wrong.

Every criticism must be accompanied by a positive suggestion for improvement.

Feedback (positive)

If anyone does something well, praise it. Not only does this reenforce commendable actions, but it also mollifies the negative feedback which may come later. Progress in the task should be emphasised.

Handling failure

The long term success of a group depends upon how it deals with failure. It is a very British tendency to brush off failure and to get on with the next stage with no more than a mention - it is a very foolish tendency. Any failure should be explored by the group. This is not to attribute blame (for that is shared by the whole group as an individual only acts with delegated responsibility), but rather to examine the causes and to devise a mechanism which either monitors against or prevents repetition. A mistake should only happen once if it is treated correctly.

One practise which is particularly useful is to delegate the agreed solution to the individual or sub-group who made the original error. This allows the group to demonstrate its continuing trust and the penitent to make amends.

Handling deadlock

If two opposing points of view are held in the group then some action must be taken. Several possibly strategies exist. Each sub-group could debate from the other sub-group's view-point in order to better understand it. Common ground could be emphasised, and the differences viewed for a possible middle or alternative strategy. Each could be debated in the light of the original task. But firstly the group should decide how much time the debate actually merits and then guillotine it after that time - then, if the issue is not critical, toss a coin.

Sign posting

As each small point is discussed, the larger picture can be obscured. Thus it is useful frequently to remind the group: this is where we came from, this is where we got to, this is where we should be going.

Avoid single solutions

First ideas are not always best. For any given problem, the group should generate alternatives, evaluate these in terms of the task, pick one and implement it. But most importantly, they must also monitor the outcome, schedule a review and be prepared to change the plan.

Active communication

Communication is the responsibility of both the speaker and the listener. The speaker must actively seek to express the ideas in a clear and concise manner - the listener must actively seek to understand what has been said and to ask for clarification if unsure. Finally, both parties must be sure that the ideas have been correctly communicated perhaps by the listener summarizing what was said in a different way.

Conclusion

Groups are like relationships - you have to work at them. In the work place, they constitute an important unit of activity but one whose support needs are only recently becoming understood. By making the group itself responsible for its own support, the responsibility becomes an accelerator for the group process. What is vital, is that these needs are recognized and explicitly dealt with by the group. Time and resources must be allocated to this by the group and by Management, and the group process must be planned, monitored and reviewed just like any other managed process.

Presentation Skills Tutorial for Project Managers

2011-01-22T06:46:00.000-08:00

by Gerard M Blair

Introduction

Management is the art of getting things done. A Presentation is a fast and potentially effective method of getting things done through other people. In managing any project, presentations are used as a formal method for bringing people together to plan, monitor and review its progress.

But let us look at this another way: what can a presentation do for you?

Firstly; it puts you on display. Your staff need to see evidence of decisive planning and leadership so that they are confident in your position as their manager. They need to be motivated and inspired to undertaking the tasks which you are presenting. Project leaders from other sections need to be persuaded of the merits of your project and to provide any necessary support. Senior management should be impressed by your skill and ability so that they provide the resources so that you and your team can get the job done.

Secondly; it allows you to ask questions and to initiate discussion. It may not be suitable within the presentation formats of your company to hold a discussion during the presentation itself but it does allow you to raise the issues, present the problems and at least to establish who amongst the audience could provide valuable input to your decision making.

Finally; presentations can be fun. They are your chance to speak your mind, to strut your stuff and to tell the people what the world is really like. While you hold the stage, the audience is bound by good manners to sit still and watch the performance.

The Objectives of Communication

The single most important observation is that the objective of communication is not the transimission but the reception. The whole preparation, presentation and content of a speech must therefore be geared not to the speaker but to the audience. The presentation of a perfect project plan is a failure if the audience do not understand or are not persuaded of its merits. A customers' tour is a waste of time if they leave without realising the full worth of your product. The objective of communication is to make your message understood and remembered.

The main problem with this objective is, of course, the people to whom you are talking. The average human being has a very short attention span and a million other things to think about. Your job in the presentation is to reach through this mental fog and to hold the attention long enough to make your point.

The Plan

It is difficult to over estimate the importance of careful preparation. Five minutes on the floor in front of senior management could decide the acceptance of a proposal of several months duration for the manager and the whole team. With so much potentially at stake, the presenter must concentrate not only upon the facts being presented but upon the style, pace, tone and ultimately tactics which should be used. As a rule of thumb for an average presentation, no less than 1 hour should be spent in preparation for 5 minutes of talking.

Suppose you have a talk to give, where do you start?

Formulate your Objectives

The starting point in planning any speech is to formulate a precise objective. This should take the form of a simple, concise statement of intent. For example, the purpose of your speech may be to obtain funds, to evaluate a proposal, or to motivate your team. No two objectives will be served equally well by the same presentation; and if you are not sure at the onset what you are trying to do, it is unlikely that your plan will achieve it.

One question is: how many different objectives can you achieve, in say, 30 minutes - and the answer: not many. In the end it is far more productive to achieve one goal than to blunder over several. The best approach is to isolate the essential objective and to list at most two others which can be addressed providing they do not distract from the main one. Focus is key. If you do not focus upon your objective, it is unlikely that the audience will.

Identify the Audience

The next task is to consider the audience to determine how best to achieve your objectives in the context of these people. Essentially this is done by identifying their aims and objectives while attending your presentation. If you can somehow convince them they are achieving those aims while at the same time achieving your own, you will find a helpful and receptive audience. For instance, if you are seeking approval for a new product plan from senior management it is useful to know and understand their main objectives. If they are currently worried that their product range is out of date and old fashioned, you would emphasise the innovative aspects of your new product; if they are fearful about product diversification you would then emphasise how well your new product fits within the existing catalogue.

This principal of matching the audience aims, however, goes beyond the simple salesmanship of an idea - it is the simplest and most effective manner of obtaining their attention at the beginning. If your opening remarks imply that you understand their problem and that you have a solution, then they will be flattered at your attention and attentive to your every word.

Structure

All speeches should have a definite structure or format; a talk without a structure is a woolly mess. If you do not order your thoughts into a structured manner, the audience will not be able to follow them. Having established the aim of your presentation you should choose the most appropriate structure to achieve it.

However, the structure must not get in the way of the main message. If it is too complex, too convoluted or simply too noticeable the audience will be distracted. If a section is unnecessary to the achievement of your fundamental objectives, pluck it out.

Sequential Argument

One of the simplest structures is that of sequential argument which consists of a series of linked statements ultimately leading to a conclusion. However, this simplicity can only be achieved by careful and deliberate delineation between each section. One technique is the use of frequent reminders to the audience of the main point which have proceeded and explicit explanation of how the next topic will lead on from this.

Hierarchical Decomposition

In hierarchical decomposition the main topic is broken down into sub-topics and each sub-topics into smaller topics until eventually everything is broken down into very small basic units. In written communication this is a very powerful technique because it allows the reader to re-order the presentation at will, and to return to omitted topics at a later date. In verbal communication the audience is restricted to the order of the presenter and the hierarchy should be kept simple reinforced. As with sequential argument it is useful to summarise each section at its conclusion and to introduce each major new section with a statement of how it lies in the hierarchical order.

Question Orientated

The aim of many presentations given by managers is to either explain a previous decision or to seek approval for a plan of action. In these cases, the format can be question orientated. The format is to introduce the problem and any relevant background, and then to outline the various solutions to that problem listing the advantages and disadvantages of each solution in turn. Finally, all possible options are summarised in terms of their pro's and con's, and either the preferred solution is presented for endorsement by the audience or a discussion is initiated leading to the decision. One trick for obtaining the desired outcome is to establish during the presentation the criteria by which the various options are to be judged; this alone should allow you to obtain your desired outcome.

Pyramid

In a newspaper, the story is introduced in its entirety in a catchy first paragraph. The next few paragraphs repeat the same information only giving further details to each point. The next section repeats the entire story again, but developing certain themes within each of the sub-points and again adding more information. This is repeated until the reporter runs out of story. The editor then simply decides upon the newsworthiness of the report and cuts from the bottom to the appropriate number of column inches.

There are two main advantages to this style for presentations. Firstly, it can increase the audiences receptiveness to the main ideas. Since at every stage of the pyramid they have all ready become familiar with the ideas and indeed know what to expect next. This sense of deja vu can falsely give the impression that what they are hearing are their own ideas. The second advantage is that the duration of the talk can be easily altered by cutting the talk in exactly the same way as the newspaper editor might have done to the news story. This degree of flexibility may be useful if the same presentation is to be used several times in different situations.

The Meaty Sandwich

The simplest and most direct format remains the meaty sandwich. This is the simple beginning-middle-end format in which the main meat of the exposition is contained in the middle and is proceeded by an introduction and followed by a summary and conclusion. This is really the appropriate format for all small sub-sections in all the previous structures. If the talk is short enough, or the topic simple enough, it can indeed form the entirity of the presentation.

The Beginning

It is imperative to plan your beginning carefully; there are five main elements:

Get their attention

Too often in a speech, the first few minutes of the presentation are lost while people adjust their coats, drift in with coffee and finish the conversation they were having with the person next to them. You only have a limited time and every minute is precious to you so, from the beginning, make sure they pay attention.

Establish a theme

Basically, you need to start the audience thinking about the subject matter of your presentation. This can be done by a statement of your main objective, unless for some reason you wish to keep it hidden. They will each have some experience or opinions on this and at the beginning you must make them bring that experience into their own minds.

Present a structure

If you explain briefly at the beginning of a talk how it is to proceed, then the audience will know what to expect. This can help to establish the theme and also provide something concrete to hold their attention. Ultimately, it provides a sense of security in the promise that this speech too will end.

Create a rapport

If you can win the audience over in the first minute, you will keep them for the remainder. You should plan exactly how you wish to appear to them and use the beginning to establish that relationship. You may be presenting yourself as their friend, as an expert, perhaps even as a judge, but whatever role you choose you must establish it at the very beginning.

Administration

When planning your speech you should make a note to find out if there are any administrative details which need to be announced at the beginning of your speech. This is not simply to make yourself popular with the people organising the session but also because if these details are over looked the audience may become distracted as they wonder what is going to happen next.

The Ending

The final impression you make on the audience is the one they will remember. Thus it is worth planning your last few sentences with extreme care.

As with the beginning, it is necessary first to get their attention, which will have wandered. This requires a change of pace, a new visual aid or perhaps the introduction of one final culminating idea. In some formats the ending will be a summary of the main points of the talk. One of the greatest mistakes is to tell the audience that this is going to be a summary because at that moment they simply switch off. Indeed it is best that the ending comes unexpectedly with that final vital phrase left hanging in the air and ringing round their memories. Alternatively the ending can be a flourish, with the pace and voice leading the audience through the final crescendo to the inevitable conclusion.

Visual Aids

Most people expect visual reinforcement for any verbal message being delivered. While it would be unfair to blame television entirely for this, it is useful to understand what the audience is accustomed to, for two reasons: firstly, you can meet their expectations using the overhead projector, a slide show, or even a video presentation; secondly, if you depart from the framework of a square picture flashed before their eyes, and use a different format, then that novelty will be most arresting. For instance, if you are describing the four functions of a project manager then display the four "hats" he/she must wear; if you are introducing the techniques of brainstorming then brandish a fishing rod to "fish for" ideas.

With traditional visual aids however, there are a few rules which should be followed to ensure they are used effectively. Most are common sense, and most are commonly ignored. As with all elements of a speech, each different viewfoil should have a distinct purpose - and if it has no purpose it should be removed. With that purpose firmly in mind you should design the viewfoil for that purpose. Some viewfoils are there to reinforce the verbal message and so to assist in recall; others are used to explain information which can be more easily displayed than discussed: and some viewfoils are designed simply for entertainment and thus to pace the presentation.

If your viewfoil is scruffy then your audience will notice that, and not what is written upon it. Do not clutter a viewfoil or it will confuse rather than assist. Do not simply photocopy information if there is more data on the page than you wish to present; in these cases, the data should be extracted before being displayed. Make sure that your writing can be read from the back of the room. Talk to the audience, not the visual aid.

The Delivery

"The human body is truly fascinating - there are some I could watch all day" - Anon

Whatever you say and whatever you show; it is you, yourself which will remain the focus of the audience's attention. If you but strut and fret your hour upon the stage and then are gone, no-one will remember what you said. The presenter has the power both to kill the message and to enhance it a hundred times beyond its worth. Your job as a manager is to use the potential of the presentation to ensure that the audience is motivated and inspired rather than disconcerted or distracted. There are five key facets of the human body which deserve attention in presentation skills: the eyes, the voice, the expression, the appearance, and how you stand.

The Eyes

The eyes are said to be the key to the soul and are therefore the first and most effective weapon in convincing the audience of your honesty, openness and confidence in the objectives of your presentation. This impression may of course be totally false, but here is how to convey it.

Even when in casual conversation, your feelings of friendship and intimacy can be evaluated by the intensity and duration of eye contact. During the presentation you should use this to enhance your rapport with the audience by establishing eye contact with each and every member of the audience as often as possible. For small groups this is clearly possible but it can also be achieved in large auditoriums since the further the audience is away from the presenter the harder it is to tell precisely where he or she is looking. Thus by simply staring at a group of people at the back of a lecture theatre it is possible to convince each of them individually that he or she is the object of your attention. During presentations, try to hold your gaze fixed in specific directions for five or six seconds at a time. Shortly after each change in position, a slight smile will convince each person in that direction that you have seen and acknowledged them.

The Voice

After the eyes comes the voice, and the two most important aspects of the voice for the public speaker are projection and variation. It is important to realise from the onset that few people can take their ordinary conversation voice and put it on stage. If you can, then perhaps you should move to Hollywood. The main difference comes in the degree of feedback which you can expect from the person to whom you are talking. In ordinary conversation you can see from the expression, perhaps a subtle movement of the eye, when a word or phrase has been missed or misunderstood. In front of an audience you have to make sure that this never happens. The simple advice is to slow down and to take your time. Remember the audience is constrained by good manners not to interrupt you so there is no need to maintain a constant flow of sound. A safe style is to be slightly louder and slightly slower than a fire-side chat with slightly deaf aunt. As you get used to the sound, you can adjust it by watching the audience.

A monotone speech is both boring and soporific, so it is important to try to vary the pitch and speed of your presentation. At the very least, each new sub-section should be proceeded by a pause and a change in tone to emphasise the delineation. If tonal variation does not come to you naturally try making use of rhetorical questions throughout your speech, since most British accents rise naturally at the end of a question.

Expression

The audience watch your face. If you are looking listless or distracted then they will be listless and distracted; if you are smiling, they will be wondering why and listen to find out. In normal conversation your meaning is enhanced by facial reinforcement. Thus in a speech you must compensate both for stage nerves and for the distance between yourself and the audience. The message is quite simply: make sure that your facial expressions are natural, only more so.

Appearance

There are many guides to management and presentation styles which lay heavy emphasis upon the way you dress and in the last analysis this is a matter of personal choice. That choice should however be deliberately made. When you are giving a presentation you must dress for the audience, not for yourself; if they think you look out of place, then you are.

As an aside, it is my personal opinion that there exists a code of conduct among engineers which emphasizes the scruffy look, and that in many organisations this tends to set the engineer apart, especially from management. It conveys the subliminal message that the engineer and the manager are not part of the same group and so hinders communication.

Stance

When an actor initially learns a new character part, he or she will instinctively adopt a distinct posture or stance to convey that character. It follows therefore that while you are on stage, your stance and posture will convey a great deal about you. The least you must do is make sure your stance does not convey boredom; at best, you can use your whole body as a dynamic tool to reinforce your rapport with the audience.

The perennial problem is what to do with your hands. These must not wave aimlessly through the air, or fiddle constantly with a pen, or (worst of all visually) juggle change in your trouser pockets. The key is to keep your hands still, except when used in unison with your speech. To train them initially, find a safe resting place which is comfortable for you, and aim to return them there when any gesture is completed.

The Techniques of Speech

Every speaker has a set of "tricks of the trade" which he or she holds dear - the following are a short selection of such advice taken from various sources.

Make an impression

The average audience is very busy: they have husbands and wives, schedules and slippages, cars and mortgages; and although they will be trying very hard to concentrate on your speech, their minds will inevitably stray. Your job is to do something, anything, which captures their attention and makes a lasting impression upon them. Once you have planned your speech and honed it down to its few salient points, isolate the most important and devise some method to make it stick.

Repeat, Repeat

The average audience is very busy: they have husbands or wives etc, etc - but repetition makes them hear. The average audience is easily distracted, and their attention will slip during the most important message of your speech - so repeat it. You don't necessarily have to use the resonant tonal sounds of the repeated phrase, but simply make the point again and again and again with different explanations and in different ways. The classic advice of the Sergeant Major is: "First you tell 'em what you are going to tell 'em, then you tell 'em, then you tell 'em what you told 'em!"

Draw a Sign

Research into teaching has yielded the following observation: "We found that students who failed to get the point did so because they were not looking for it". If the audience knows when to listen, they will. So tell them: the important point is ... .

Draw a Picture

The human brain is used to dealing with images, and this ability can be used to make the message more memorable. This means using metaphors or analogies to express your message. Thus a phrase like "we need to increase the market penetration before there will be sufficient profits for a pay related bonus" becomes "we need a bigger slice of the cake before the feast".

Jokes

The set piece joke can work very well, but it can also lead to disaster. You must choose a joke which is apt, and one which will not offend any member of the audience. This advice tends to rule out all racist, sexist or generally rude jokes. If this seems to rule out all the jokes you can think of, then you should avoid jokes in a speech.

Amusing asides are also useful in maintaining the attention of the audience, and for relieving the tension of the speech. If this comes naturally to you, then it is a useful tool for pacing your delivery to allow periods of relaxation in between your sign-posted major points.

Plain Speech

Yes!

Short and Sweet

One way to polish the presentation of the main point of your speech is to consider it thus. The day before your presentation, you are called to to the office of the divisional vice-president; there you are introduced to the managing director and a representative of the company's major share holder; "O.K." says the vice president "we hear you have got something to say, we'll give you 30 seconds, GO". Can you do it?

If you can crystallise your thoughts and combine your main message with some memorable phrase or imagery, and present them both in 30 seconds then you have either the perfect ending or the basis for a fine presentation.

The Narrative

Everyone loves a story and stories can both instruct and convey a message: Zen Philosophy is recorded in its stories, and Christianity was originally taught in parables. If you can weave your message into a story or a personal annocdote, then you can have them wanting to hear your every word - even if you have to make it up.

Rehearsal

There is no substitute for rehearsal. You can do it in front of a mirror, or to an empty theatre. In both cases, you should accentuate your gestures and vocal projection so that you get used to the sound and sight of yourself. Do not be put off by the mirror - remember: you see a lot less of yourself than your friends do.

Relaxation

If you get nervous just before the show, either concentrate on controlling your breathing or welcome the extra adrenaline. The good news is that the audience will never notice your nerves nearly as much as you think. Similarly, if you dry-up in the middle - smile, look at your notes, and take your time. The silence will seem long to you, but less so to the audience.

Conclusion

Once the speech is over and you have calmed down, you should try to honestly evaluate your performance. Either alone, or with the help of a friend in the audience, decide what was the least successful aspect of your presentation and resolve to concentrate on that point in the next talk you give. If it is a problem associated with the preparation, then deal with it there; if it is a problem with your delivery, write yourself a reminder note and put it in front of you at the next talk.

Practice is only productive when you make a positive effort to improve - try it.

How to handle with difficult team members

2010-11-30T12:17:00.001-08:00

Fire them immediately. No! I am kidding. Difficult team members/employees are not necessarily bad employees. Positively, by challenging the status quo they can be effective catalysts for change. Negatively, difficult employees can be disruptive to the smooth and efficient running of the organization. Most managers and supervisors encounter difficult employees sometime in their careers and they often call in HR professionals to help deal with the situations that arise or if it is not worth for, fire them.

But, first you must make sure that you check and explore all ideas in order to find the right place for them in organization. Here are some suggestions that may help managers and HR professionals to handle difficult employees effectively:

1. Understand the big picture – what is the track record of the employee? Is this an isolated occurrence or a pattern of behavior. Can the behavior in question be justified from the employee’s point of view—even if you might not agree with their point of view?
2. Gather the facts – there are always rumors and hearsay so it is important to fact check the reality of the situation. Try to find hard evidence of what occurred or what is occurring—facts are undeniable!
3. Create a plan – decide when and where you will speak to the employee and other involved people. Know what you will say to open the discussion. Prepare your key questions—use open ended questions that allow each person to state their perspective on what happened.
4. Focus on the problem not the person – don’t give the impression that you are attacking the people involved, that will only result in closing down the discussion. Instead, attack the problem by uncovering underlying issues and root causes through intensive questioning.
5. Be open to hearing all sides – when dealing with a difficult employee it is not only fair but necessary to hear all sides and perspectives to understand the underlying reasons for the difficult behavior. Play the role of a mediator and try to find the common ground and figure out where and how you can bring clarity to the situation.
6. Identify a solution – the goal is to come to an agreement with the employee on how to solve the issue. Without agreement from the employee on the solution it is questionable if their behavior with change. The agreement should result in a plan of action that the employee commits to . You should also agree upon how the plan will be implemented and monitored.

Train yourself and the managers and supervisors you work with to use the six steps to deal effectively with the difficult employees.

The most of the ideas for this article is taken from site hrtips.com

Planning & Estimation Techniques

2010-09-24T06:30:00.000-07:00

How do we estimate? What approach should follow? How accurate estimations will be? Who will estimate? Why we are making so unclear estimations.

The answer for more precise estimations is Scrum. Scrum Team has to make very serious commitment to complete the work (Potentially shippable Product) which requires careful thought to be successful. Steps for successful estimation would be:

Estimate Team's Time available for Scrum:

Estimating the time of each and every team member available for the sprint is very much important as a part of the sprint planning. When a team member estimates a given task can be completed within 8 hours which does not mean he can complete the task in one day. The fact is that no one will seat in one place to do complete the job without attending meetings, lunch breaks, unexpected breaks, checking emails and phone calls etc.

Those who just started practicing scrum will have question regarding "Managing time for bug fixes". Again we cannot make two sprints one for product backlog and one for bug fixes. The time for bug fixes should be addressed form the daily time available time. It means apart from daily routine work like emails, phones, breaks , you should also allocate some time for bug fixes and the remaining time you can commit for the sprint.

1. Estimate how much time each member can spend for sprint related work.

Available time for Sprint Related work = Average work day time - Time allocated for other activities.
Average work day time = e.g. 10 hours
Time Allocated for other activities: = e.g. 6 hours
Emails and Phone : 1 Hrs
Lunch : 1 Hrs
Reading Blogs : 1 Hrs
Meetings : 2 Hrs
Bug fixes : 1 hrs
Available time for Sprint Related work = 4 hours

Estimate Effort for Each Prioritized Item on the Product Backlog:

Estimates can be better done by the people who have the experience of similar kind of work already done, Peers and Historical data. It is always better to involve the people who have similar work experience for appropriate estimations.

No one will estimate perfectly for the first time, for sure team members will either over estimate or under estimate the task work, but it makes them realize how much they can produce and for next sprint the team members will try to estimate a bit more precisely.

After three to four sprints, team members will be in a position to understand their own strength and how much work they can do. This leads for better estimates.

2. All the team members must participate in the estimation game.

3. Take the prioritized Item from Product Back Log, Understand it thoroughly, what is supposed to be done, any dependencies, complexity, Risk involved, etc. ,. If required get the clarification from the product manager (Pre- Planning).

4. Divide the Prioritized/Understood Item and break it down to individual tasks.

5. Use Planning poker for estimating duration for individual tasks.

All the team members must have cards: ½,1,2,3,5,8,13,20,50 etc.
Scrum Master reads description of the backlog Item.
Everyone selects and simultaneously shows cards
If estimates vary significantly, high and low estimators briefly explain why they have estimated so.
Repeat steps 3-5 until estimates stop converging.
Decide estimate for backlog item
Move to next backlog item.

Points to be consider for estimations:

1. Once committed to the sprint work, Team members should not be disturbed by adding additional work or different work then assigned to the team members.

2. Remaining work should be carry forwarded to the next sprint (This happens generally due to underestimates) .

3. Teams must be self organized and have transparency among the team members for achieving the goal.

Follow Scrum Rules to Make your Product Development Successful:

1. Full-Time Product Owner (with Expertise and Authority) Identified
2. Product Owner Works With Team and All Other Stakeholders
3. Product Backlog Created and Managed by Product Owner
4. Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
5. Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
6. Regular Sprint Length (no more than 30 days)
7. Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
8. Sprint Burndown Chart
9. Team Room with All Needed Equipment and Supplies
10. Retrospective Meeting for Process Improvements
11. Definition of "Done"
12. Commitment Velocity Calculated (from Sprint Backlog Estimates)
13. Team Size 7 +/-2, Maximum of 12
14. Cross-Functional Team Including ScrumMaster and Product Owner
15. Team Self-Organization - Team Members Volunteer for Tasks
16. ScrumMaster Tracking and Removing Obstacles
17. Team Safety - No Interruptions to Team's Work During Sprints
18. No "Break" Between Sprints
19. Sustainable Pace - Timebox Effort, Not Just Schedule
20. Quality is Not Negotiable - Defects Go on Top of Product Backlog

And summary:

Team understands the details of what the Product Owner has prioritized on the product backlog in the Sprint Pre Planning Meeting:, Team decides how much productive time it has available during the sprint, Team decides how many Product Backlog items it can commit to complete during the Sprint. , And finally team delivers potentially shippable product at the end of every sprint.

Author: Madhusudhan Rao Giruka

Managing Project Teams and Importance of The Human Factor

2010-09-04T04:35:00.000-07:00

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 descriptions 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.

About author: Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh.

Stress Management and Stress Control

2010-08-27T05:49:00.000-07:00

Today’s world is a stressful place, with its many demands, crises, and sudden changes intruding into the lives of its inhabitants. Constantly bombarded with pressures and stresses, it is not surprising that most people absorb this negative energy into themselves, and begin to suffer the detrimental effects of becoming attuned to the modern world’s problems and especially on their daily jobs. Once the mind has been invaded by these negative influences, both inner peace and positive thinking become difficult to achieve. This is very difficult especially when you job is directly connected with managing a group or groups of people. As leader, you could transfer the negative thoughts and energy to them and that could impact the project plan and current tasks duration. Fortunately, a cure for this negative influence can be found in mind meditation – a cleansing spiritual exercise that allows even those immersed in the most hectic lives to use this stress management technique.

Meditation is an ancient art – indeed, the vast array of cultures and peoples who have practiced it is a testimonial to its timeless effectiveness. Meditation has been used by a staggering range of cultures and creeds to cleanse the spirit of negative energy, restore the mind’s positive balance, and achieve inner harmony.
You can use meditation in your own life to improve both your outlook and your quality of living. Without the safety valve of meditation, stresses begin to wear ruts in the mind, and can lead to constant unhappiness, a loss of mental focus, and even self-harming behavior such as alcoholism or drug abuse. Stress, clearly, can transform your life in a highly negative way. You owe it to yourself to make use of meditation to handle your stress, suppress it, and make room in your mind for positive energy to flourish.

Open and closed meditations are the two main forms of meditation. They will be described here, but if you are unable to choose one merely from description, it is best to try both and discover which technique is most in tune with your unique spiritual needs. Each human mind is individual and special, and some may even find the most relief from combining the two forms.

Open meditation makes use of a focus, such as a mantra, an idea, a visualization, or even a regular action such as breathing or a repetitive physical movement such as walking. The person who is meditating allows their mind to move freely through whatever ideas and images occur to it, but regularly returns their attention to the focus or mantra. In this way, the mind is allowed to move freely from idea to idea in an almost dream-like way, but does not begin to analyze. Thus, the mind remains calm and detached, allowing it time to refresh itself, melting away the negative energy of stress through relaxation.

Closed meditation drives out all external thoughts and ideas in favor of focusing steadily on the focus or mantra itself, or even on simply maintaining a complete blankness of mind. Closed meditation thus clears the psyche of tension either by keeping the mind concentrated exclusively on one focus, so that no room is left for stress, or by removing concentration entirely by blanking the thoughts, thus preventing the mind from concentrating on problems and generating stress.

Those who wish to clear their minds of stress’ negative energy and make room for positive energy to improve their lives should therefore consider a regular program of meditation for stress management. The two types of meditation should be explored, the more soothing chosen, and meditation made a regular part of your schedule. You will find that meditation is one of the most fruitful methods of freeing your mind from tension, handling stress, and energizing your spirit to meet the challenges of life in a fresh and effective way.

Author: Hilary Stewardson

Importance of Internet Primarily based IT Project Management Software Tool and On-line Task Management

2010-08-19T23:50:00.000-07:00

By: galaxy latindirectv

Project Management Software could be a easy Tool that helps Managers and therefore the Team Members successfully arrange, manage and execute the various Tasks concerned in each Project. All the Project Management Software is provided to perform the functions including Statistics and Reports, Manage Consumer Data, Comes, Tasks, Files, Contacts, Calendars, facilitating Multiple Projects and Multiple Users Management. Manage any project with ease, communicating all necessary details to your staff via the web.

Varieties of Project Management Software There are several types of Project Management Software. It will be a desktop application and it will also be a Net-Primarily based Software Solution to permit access from remote locations as needed. It can be a personal setup allowing solely a few to access it or it will be a collaborative set up which would allow to access many users simultaneously. These Project Management Software Solutions will work for numerous types of organizations.

Internet-Primarily based Project Management Software is typically termed as the newest generation high-level Project Management Software. In order to further assist internet technique of Management many firms have come back up with Project Management Tools. Project management System can facilitate your to manage your project efficiently if the project needs contributions of multiple people or groups employing a multi tiered development set up with in a very allocated time and existing resources. It organizes not just the elements of project as landmark targets but conjointly organizes the output of the team member in a very comprehensive manner.

The salient benefits of the web based mostly project management software are:
(a) It Helps the company sectors in increasing productivity as the Web-Primarily based Software don't needed to be installed.
(b) It immensely helpful in maintaining Multiple User Management, A Well-Organized Task Management Tool, Project Calendar and Email Notification.
(c) It also facilitates in obtaining the idea of various reports and comprehensive statistics, providing the overall huge picture on project advancement.

Selecting Right Project Management Software Project Management Software is meant to permit you to manage all aspects of your project wants effectively. There are varied sorts of this software available however most can permit for complete management from the start through completion. Here are a number of the advantages that you'll be able to expect from a Project Management Software that you just choose.

They're:
o It ought to produce multiple projects and tasks quickly and intuitively
o It ought to be simple, Easy to Use and user friendly furthermore
o It's the ability of operating on some of the foremost complicated of comes

Keeping all these aspects in mind we tend to at Inventa Technologies have designed latest generation Online Project Management Software Tool that increases the effectiveness of your work and therefore the happiness of your shoppers by making the work flow totally transparent to them. You'll purchase the software and host it yourself, or subscribe for a monthly fee and allow us to be sure of everything. Either manner, we tend to'll offer industry leading support if you wish it and will continue to feature nice new Project Management System options like:
1. Simple Project Management
2. Multiple User Management
3. Create Multiple Projects and Tasks
4. Security and Access Rights
5. Files Upload
6. Calendar
7. Contacts

Conclusion: Project Management Software may be a Web Primarily based Tool that helps to make Multiple Comes and Multiple Tasks quickly and intuitively. Online Project Management Software is suitable for individuals with for businesses who want an uncomplicated and effective IT Project Management Tool.

Article From Ubscure

The Most Effective Time Management Tips

2010-08-12T02:25:00.000-07:00

Time management tips can help you run a more effective projects so that your project doesn’t stall out due to improper use of time.

Below you can find time management tips which our expertize exclude as the most effective in time management process:

1. Think through the task you are about to undertake before you even begin it.

2. Don’t take on too many tasks at the same time.

3. Finish one project before starting on a new one.

4. Always strive to finish everything you start.

5. Streamline your paperwork so that you don’t waste time on needless duplications.

6. Ask for help. Delegate tasks rather than doing everything yourself.

7. Set aside uninterrupted time to complete a project so that you can avoid distractions.

8. Pay attention to instructions and conversations so that you get the details right from the first time.

9. Before you run an errand, make sure the items you are going for are ready.

10. Schedule your appointments during the morning hours so that you become more organized.

11. Maintain a clutter free home and workspace so that you don’t waste time looking for misplaced items.

12. Pick out your outfit for the next morning and have everything ready so that you don’t waste your time in the morning.

13. Always keep your gas tank at half full or more so that you don’t have to stop when it isn’t convenient.

Time is valuable and we often take it for granted. We either have too much or too little. Time is something to be respected and used wisely. Do not waste it for something which is not worth for because every waste on the end will finish with the thought “All I wanted was time!”

11 Tips for Improving Team Performance

2010-07-21T01:48:00.000-07:00

As a Project Manager, your success depends on how well your team performs. So if you want to improve your team performance, then there are lots of different ways that you can improve your team performance. Anyway we've listed here our Top 10 most important tips:

Tip 1: Show them the vision
People only perform well in a role if they understand what it is that they need to deliver and why. For this reason, we suggest you get your team together to reinforce the project vision, objectives, time frames and deadlines. Make your team feel wanted and needed by showing them that the project is critical to the success of the business. You will gain their buy - in and their commitment going forward.

Tip 2: Meet them individually
After your meeting, take each team member aside and tell them what it is that you need from them to help you deliver the project. Make sure they have a clear Job Description and they know how you are going to measure their performance. Ask them how they like to be managed, what motivates them and how you can support them in their role.

Tip 3: Give them room
At this point, you need to back off a little and give them room to perform. And if the pressure increases in your project, you need to give them more room than less. It's hard to do this, but you mustn't over - pressurize them or their performance will reduce, rather than improve.

Tip 4: Count the goals
As you back off, you need to put in place checks to measure their performance regularly. Meet with them individually every month to discuss their achievements, what's outstanding and how they can improve. Make sure you don't “bottle up” your concerns. Instead speak to them openly, keeping constructive at all times.

Tip 5: Be positive
If you're stressed and weary, ease off on your staff. Shouting or being negative will only rub off on them. It's incredibly difficult but you need to be positive, reassuring and supporting them at all times, even if the project is delayed.

Tip 6: Shake hands and pat backs
It's easy to forget to praise your team's successes. So every time you deliver a great quality product, finish a difficult task on time or get great feedback from a customer — congratulate those responsible in your team.

Tip 7: Meet at half time
Get your team together regularly to build a strong team spirit. Get them socializing together, so that new friendships are formed. The stronger the bond your team have with each other, the more likely they will work together as a single cohesive unit and achieve the objectives you have set.

Tips 8: Take time out
Don't be afraid to give team members time off for working hard. By taking time out, it will reduce sick leave, improve motivation and increase efficiency.

Tips 9: Give them what they need
Everyone is motivated by different things. You need to know what motivates every different member of your team. Get to know them well. If you can reward each person differently based on their motivations, then you'll improve their performance every time. This is the hardest trick in the book, but the one that pays the biggest dividends.

Tip 10: Celebrate your wins!
Staff all too often finish a project and move straight onto the next one without celebrating its success. When they do this, they carry their stress and pressure into the next project they work on. So help your team to "start afresh" by
celebrating your success at the end of the project.

Tip 11: Again... Don't forget Tip 9.

By taking these 11 tips seriously, you will improve the performance of your team and boost your chances of success. Give your team the right tools to help them complete their work quickly and to a high level of quality. This builds personal pride in their work, improving motivation and performance. Use the Seavus Project Viewer and tools from www.seavusproducts.com. They are developed by project management experts and have been professionally designed, they look great and give you the content you need.

The Best Microsoft Project Viewer for MPP files and Powerful Collaborative Tool

2010-07-20T06:29:00.000-07:00

Seavus Project Viewer is the single best software for viewing Microsoft® Project plans. It is a low-cost(trial) Viewer for Microsoft® Project that allows users to open, view and print project plans (mpp files) apart from Microsoft® Project.

On one side the project managers create and change project plans in Microsoft® Project, where on the other side project team members don't need to create and change project plans and use Seavus Project Viewer to view those plans

Seavus Project Viewer is the only project viewer that provides a collaborative environment for project teams without server installation. With Seavus Project Viewer, team members report task progress to project managers who either accept or reject them. Seavus Project Viewer's unique collaborative features empower teams to get real-time project status as well as to easily evaluate teams' performance and build knowledge for future projects.

Other features:

Increases productivity as it supports 100% of the views in Microsoft® Project 2003/2007 and provides additional custom project views. Saves money as it costs 90% less than MS® Project.
Saves money since MS® Project training courses for team members are not needed.
Easily understandable by all project stakeholders.
Introduces Seavus Project Search that searches information contained in the project files.
Open large sized MPP files with a lot of rows and various information in a seconds.

More fresh features:

Opens MS® Project 2010 files and supports almost all views.
Empowers project collaboration and task update within project teams through Google Apps™.
Searches information within mpp files. Having Seavus Project Search on your PC will save time searching for that specific information you need. In addition, Seavus Project Search also lets you search projects from Google Desktop Search as well as Windows Desktop Search.

Read more info on official Seavus Project Viewer page or download the trial HERE.

TimeSheet – record your work time | DetectorPRO

2010-05-30T14:13:00.000-07:00

TimeSheet – record your work time | DetectorPRO

Seavus Project Planner 1.3 released today

2010-04-23T00:12:00.000-07:00

Seavus Project Planner is project management software to plan and track projects, resources and costs. This is a desktop project management software capable to plan and track projects, manage resources and track project costs.The software allows project managers to organize work and project delivery as well as to manage resource schedules and scope changes.

Seavus Project Planner's core features include:

Project scheduling
Seavus Project Planner will reduce your efforts to define tasks, group them, set dependencies, define Milestones as well as assign resources and costs. Moreover, what-if scenarios that allow project managers to check project variances are supported by the unique unlimited undo/redo functionality.

Project tracking
Seavus Project Planner provides greater control over the project LifeCycle. Project tracking has never been easier with the unlimited number of baselines and numerous task progress update options (tracking toolbar, customizable forms toolbar and Gantt Chart).

Resource management
Project managers can easily assign resources to tasks as well as track and analyze their performance over time. This allows project managers to better manage resources in order to avoid over allocation.

Project cost tracking
Project costs can be controlled by assigning them to specific tasks and resources. Task updates will allow the Project Manager to track the costs and make fine-tunings if necessary.

Clean and intuitive workspace
Seavus Project Planner has an easy-to-use workspace that is complemented with Quick Bars that allow project managers to quickly navigate through the application reducing the time and effort to make the desired action.

New and powerful version 1.3 brings you:
• Google Apps Integration
• Master Project and Resource Pool
• Open API for developers
• Save your projects in PDF file

You can free download Seavus Project Planner 1.3 here.

People Management Tutorial and Tips

2010-04-21T06:02:00.000-07:00

This article covers key concepts related to Project HR Management and managing people involved in the project.

1. The knowledge area of Project HR Management consists of the following processes:
Develop Human Resource Plan, Acquire Project Team, Develop Project Team and Manage Project Team

2. The table below gives the inputs, tools and techniques, and Outputs for the Human Resource Planning process :
Enterprise environmental factors, Organizational process assets and Activity resource requirements

3. Responsibility Assignment Matrix (RAM) defines who does what. The Staffing Management Plan defines when will people get added and removed from the project.

4. A Project Manager may yield authority over the project team in one of the following ways -

Referent - project team knows the PM
Formal Power - Power due to Project Managers position
Technical Power - Project Manager has strong technical skills in the projects domain.
Coercive Power - The project team is afraid of the power the Project Manager holds.

5. Conflicts in the team are caused due to the following reasons in decreasing order of occurrences.

Schedules
Project Priorities
Resources
Technical Opinions

So the most common cause of conflicts in projects are issues related to schedules.

6. Conflicts are best resolved by those in the team.

7. There are standard conflict resolution techniques available to resolve conflicts. These are (from best to worst) -

Problem Solving or Confrontation (look at the facts, analyze them and find a solution). This is an example of win-win situation.
Compromising (Find the middle route). This is an example of loose-loose situation.
Withdrawal or Avoidance
Smoothing (Emphasize the agreements)
Forcing (Do it my way). This is an example of win-loose situation.

8. The process of problem solving has these steps -

Define the cause of the problem
Analyze the problem
Identify solution
Implement a decision
Review the decision, and confirm that the problem is solved.

9. War room is a technique for team building. As part of this the project team meets in one room. It helps to create a project identity.

10. Halo Effect is the assumption that because the person is good at a technology, he will be good as a project manager.

11. There are many organizational theories. Some of the main ones are - Expectancy Theory, McGregory Theory, Herzberg Theory, Maslow's Hierarchy of needs.

12. Expectancy Theory - People accept to be rewarded for their efforts. This is a motivation factor. People put in more efforts because they accept to be rewarded for their efforts.

13. McGregory Theory of X and Y - There are two type of employees. Employees of type X need to be always watched. They cannot be trusted and need to be micro managed. Employees of type Y, on the other hand, are self-motivated. They can work independently.

14. Herzberg Theory - Hygiene factors (salary, cleanliness etc.) if not present can destroy motivation. However good hygiene alone does not improve motivation. What motivates people is the work itself. The motivation factors for employees include responsibility, self-actualization, growth, recognition etc.

15. Maslow's Hierarchy of needs - there are various levels of needs for an employee. When a lower level is met, employee attempts to reach the next higher level. The maximum satisfaction is achieved when the employee reaches the highest level of satisfaction - self-fulfillment. These level of needs from the highest to lowest are -

Self-fulfillment
Esteem
Social
Safety
Physiology

The 5 Goals of a Project Manager

2010-04-17T11:34:00.000-07:00

These goals are generic to all industries and all types of projects. Regardless of your level of experience in project management, set these 5 goals for every project you manage.

Goal 1: To finish on time

This is the oldest but trickiest goal in the book. It’s the most difficult because the requirements often change during the project and the schedule was probably optimistic in the first place.

To succeed, you need to manage your scope very carefully. Implement a change control process so that any changes to the scope are properly managed.

Always keep your plan up to date, recording actual vs. planned progress. Identify any deviations from plan and fix them quickly.

Goal 2: To finish under budget

To make sure that your project costs don’t spiral, you need to set a project budget at the start to compare against. Include in this budget, all of the types of project costs that will accrue, whether they are to do with people, equipment, suppliers or materials. Then work out how much each task in your plan is going to cost to complete and track any deviations from this plan.

Make sure that if you over-spend on some tasks, that you under-spend on others. In this way, you can control your spend and deliver under budget.

Goal 3: To meet the requirements

The goal here is to meet the requirements that were set for the project at the start. Whether the requirements were to install a new IT system, build a bridge or implement new processes, your project needs to produce solutions which meet these requirements 100%.

The trick here is to make sure that you have a detailed enough set of requirements at the beginning. If they are ambiguous in any way, then what was initially seen as a small piece of work could become huge, taking up valuable time and resources to complete.

Goal 4: To keep customers happy

You could finish your project on time, under budget and have met 100% of the requirements—but still have unhappy customers. This is usually because their expectations have changed since the project started and have not been properly managed.

To ensure that your project sponsor, customer and other stakeholders are happy at the end of your project, you need to manage their expectations carefully. Make sure you always keep them properly informed of progress. “Keep it real” by giving them a crystal clear view of progress to date. Let them voice their concerns or ideas regularly. Tell them upfront when you can’t deliver on time, or when a change needs to be made. Openness and honesty are always the best tools for setting customer expectations.

Goal 5: To ensure a happy team

If you can do all of this with a happy team, then you’ll be more than willing to do it all again for the next project. And that’s how your staff will feel also. Staff satisfaction is critical to your project’s success.

So keep your team happy by rewarding and recognizing them for their successes. Assign them work that complements their strengths and conduct team building exercises to boost morale. With a happy motivated team, you can achieve anything!

And there you have it. The 5 goals you need to set yourself for every project.

Of course, you should always work smart to achieve these goals more easily.

The author of this post is Jason Westland who has 15 years experience in the project management industry. From his experience he has created software to help speed up the management process. If you would like to find out more information about Jason’s online project management software visit ProjectManager.com.

Fast and Effective Scrum Tutorial for New Scrum Master and New Project Managers

2010-03-16T15:17:00.000-07:00

This quick tutorial will introduce you and your company to utilizing the Scrum project management process.

Scrum is perhaps one of the simpler project management methods to learn and implement. In this guide, I will show you how to speak the language of Scrum and utilize this valuable management tool for your company.

Basic Scrum Vocabulary

Before being able to implement Scrum, it is important to be familiar with some key words in the the Scrum vocabulary.

Sprint- a 30-day focused effort moving the team toward fixed goals.

Product Backlog- a constantly prioritized to-do list.

Sprint Backlog- a list of the highest prioritized items from the product backlog.

Scrum Master- the coach for the product management team and works to ensure the realization of the goals of the sprint.

Product Owner- represents the customer and is responsible for prioritizing the backlog.

Scrum Team- a group of 5-9 people who self-organize and have joint responsibility for the completed tasks.

The Scrum Process

Now that basic vocabulary related to Scrum has been defined I will detail the Scrum process step-by-step.

1. Creating a backlog – in this step, the Product Owner and Scrum Team meet in order to discuss the priority and items on the Product Backlog. The Product Owner must be able to form the product vision. The Product Backlog then, is a prioritized list of what is required for the project and is ranked with regard to importance.

2. Once the product manager creates the backlog, then there will be a Sprint Planning Meeting. During the first phase of the meeting, the Product Manager describes to the team the goals of the project and explains the Product Backlog. During the second phase, the Scrum Team will select the items to be completed during the sprint from those with highest priority on the Product Backlog.

3. Once the items to be worked on have been selected, a potential Sprint schedule is constructed – taking into account the availability of the team members to devote their time to the project. The items in the Product Backlog are assigned and broken down into individual tasks. Once this occurs, this document is the Sprint Backlog.

4. The Sprint begins and lasts from 15-30 days. During the Sprint, no other tasks are added to the backlog.

5. Daily Scrum begins when the sprint begins. The Daily Scrum is a 15 minute stand-up meeting where each member of the team gives a very brief report to everyone else – what they accomplished since the last DailyScrum, what they hope to accomplish, and issues that have come up. Here, the Scrum Master will make note of issues and attempt to resolve them – after the meeting.

6. Sprint Review – once the Sprint ends, everyone gets together in a meeting to share what he or she accomplished during the sprint.

7. The process begins again with a new list of prioritized tasks on the Product Backlog.

While this is a very brief overview of the Scrum process, there is enough information here in order to begin implementing Scrum in your own company. The only temlaplates for running projects with scrum is Product BackLog and Sprint BackLog. You can plan resources, time and estimations of individual items from the Product BackLog with Microsoft Project or other planning tool.

Click here to read additional Project Management articles related to Agile methodology.

3 Tips to Avoid Most of Project Management Issues

2010-02-28T05:16:00.000-08:00

It doesn't take much for a small web project to go off the rails. We've all seen it. The project can be moving along perfectly with the client and stake holders satisfied with the progress being made, and then, all of sudden, before you've even realised it, you're scratching your head wondering how it got to this point. It's a common issue in the web design industry. There's no secret remedy for combating these issues, rather a combination of planning, diligence and common sense will assist in preventing disastrous web project outcomes. Below are list of helpful tips for ensuring the project remains on track.

Yes, you still need a Project Initiation Document

Just because it is small, doesn't mean planning is not required.
The most important phase in the life cycle of a small web project is the Project Initiation Phase. All too regularly, people dive straight into the project, particularly when it is only relatively small, without the required planning. For some inexplicable reason, people will not reserve the necessary planning for a smaller job merely because it is not overly complex. Anyone who has managed a number of web projects will tell you that the small projects can be just as tricky as some of the bigger ones. So, with this in mind, it is critical to apply a methodical, well-thought-out approach to a web project of any size. A methodical approach begins with the Project Initiation Phase.

Project Initiation Phase is when you determine why the project is happening, what the project is attempting to achieve and what are the key factors that define the project's success. One of the critical steps to a well-planned initiation phase is the development of a Project Initiation Document. This document is a collaborative effort between the web design team and the client. The purpose of the document is to ensure all those involved are in agreement on the scope of the project.

The project initiation document ought to summarise:
1. Key Objectives
  - A mission statement for the proposed site
  - Proposed site goals
  - Site KPIs
2. Audiences
  - Identify your audience
  - User goals
  - User profiling
3. Functionality
4. Content
While the Project Initiation Document is critical to the success of the project, it is advisable to keep it relatively concise. Another pitfall to no planning is too detailed planning.
Project Plan

Start simple and then get more detailed.
After the Project Initiation Document has been completed and all participants are in agreement on the scope, the next step to ensuring the project is moving in the right direction is to create a Project Plan. A project plan can take a variety of forms, depending on the nature of the project. It is unrealistic to plan the entire project in minute detail from day one, it just doesn’t happen. Web projects, regardless of size, evolve as discovery, user focus and design is undertaken. Keeping this point in mind, the project plan needs to start simple and then delve into more detail.

Initially, the project plan is a basic extrapolation of the Project Initiation Document which stipulates the key deliverables of the project, a high-level timeline and the resources needed for the project’s execution.

Once this plan has been documented, break-up the project into segmented items of work, such as strategy, pre-production, design, development and deployment. In each of these segmented items of work, specify mini milestones and designate a person to action each mini milestone. These mini milestones need to be documented into a working chart or spreadsheet with a dead line, so that the project continues to progress.
Risk Management Plan

Don’t risk not doing it.
At the beginning of the project it is necessary to outline any risks to the project’s development. All projects, even the small ones, have risks associated with delivery in the specified time frame, budget and specification. Risks can be anything from the time needed to complete the project, to the technology being used, to the client’s expectations and understanding of the job.
Some points to consider when developing the risk management plan:
1. Rank each potential risk in order of its likelihood
2. Determine how damaging each risk is to the success of the project
3. Outline how these risks will be mitigated
4. Don’t be afraid to share the risks with the client. Transparency and communication is often the biggest hurdle for any web project

Summary
It is impossible to preempt everything that is going to occur during the development of a web project, however, by devoting the required time to planning during the Initiation Phase, working on a project plan and outlining the potential risks, there is a much greater chance of avoiding unexpected issues.

An article of James Hinton from http://www.wiliam.com.au provides the most information of this article.

Teambuilding and Benefits

2010-02-15T09:48:00.000-08:00

This is a word we hear a lot these days: ‘we need some kind of teambuilding activity’. But from our point of view, often the people saying it don’t really know what they mean.

It’s as if we all know that teams are good. We understand the sum of the parts thing, but we don’t quite know how to make a team work in the way we think we want it to.

When it comes to teambuilding, the very first question we have to ask is, what for? In other words, what are you building it to do?

Sometimes it can genuinely mean building the team: new people coming together, a change of roles, new expectations, sorting out difficulties or communication issues. All good things to prompt the need for teambuilding.

But sometimes it isn’t that at all.

For example, we were recently asked to run a teambuilding day for a group of people and almost as soon as we met them and started putting the programme together, we realised they were a very ‘built’ team already. That wasn’t the issue.

The issue was that their ‘output’ wasn’t what the company expected from them and so they (the company) thought if they had a teambuilding event the team would work better.

Uh uh. That’s not teambuilding. It is, however, team development. And increasingly, we find that when people talk about teambuilding that’s what they really mean.

Part of this whole process is learning about how teams work. And, get this – no matter what the books say (and there are plenty of them) - every single team is different: there is no model you can follow that will create the perfect team.

You’ll read that you need ideas people, drivers, completer-finishers, etc., etc., etc. And yes, possibly you do need a variety of ‘types’. But for our money, the ‘types’ are far less important than ensuring that your team knows why it exists and what its aims are.

So let’s look first at just exactly what being a team means. You might think that the very word ‘team’ is clear in and of itself: a group of people working towards shared goals. We wish it were that straightforward. As it isn’t, we thought we would unpick it a bit.

The common enemy

The most obvious kind of team that you’ll know about is a sports team. Everyone is on the same side trying to beat the opposition. They train together, get to understand how to make the most of each other’s skills, and when working well, they are able to fulfil the manager or coach’s strategy.

They know who their opposition is and they have very clear goals. Yes, there may be personality quirks and differences, but the whole truly is greater than the sum of its parts.

However, it’s not quite so straightforward when it comes to work teams, though, is it? Personalities, which in a sporting context might get absorbed by the team for the good of the game, often take centre stage in the workplace.

The oddest thing of all, of course, is that it’s not always clear who the ‘opposition’ is. You’d think it would be the competition – whoever your closest corporate rival is. Unfortunately, far too often, the opposition turns out to be right at home base: another team or department, the ‘management’ or someone sitting right beside you.

Now the thing about ‘opposition’ is that it gives a common focus, a common ‘enemy’ if you will. Now that’s great if it’s productive. Creative ideas can pour out of a group when they have to figure out how to handle the competition.

However, when the common enemy is someone or some group or some department or a ‘them’ and ‘they’ are within the same company, then the results are divisiveness, gossip, complaining. The end result of this is of course a loss of productivity and people working against, not for each other.

Then it’s all about ‘them’ and ‘us’, with people running around using their energies to get more of ‘us’ to agree just what’s wrong with ‘them’. We see this in company after company after company – people are spending vast amounts of time and energy having a ‘go’ at each other rather than using that same amount of time and energy to make things work better.

This is one of the key reasons why ‘teambuilding’ is such a hot topic. People can easily recognise that something needs to be done, but they aren’t quite sure what.

What can be done?

They are right. Something does need to be done because there are real payoffs and advantages to being part of a well-functioning team. To begin with, it’s just pleasanter being around people who get on.

More importantly, real payoffs include:

A feeling of identity
On-going support
Creative pooling of ideas
Increased confidence
Things tend to work better as a result of team effort
You aren’t alone
Goals that make sense

You don’t have to reinvent the wheel, or if you do, so is everyone else in the team

So the first thing you have to ask yourself is this:

What kind of team are you?

These days we see a lot of ‘virtual’ teams – people who hardly ever see each other, or even work in the same office or even the same country.

Then there are teams that all sit in an open plan space and chat with each other all day as things arise.

There are teams where people sit in separate spaces and get together once a day/week/fortnight.

There are teams that seem to do all their communicating via e-mail or conference calls.

There are teams that work on projects together and others where people go off and do their own thing and come together every once in a while to report and bring everyone else up to date.

At PMTutor.Net, for instance, our ‘team’ consists of a group of freelance partners and associates who come into the office as and when, some full-time permanent staff who are at ‘base camp’ most of the time and a bunch of associates in training and support staff who we see when they are needed.

Everyone is however still a member of the PMTutor.Net team. What makes it a team are shared values, goals and objectives. And, of course, our old friend communication. Sometimes we fail abysmally, but a lot of the time we get it right; enough so, that people do feel part of this identity known as PMTutor.Net.

To work effectively you need agreement on exactly what sort of team you are: what the goals are, what each member's role is, who needs to work closely with whom, what the game plan should be. Sometimes it’s as simple as learning more about the people you work with, and sometimes it’s a whole lot more complicated, such as working through entrenched difficulties or defining how a long-distance team communicates.

So what is your team? The better you are at identifying what kind of team you are, the better you’ll be able to identify what it needs to work well. Yours doesn’t have to be a classic team. This is actually where many people get confused. They have a picture of what a team is supposed to be, but then find themselves part of something that doesn’t fit that picture.

Here are a couple of other things teams don’t have to be:

They don’t have to be a family.
People don’t have to be bosom buddies.
People don’t even have to like each enough to want to have dinner together.
Teams aren’t group therapy.
Teams can, on occasion, be any or all of those things.

It may still be a team; it just may not look like one. Whatever it looks like, however, it still has to be able to function well and achieve its goals.

Which leads us to the second question.

What do you want your ‘teambuilding’ event to achieve?

Teams are complex machines and it's not surprising that they malfunction occasionally or need re-alignment.

Do you want people working better together?
Do you want to set new team goals and agreements?
Do you need to iron out communication difficulties that have crept in?
Do you want a jolly – to reward the team for being terrific?
Do you simply want to get everyone’s creative juices going and brainstorm new ideas?
Do you need to set clear parameters and boundaries so everyone knows what’s expected of them?
Do you want to inject some fresh enthusiasm and energy into a group that’s been working too hard and may have lost sight of the goal posts?

Perhaps the goals posts have moved and you need to let everyone know that.

A team event can encompass any and all of those questions.

The one thing that everyone recognises is that whatever you want to call it (building or development, event or away day), ‘it’ needs to be done away from the office environment. The idea is to slow things right down; to get away from e-mails, phone calls, questions and demands, people dropping by, being asked to pop into unscheduled meetings. It means getting away from all the day-to-day stuff that sometimes makes it hard to see what’s going on and what’s needed.

Once you know what you want your event to achieve, then you can decide what it’s going to look like. You can do the go-carting thing, the throwing people off Welsh mountains thing. You can have the cosy get-away in a country hotel thing. You can have it non-stop fun, be business focused or have a bit of both.

The key always is to ensure that your event has a positive effect on the morale, motivation, confidence and effectiveness of the team and its individual members.

Models that illustrates the process of motivation, needs - drives - behaviour - goals - reduction or release of tension

2010-01-28T02:15:00.000-08:00

Joe Kelly (How Managers Manage) presents a simple model that illustrates the process of motivation.

Behaviour is both directed to, and results from, unsatisfied needs. The word unsatisfied is most important. As Maslow says,

"If we are interested in what actually motivates us and not what has or will, or might motivate us, then a satisfied need is not a motivator."

Kelly's model of motivation presents a sort of chicken-egg dilemma. Which comes first, the goal or the need? When we talk about behaviour being goal-oriented, we mean that individuals feel a need, want, desire or drive to do something that leads to the achievement of a goal. But is the goal, as part of the self, already there? Is it the factor that stimulates the need? Are goals and needs the same thing?

It is useful to separate the two concepts. We can define a goal as that outcome which we strive to attain in order to satisfy certain needs. The goal is the end result, the need the driving force that spurs us towards that result. A student might have a goal to get an A in a course, but this goal may reflect a number of different needs. He or she may feel a need to confirm his or her competence; friends may all be getting A's; he or she may wish to have the esteem of others; simply to do the best possible: to keep a scholarship. It is difficult to infer needs from goals.

We talk about money as a motivator. Money represents so many different things to different people that saying that individuals "work for money" is meaningless. What we have to know is what needsthe money is satisfying. Is it survival, status, belonging, achievement, a convenient scorecard for performance? Remember, behaviour is both directed to, and results from, unsatisfied needs.

Every individual has a number of needs which vie for satisfaction. How do we choose between these competing forces? Do we try to satisfy them all? Much like a small child in a candy store, faced with the dilemma of spending his or her allowance, we are forced to decide what we want the most; that is, we satisfy the strongest need first.

Although there is general agreement among psychologists that man experiences a variety of needs, there is considerable disagreement as to what these needs are - and their relative importance. There have been a number of attempts to present models of motivation which list a specific number of motivating needs, with the implication that these lists are all-inclusive and represent the total picture of needs. Unfortunately, each of these models has weaknesses and gaps, and we are still without a general theory of motivation.

In this article, I will describe the four main theories of motivation. These are Maslow's Hierarchy of Needs, Herzberg's Dual-Factor Theory, The Need for Achievement and David McClelland's work and Vroom's Expectancy Motivation Theory.

Hierarchy of Needs - Abraham Maslow

One model of motivation that has gained a lot of attention, but not complete acceptance, has been put forward by Abraham Maslow. Maslow's theory argues that individuals are motivated to satisfy a number of different kinds of needs, some of which are more powerful than others (or to use the psychological jargon, are more prepotent than others). The term prepotency refers to the idea that some needs are felt as being more pressing than others. Maslow argues that until these most pressing needs are satisfied, other needs have little effect on an individual's behaviour. In other words, we satisfy the most prepotent needs first and then progress to the less pressing ones. As one need becomes satisfied, and therefore less important to us, other needs loom up and become motivators of our behaviour.

Maslow represents this prepotency of needs as a hierarchy. The most prepotent needs are shown at the bottom of the ladder, with prepotency decreasing as one progresses upwards.

SELF-ACTUALISATION - reaching your maximum potential, doing you own best thing
ESTEEM - respect from others, self-respect, recognition
BELONGING - affiliation, acceptance, being part of something
SAFETY - physical safety, psychological security
PHYSIOLOGICAL - hunger, thirst, sex, rest

The first needs that anyone must satisfy are physiological. As Maslow says:

"Undoubtedly these physiological needs are the most prepotent of all needs. What this means specifically is that in the human being who is missing everything in life in an extreme fashion, it is most likely that the major motivation would be the physiological needs rather than any others. A person who is lacking food, safety, love and esteem would probably hunger for food more strongly than anything else".

Once the first level needs are largely satisfied, Maslow maintains, the next level of needs emerges. Individuals become concerned with the need for safety and security - protection from physical harm, disaster, illness and security of income, life-style and relationships.

Similarly, once these safety needs have become largely satisfied, individuals become concerned with belonging - a sense of membership in some group or groups, a need for affiliation and a feeling of acceptance by others.

When there is a feeling that the individual belongs somewhere, he or she is next motivated by a desire to be held in esteem. People need to be thought of as worthwhile by others, to be recognised as people with some value. They also have a strong need to see themselves as worthwhile people. Without this type of self-concept, one sees oneself as drifting, cut off, pointless. Much of this dissatisfaction with certain types of job centres around the fact that they are perceived, by the people performing them, as demeaning and therefore damaging to their self-concept.

Finally, Maslow says, when all these needs have been satisfied at least to some extent, people are motivated by a desire to self-actualise, to achieve whatever they define as their maximum potential, to do their thing to the best of their ability. Maslow describes self-actualisation as follows:

"A musician must make music, an artist must paint, a poet must write, if he is to be ultimately happy. What a man can do, he must do. This need we may call self-actualisation ... It refers to the desire for self-fulfilment, namely the tendency for one to become actualised in what one is potentially. This tendency might be phrased as the desire to become more and more what one is, to become everything that one is capable of becoming.

The specific form these needs take will of course vary greatly from person to person. In one individual it may be expressed maternally, as the desire to be an ideal mother, in another athletically, in still another aesthetically, the painting of pictures, and in another inventively in the creation of new contrivances. It is not necessarily a creative urge although in people who have any capabilities for creation it will take this form."

Several points must be made concerning Maslow's model of motivation. First, it should be made clear that he does not mean that individuals experience only one type of need at a time. In fact, we probably experience all levels of needs all the time, only to varying degrees. In many parts of the world, hunger is a genuine reality but we have all experienced the phenomenon of not being able to concentrate upon a job because of a growling stomach. Productivity drops prior to lunch as people transfer their thoughts from their jobs to the upcoming meal. After lunch, food it not uppermost in people's minds but perhaps rest is, as a sense of drowsiness sets in.

Similarly, in almost all organisational settings, individuals juggle their needs for security ("Can I keep this job?") with needs for esteem ("If I do what is demanded by the job, how will my peers see me, and how will I see myself?") Given a situation where management is demanding a certain level of performance, but where group norms are to produce below these levels, all these issues are experienced.

If the individual does not produce to the level demanded by management, he or she may lose the job (security). But if he or she conforms to management's norms rather than those of the group, it may ostracise him or her (belonging) while the individual may see him or herself as a turncoat (esteem) and may have a feeling of having let the side down (self-esteem.) We do not progress simply from one level in the hierarchy to another in a straightforward, orderly manner; there is a constant, but ever-changing pull from all levels and types of needs.

A second point that must be made about Maslow's hierarchy is that the order in which he has set up the needs does not necessarily reflect their prepotence for every individual. Some people may have such a high need for esteem that they are able to subordinate their needs for safety, or their physiological or belonging needs to these. The war hero springs to mind. There is little concern for safety or physical comfort as the seeker of glory rushes forward into the muzzle of destruction.

A third, and very important point to be made about Maslow's hierarchical model is the assertion that once a need is satisfied it is no longer a motivator - until it re-emerges. Food is a poor motivator after a meal. The point in this is clear for management. Unfortunately, many organisations and individuals still fail to get the message. Most incentive schemes are based upon needs that have already been largely satisfied. If management placed emphasis on needs that have not been satisfied, employees would be more likely to be motivated towards achieving the goals of the organisation. Human behaviour is primarily directed towards unsatisfied needs.

Finally, an important aspect of Maslow's model is that it provides for constant growth of the individual. There is no point at which everything has been achieved. Having satisfied the lower needs, one is always striving to do things to the best of one's ability, and best is always defined as being slightly better than before.

There has been a great deal of debate over Maslow's hierarchical concept of motivation. It has a basic attraction to most people because it seems to be logical, to make sense.

Dual-Factor Theory - Frederick Herzberg

Frederick Herzberg and his associates began their research into motivation during the 1950's, examining the models and assumptions of Maslow and others. The result of this work was the formulation of what Herzberg termed the Motivation-Hygiene Theory (M-H). The basic hypotheses of this theory are that:

1. There are two types of motivators, one type which results in satisfaction with the job, and the other which merely prevents dissatisfaction. The two types are quite separate and distinct from one another. Herzberg called the factors which result in job satisfaction motivators and those that simply prevented dissatisfaction hygienes

2. The factors that lead to job satisfaction (the motivators) are:

achievement
recognition
work itself
responsibility
advancement

3. The factors which may prevent dissatisfaction (the hygienes) are:

company policy and administration
working conditions
supervision
interpersonal relations
money
status
security

Hygienes, if applied effectively, can at best prevent dissatisfaction: if applied poorly, they can result in negative feelings about the job.

Motivators are those things that allow for psychological growth and development on the job. They are closely related to the concept of self-actualisation, involving a challenge, an opportunity to extend oneself to the fullest, to taste the pleasure of accomplishment, and to be recognised as having done something worthwhile.

Hygienes are simply factors that describe the conditions of work rather than the work itself. Herberg's point is that if you want to motivate people, you have to be concerned with the job itselfand not simply with the surroundings.

In a medical sense, growth, healing and development occur as natural internal processes. They are the result of proper diet, exercise, sleep etc. Hygienic procedures simply prevent disease from occurring. They do not promote growth per se. Herzberg says that we should focus our attention on the individuals in jobs, not on the things that we surround them with. He maintains that we tend to think that growth and development will occur if we provide good working conditions, status, security and administration, whereas in fact what stimulates growth (and motivation to grow and develop) are opportunities for achievement, recognition, responsibility and advancement.

Once again, this theory has a basic attraction. As Joe Kelly puts it, however:

"It is always as well to bear in mind that academics, who place considerable value on autonomy and inner direction, have an obsession about making work meaningful. The notion that it is possible to realise man's true nature through creative work which is its own reward is an exceedingly attractive proposition to the learned don which is rarely fully shared by his wife".

Herzberg goes further than Maslow, cutting the hierarchy off near the top and maintaining that motivation results only from some elements of esteem needs and self-actualisation.

The Need for Achievement - David McClelland

The one single motivating factor which has received the most attention in terms of research, is theneed for achievement (n-ach). As a result, we know more about n-ach than any other motivational factor. Much of this knowledge is due the work of David McClelland of Harvard. To illustrate what he means by the need for achievement, McClelland cites the following example:

"Several years ago, a careful study was made of 450 workers who had been thrown out of work by a plant shutdown in Erie, Pennsylvania. Most of the unemployed workers stayed at home for a while and then checked with the employment service to see if their old jobs or similar ones were available. But a small minority among them behaved differently; the day they were laid off, they started job hunting. They checked both national and local employment offices; they studied theHelp Wanted sections of the papers; they checked through their union, their church and various fraternal organisations; they looked into training courses to learn a new skill; they even left town to look for work, while the majority when questioned said they would not under any circumstances move away to obtain a job. Obviously the members of the active minority were differently motivated".

Individuals with a high n-ach have a number of distinctive characteristics which separate them from their peers. First of all, they like situations where they can take personal responsibility for finding solutions to problems. This allows them to gain personal satisfaction from their achievements. They do not like situations where success or failure results from chance. The important thing is that the outcome be the result of their own skill and effort.

A second characteristic of high n-ach people is that they like to set moderately high goals for themselves. These goals are neither so low that they can be achieved with little challenge, nor so high that they are impossible. High n-ach individuals prefer goals that require all-out effort and the exercise of all their abilities. Once again, the achievement of this type of objective results in greater personal satisfaction. This phenomenon can be observed in very young children. A child may be given a game of ring toss, told that he or she scores whenever a ring lands over the peg and then left alone to play the game. McClelland comments:

"Obviously children who stand next to the peg can score a ringer every time; but if they stand a long distance away, they will hardly ever get a ringer. The curious fact is that children with a high concern for achievement quite consistently stand at moderate distances from the peg where they are apt to get achievement satisfaction ... The ones with low n-Achievement, on the other hand, distribute their choices of where to stand quite randomly over the entire distance. In other words, people with high n-Achievement prefer a situation where there is a challenge, where there is some real risk of not succeeding, but not so great a risk that they might not overcome it by their own efforts".

A third distinctive characteristic of high achievers is that they want concrete feedback on their performance. Only certain types of jobs provide this kind of feedback, however, and so some kinds of jobs are unattractive to high achievers. For instance, teachers receive only imprecise, hazy feedback as to the effectiveness of their efforts while production managers have a daily output chart to look at with either joy or disappointment.

There are some additional minor characteristics possessed by high achievers. They tend to enjoy travel, are willing to give up a bird in the hand for two in the bush and prefer experts to friends as working partners. The image is clear; the high achiever is a personality type suited admirably to certain jobs and not others. It would be wrong to treat all individuals as high achievers and attempt to motivate them by offering them challenging jobs, rapid and objective feedback on performance and personal responsibility for success or failure.

The need for affiliation and the need for power

McClelland has also identified two other types of need, the need for affiliation (n-affil) and the need for power (n-pow). His testing procedure is concerned with the application of what is known as theThematic Apperception Test (TAT), a series of pictures which are presented to a subject, one at a time. The individual is asked to tell a story about each picture. The underlying assumption of the TAT procedure is that it will reveal the dominant thoughts and attitudes of subjects. For instance, an individual with high n-ach will formulate stories concerned with getting things done, challenging situations, feelings of satisfaction at having done a good job and so on. The individual with a high need for affiliation (n-affil) will reflect sensitivity to the feelings of others, a desire for friendly relationships and a reference to situations which involve human interactions. High n-power subjects will relate stories reflecting the process of influencing others, controlling and manipulating others.

The need for affiliation

The need for affiliation is similar to Maslow's need to belong. It can be a dominant motivating force affecting behaviour and may manifest itself in many different ways. The novelist John O'Hara was supposedly obsessed with the fact that, not having a college degree, he was excluded from membership of certain clubs and societies. At the other end of the spectrum, James Coyne, a former Governor of the Bank of Canada, was described as the most unclubbable man in the country, as he held an aversion to joining groups. In its most straightforward form, a need for affiliation manifests itself in a desire to be liked by others, to be part of a group, to enter into warm, personal relationships. High n-affil people value relationships over accomplishments, and friendship over power.

The need for power

In studying the motivational profiles of North American managers, McClelland noticed that many of those who reach the top of organisations and are rated as highly effective in their positions, demonstrate a concern for influencing people. This is, in McClelland's terms, a need for power. This need is not simply seen as the raw desire to control others or simply to exert authority. McClelland makes the point that:

"... this need must be disciplined and controlled so that it is directed toward the benefit of the institution as a whole and not toward the manager's personal aggrandisement. Moreover, the top manager's need for power ought to be greater than his or her need for being liked by people."

Power motivation refers not to autocratic, tyrannical behaviour but to a need to have some impact, to be influential and effective in achieving organisational goals.

Results

McClelland examined the motivational needs of a large group of managers whose units demonstrated varying degrees of morale. The most important factor, in predicting whether a manager's subordinates would exhibit high morale, turned out to be how their need for power related to their need for affiliation. Teams which exhibited higher morale were those in which the manager's need or power exceeded their desire to be liked. McClelland puts forward the following explanation:

"Sociologists have long argued that, for a bureaucracy to function effectively, those who manage it must be universalistic in applying rules. That is, if they make exceptions for the particular needs of individuals, the whole system will break down. The manager with a high need to be liked is precisely the one who wants to stay on good terms with everybody and therefore is the one most likely to make exceptions in terms of in terms of particular needs. ...Sociological theory and our data both argue ... that the person whose need for affiliation is high does not make a good manager."

Organisation man?

Power-motivated managers, like achievement orientated managers and the affiliators, demonstrate distinct characteristics:

They are highly organisation-minded. They feel responsible for building organisations to which they belong. They believe strongly in centralised authority.
They like to work. This is different from the high achiever who likes to minimise work by becoming more efficient. While the high achiever minimises effort and maximises output, the power-motivated manager enjoys work for its own sake.
They are willing to sacrifice some of their own self-interest for the good of the organisation.
They have a strong sense of justice, feeling that hard work and sacrifice should be rewarded.

The picture of McClelland's power-motivated manager is reminiscent of the organisation mancaricatured by William Whyte. The message seems to be that if one is dedicated to the institution, committed to the work ethic and unflagging in energy and devotion, success will follow. However, the increasing popularity of switching jobs as a method of rapid advancement and the rapidity of change in organisations somewhat contradicts this type of thinking.

Expectancy Theory of motivation - Victor Vroom

Victor Vroom, of Carnegie-Mellon in Pittsburgh, has challenged the assertion of the human relationists that job satisfaction leads to increased productivity. (This theory has been called thecontented cow approach to management.) The assumption is that if management keeps employees happy, they will respond by increasing productivity. Herzberg, in a delightful film of motivation, highlights the fallacy of this assumption with an interview between a manager and a secretary. The secretary is complaining about the job, and the manager lists all the things that have been done for the secretary - increases salary, new typewriter, better hours, status and so on - at the end of which she looks straight at him and asks, So what have to done for me lately?

The point may be made that satisfied needs do not motivate people Hygienes simply keep employees quiet for a time. For an individual to be motivated to perform a certain task, he or she must expect that completion of the task will lead to achievement of his or her goals. The task is not necessarily the goal itself but is often the means of goal attainment. Vroom defines motivation as:

"A process governing choices, made by persons or lower organisms, among alternative forms of voluntary behaviour."

In organisational terms, this concept of motivation pictures an individual, occupying a role, faced with a set of alternative voluntary behaviours, all of which have some associated outcomes attached to them. If the individual chooses behaviour 1, outcome A results; if 2 then B results and so on.

Knowing that individuals choose behaviours in order to obtain certain outcomes is nothing new. The question is why they choose one outcome over another. The answer provided by the motivational theories in the other articles in this short series (Maslow, Herzberg, McClelland) is that the choice reflects the strength of the individual's desire or need for a specific outcome at a certain time.

However, Vroom makes the point that task goals (productivity, quality standards or similar goals attached to jobs) are often means to an end, rather than the end in itself. There is a second level of outcomes which reflect the real goals of individuals and these may be attained, in varying degrees, through task behaviour.

An individual is motivated to behave in a certain manner because (a) he or she has a strong desire for a certain task outcome and a reasonable expectation of achieving that outcome and (b) because he or she also expects that the achievement of the task outcome will result in reward in terms of pay, promotion, job security, or satisfaction of individual needs - physiological, safety, esteem and so on.

Let us take a look at how the model works. Imagine a manager has as a task goal, receive good ratings for internal customer service. The choice of this task goal reflects three things:

The strength of the need for good ratings versus some other goal.
The expectation that this goal can be achieved.
The expectation that the achievement of this task goal will lead to desired rewards - promotion, increased security and so on.

Vroom would maintain that we do things in our jobs in order to achieve second level rewards:

"If a worker sees high productivity as a path leading to the attainment of one or more of his or her personal goals, he or she will tend to be a high producer. Conversely, if he or she sees low productivity as path to the achievement of his or her goals, he or she will tend to be a low producer".

Certainly Vroom has hit on an important aspect of motivation. We do not attempt simply to satisfy a need or even a set of needs in a straightforward, "If I do this, then I will achieve that" manner. We work with a chain of goals and rewards, where goals in one area are only a means of achieving goals in another.

An article of Robin Stuart-Kotze from www.managementlearning.com provides the most information of this article.

How To Motivate Team Members - Part 3

2010-01-24T23:58:00.000-08:00

The last 5 tips of the serials of tips "How To Motivate Team Members" are below. The first 10 tips you can find at this link: How To Motivate Team Members - Part 1, and the second group of 10 tips at this link: How To Motivate Team Members - Part 2.

20. During a discussion, if there is a point that needs clearing up find the time to clarify or ask for a clarification. Misunderstandings can lead to huge blunders and these can be detrimental to how you feel about your team members. Avoid conflict and resolve situations before they can damage the team morale, or that of individuals.

21. Spot the motivators within your team; there are individuals that put a spark in the atmosphere, they are active and they compel others to show the same energy without ever saying it. If you have a good motivator prioritize his career development plans so even if there is no room for vertical growth, he gets satisfaction from horizontal growth within the organization.

22. Brainstorming sessions produce some great ideas and when they are one on one they show your team members they are considered important. Along with importance should come responsibility so give them roles they can fulfill according to their capabilities and interests.

23. Divide the project into parts where you can give individuals smaller achievable goals. This gives them the freedom to do things their way while letting them gain in confidence as well as motivation to do the best they can.

24. Achievement of organizational goals should lead to benefits. These can be monetary benefits as well as packages that provide the team members, e.g. medical cover or something similarly advantageous.

25. Last but not the least, keep Maslow’s Hierarchy of needs in mind; not every individual has the same motivational needs and while a certain incentive would work for one team member it would not motivate the other and can even backfire. For instance, if a member is financially insecure he will value a raise more than anything else, but the same raise will not work on a financially secure member, he can be concentrating on job security or his own safety, therefore it is of utmost importance to get to know your team. Once you have worked out where they stand on the hierarchy of needs, you can work out the best motivational incentive for them. Macro-management does not pay the dividends.

Short conclusion of this serial which will help to the most of Project Managers to reach their goals with their teams is most valuable: Capability to express the ideas on the way that will not produced defensive reaction, Listens the others and communicates clearly and constructively. Respects opinions of others, even if conflicting.

Useful links:
How To Motivate Team Members - Part 1
How To Motivate Team Members - Part 2

Common Mistakes in Project Planning Process

2010-01-24T01:22:00.000-08:00

This is something that a lot of Project Managers sometimes forgot it when planning projects, and I see some project managers overlook it. It’s obvious when you point it out, but that’s as long as you are not in the pit with the alligators.

Monitor & Control Work Appropriately

I was once in a situation where the scope of my project was constantly changing. This happens on all projects of course, at least those of any size and complexity. It’s a natural process. This one was particularly bad.

One day, I asked myself how much time had been spent in replanning activities. How much time had the other project managers spent? The project controllers? Myself? What is all this re-planning costing us in terms of schedule, dollars, and quality?

Then the obvious hit me. The project team had also been impacted of course. They had to sit down and re-estimate tasks, consider impacts of the changes, etc. Every step of the way. Where was this tracked?

Nowhere.

Nowhere?

This goes back to a common mistake when constructing a WBS and defining the scope of your project. Sure, you have a “project management” element at level 2 in your WBS. Do your engineers charge there when their attention is diverted away from getting things done and instead goes towards project management related activities?

After all, the time they spend re-planning with you is deducted from the time they would otherwise have been doing design work, writing code, or whatever their real job on your project is. If they record that time appropriately, you can use it. If they just charge it as normal work, it’s a lost opportunity.

But Why Track It Anyway?

I’m not advocating you track this for the sake of it. Only track what makes sense. This gives some benefits you may want to consider:

It helps you know what the impact of re-planning is to your project. By not hiding this diverted work alongside the real work, you can know the impact to schedule, budget, and quality.
It helps you manage your stakeholders. Solid data about past impacts to project work resulting from massive scope changes can help ensure change requests are submitted and approved only when the value outweighs the costs.
It helps with better estimates in the future. By really knowing what it takes for you and your team to respond to scope changes, you can now include the estimated impacts of this inevitable project activity, instead of missing deadlines or going over budget because you failed to factor change into your project planning.

How To Motivate Team Members - Part 2

2010-01-18T09:06:00.000-08:00

Here are another 10 tips of the series "How To Motivate Team Members". The first 10 tips you can find on this link: How To Motivate Team Members - Part 1:

10. Listen to your team members talk; give them your ear from time to time and really listen. This should be a ritual every few days to get their perspectives. You can get new ideas and things they say can help you improve your policies and even benefit your business.

11. When a team member comes to you with a problem be positive in your analysis, try to find a definite solution and back him to work it out, even if you have to roll up your sleeves and help. Earning respect with deeds goes further than words.

12. Always support your team, give them confidence and give them opportunities to fulfill your confidence. It is imperative that you tell them you are there to support them in case they are stuck.

13. Not everyone can handle every job. As a leader it is up to you to pick the right person for the right job because while an under confident member can gain loads from successfully achieving his goal, failure has a huge negative impact on morale.

14. Eating together can be a relationship builder, have team lunches where someone gives a work related presentation. You basically end up killing two birds with a single stone.

15. Let your team be creative. Your team’s productivity is likely to go up if you give them a day where they can try out their ideas, as long as it has something to do with the project at hand, let them enjoy themselves.

16. What do people work best for? Something they have stakes in, those can be monetary stakes and they can be emotional or personal attachments. If you instill a sense of ownership in the team they will take the team goals as their personal goals, you need not worry about the end product after that; it is going to be their best effort.

17. Give them something fun to look forward to. That can be some time off at a board game or you can have a bake off or something similar. It is good to pit the junior members against the seniors and let them enjoy the competition. Or you can have work parties, give people responsibility to arrange them and bring people out of their shells so they take up responsibilities as well. The whole program helps lighten the mood and you share something good to eat too.

18. Encouragement goes a long way within a team and individually. When someone does well, be generous in your praise. An email to recognize a good idea, a pat on the back for a quick delivery or praise in front of the team or senior management is an excellent way to tell them they are appreciated.

19. When you ask for ideas and input it is usually the shy team members that lag behind. Give them time as well as the opportunity to come forward and speak. Listen carefully and evaluate ideas on merit, make sure not to discourage anyone though; telling them off for a bad idea means they probably will not speak again.

20. During a discussion, if there is a point that needs clearing up find the time to clarify or ask for a clarification. Misunderstandings can lead to huge blunders and these can be detrimental to how you feel about your team members. Avoid conflict and resolve situations before they can damage the team morale, or that of individuals.

Useful links:
How To Motivate Team Members - Part 1
How To Motivate Team Members - Part 3

How To Motivate Team Members - Part 1

2010-01-17T03:30:00.000-08:00

Motivation is a complex “methodology” and process which is crucial part of every project cycle. Simple, if team members are motivated the project progress is always without any bigger problems, and existing problems are solved fast with enthusiasm. But, how to motivate all team members, the same incentives do not work on all individuals. Here is a list(part 1) of motivating tips that work, and you can use these tips for most of members in your team depending of their team and personal characteristics.

1. Always start with yourself; to motivate others you have to be motivated yourself and should look for positives in all situations. As a role model, if you are energetic and inviting your team will have confidence in you and will follow willingly.

2. Share the information you have about the project and give them a sense of ownership. It is their project; they should know the circumstances and limitations surrounding the project. This can lead to team members coming up with good suggestions as well.

3. When you face a work related problem your team is your best resource, and one that can rise to the occasion if you manage to motivate them. Take your problems to them; discuss and look for ideas and ways out of trouble. Once they feel you are a part of the team it is easier to rev them up good.

4. While discipline is important, strive to keep your work environment as informal as possible. People usually work better without the boss breathing down their neck so push for deadlines but in a manner that makes it a team goal they can take pride in achieving instead of an order that precedes insults on failure.

5. Projects are divided into phases; a good PM motivates his team by pointing out the milestones within the project. Usually you can arrange for special celebrations upon reaching the milestones on time. Plan your work parties ahead of time, or plan them during work hours so the team can all gather around and enjoy instead of worrying about other commitments.

6. Always appreciate your team members, even the small tasks that result in the leader saying ‘thank you’ can make people strive harder for appreciation. While communicating, choose your words wisely; be humble, use words like we instead of I.

7. During evaluation do not try to pin the blame on anyone as it creates an environment of distrust. For a good team environment you have to make them believe it is a team accomplishment or team failure.

8. Provide feedback in a positive manner; give them what was done right, mention the shortcomings and how the team can do better. Be a part of the team when there is blame to take but end your feedback on a positive note.

9. Everyone eats, take individual team members out to lunch, discuss trivial things as well as work related matters and just let them enjoy the time. Its free lunch to them and your time is well spent because at the end of it you have established a relationship from which you get fresh ideas and a willing worker who knows he is valued.

10. Listen to your team members talk; give them your ear from time to time and really listen. This should be a ritual every few days to get their perspectives. You can get new ideas and things they say can help you improve your policies and even benefit your business.

This post was created using most of the information from site: http://blog.softwareprojects.org

Useful links:
How To Motivate Team Members - Part 2
How To Motivate Team Members - Part 3

How To Calculate the Critical Path - Easy Way

2010-01-16T13:43:00.000-08:00

One way to identify the critical path is simply to add the time durations in each of the possible paths through the network and identify the longest path.

Assessing Slack Time
Another method that reduces the risk of missing paths that are "near critical" is to determine the slack for each activity, which is defined as the difference between the late start and the early start (or late finish and early finish) for each activity. The critical path is then the path through the schedule which has the least amount of total slack time.

The early start is calculated by working forwards through the network from start to finish (the forward pass), and identifying the earliest date that each activity can start and finish based on its dependencies. The formula is:

Early Finish = Early Start + Duration

The late start is calculated by working backwards through the network from finish to start (the backwards pass), and identifying the latest date that each activity can start based on its dependencies, if an overall (target) completion date is to be achieved. If there is no such target date, simply use the early finish date of the last activity from the forward pass. The formula is:

Late Start = Late Finish - Duration

The float or slack for each activity is calculated as the difference between the late start and early start (or late finish and early finish) for that activity. The formula is:

Slack = Late Finish - Early Finish (or Late Start - Early Start)

How To Write A Scope Statement

2010-01-14T23:35:00.000-08:00

This article illuminates the necessity of an effective scope statement and how to write one that will help guide a project to successful completion. The various sections of a scope statement are discussed, as well as hints on how to minimize scope creep.

Introduction - Where to Begin
A scope statement is one of the most critical pieces of a project, and writing one can be a difficult task for a project manager. But, an effectively written scope statement can help the rest of the project flow along with minimal problems. Lets take a look at how to write a good scope statement, its necessary components, and the pitfalls to avoid during its creation.

The firsts step on writing a scope statement is filling in the project name, project charter, and a listing of the project owner, sponsors, and stakeholders. Next, A project justification will need to be identified, as well as project requirements, milestones, and deliverables. Any non-goals - items that fall outside of the scope of the project - need to be identified here. And finally, cost estimates need to be provided within the scope statement. This information may be readily available or it may need to be compiled from various sources, but the scope statement is where it needs to be documented all together. This can be a cumbersome task, but it is a necessary one. As the project progresses, everyone involved knows where they can look should a question arise.

A scope statement is just one of many project management forms.

Clear and Concise is the Rule
A scope statement needs to be very clear and concise, and the project name is a good place to start. An effective project name reads something like 'Create a Marketing Plan For Increasing Sales of Widget X in Chicago'. This is much better than 'Marketing Plan Project', which is definitely concise but by no means clear. The aim of the project name is to document the project so that everyone involved is aware of what is expected during the life of the project. A good project name also helps provide a vision of where the project is headed. You can download an example of a scope statement by clicking here.

A project charter needs to be drafted next. A charter is usually used for three different reasons:

•Authorizing the project
•Providing a high level overview
•Identifying the main stakeholders

The charter often includes the name of the project owner as well as project sponsors. It also identifies objectives or goals, and constraints on resources or time. Finally, the charter is used as a focal point throughout the life of the project, which can be especially useful during change control meetings for minimizing scope creep. Scope creep is a phenomenon where the scope of a project gradually increases over time.

The scope statement needs to identify the reason for the project. This is often called the project justification. It is usually a statement or two identifying why the project is being created. It’s important to have the project justification identified because this helps to give overall direction to the project as well as emphasizing the final goal. The project justification should be clear and precise manner so that it identifies a quantifiable measure of success for the end of the project. An effective justification might read like the following:

This project is to create a successful marketing plan for the month of August 2008, in order to increase sales of Widget X by 15% in the Chicago metropolitan area. This is a good example of an effective justification because it is quantifiable and qualitative. Distinct boundaries are set as to what is the expected result of the project so there is no ambiguity.

Requirements, Deliverables and Non-Goals
The next section in the scope statement should list the requirements of the project. The requirements are objectives that must be met during the project, and often they include significant milestones or goals. The objectives need to be quantifiable and identified clearly. Any milestones or goals need to be also clearly identified, as well as any non-goals. Non-goals are items that are specifically not going to be addressed by the project, which helps to eliminate the scope creep. By clearly identifying these as non-goals, the scope cannot include them later on without going through a change management process. Ultimately, many project managers track their milestones, goals, and/or deliverables using a Work Breakdown Structure.

The deliverables for a project need to be clearly identified within a scope statement. If necessary, deliverables need to be tied to specific milestones in the project schedule. The deliverables also need to be agreed upon by the major stakeholders as well as the project owner. Deliverables may include any training necessary for personnel at the culmination of the project. Or deliverables may be a final product to be provided to the stakeholders. No matter what makes up a project's deliverables, specific details regarding them is the golden rule. The more clearly the deliverables are identified and specified, the less chance there will be for scope creep to occur later on.

Cost estimates for the project should also be included in the scope statement. This is an essential process of project planning, so the cost estimates should be as accurate as possible. If the cost estimates are too low, the project will go over budget - sometimes significantly so. If the cost estimates are too high, resources that are allocated to the project - whether they are money, equipment or people - are unavailable for other projects and could negatively affect them. So the more on track the cost estimates are, the more efficient and successful the project will be. This can be a difficult task for the project manager to do, but effective cost management is a critical success factor for projects.

Finalization and Acceptance
The last significant section of a scope statement is the formal acceptance signatures. Once the project manager has compiled all of the documentation into a concise and clear statement, all of the major stakeholders as well as the project owner need to sign off on it. This is a very significant step and can be a very useful tool in mitigating scope creep as well. A meeting should be held where everyone can be provided a copy of the scope statement. At that time, any discrepancies can be cleared up or last minute changes can be made. Once everyone signs off on the scope statement, there should be agreement between all parties and the project can begin. By having everyone sign the scope statement, there is very little chance of surprises down the road. And in the event that something does pop up, there is documentation of what was agreed upon initially so that changes can be made if necessary. If anything does change down the road and the scope does need to be increased for some reason, signatures should be obtained from everyone once more.

Exhaustively detailed specifics, clear and concise language throughout, and avoiding ambiguity are the keys to making a scope statement effective and useful. It is also very beneficial to have all of this information documented in one place - even if the process of creating it is enormous. The task of creating a scope statement can encompass a great deal of time for any project manager, but the rewards usually include more successful projects and minimized scope creep throughout. And this can be a highly desirable benefit, as scope creep is often a significant cause of project failure. So document as much as possible, as clearly as possible, and make sure everyone involved is aware of what is expected. Through clear and concise documentation, a scope statement's usefulness shines all the way to project success.

The Difference Between a Leader and a Manager

2010-01-12T05:18:00.000-08:00

Manager Development
Leader. Leadership.
One of these might be the first word that comes to mind when someone asks themselves, "What qualities make a good manager?" That word might or might not be part of any individual person that is a manager.

Some may think that a Manager and a Leader are the same, but they are not necessarily identical. An effective manager will have leadership qualities and "manager" will be only one facet of a "LEADER."

A Leader possesses a natural set of talents that inspire people to follow, to be loyal, and to produce. Some managers have these qualities, but others do not possess them, or have them to some degree that can be enhanced through training and coaching. Ongoing Professional Development would target that need and a good alternative would be Self-Improvement training through books, a career coach, a counselor, a job club, a professional organization, or other entities and resources.

Those managers that do not have specific leadership qualities and talents or that do not receive guidance to draw them out sometimes work much harder than their subordinates to produce results for the company. In extreme cases, they may even become workaholics and possibly feel that their subordinates are not capable of adequate work production and quality. He/she may become resentful of them and they of him/her.

Advancement On the Job
Regardless of the dynamics, some of these managers remain stymied in the same occupational title and pay level for decades. They become "too valuable in their positions to replace' and "not valuable enough" as asset for the administration develop to move up the ladder and secure increased company results. Such development may be viewed as a risky gamble by the company leadership and training costs and replacement costs to move up that manager may be formidable.

We have seen the portrayal in film, television, and art of the frustrated, hardworking manager toiling around the clock in rolled-up shirtsleeves. Such a hands-on manager, in fact, can be inspiring to subordinates, but he can also work himself into illness. He/she likely could accomplish more for the company by delegating duties and leading subordinates into a network that is structured for optimal results.

Leadership qualities are the characteristics that propel the manager upward in the company and a long-term career. They produce increased business results for the company and the customers or clients that it serves.

Functions of a Manager
Sometimes, a manager is a babysitter with a glorified title. This might be someone that accepts the title "Manager" and by doing so, helps to lower an organizational framework over a group of people - There are now a Manager and Subordinates, where before, everyone was more or less equal and a kind of pecking order likely existed - This pecking order, actually, is an informal Vertical Team in a self-placed hierarchy. There is a clearer hierarchy after the installation of a Manager and the natural pecking order may assert itself more strongly within it. In fact, some people might quit if they do not think the Manager deserves to be a Manager, even if there is no increase in pay or duties with the title. Whatever the manifestation, if the Manager does not use leadership qualities to advantage, the dynamics of the work group may change for the worse.

Sometimes a manager is actually a frontline worker (as opposed to a supervisor) that is paid just a bit more than subordinates in order to set a faster, more productive work pace. I have known managers that earned only 5 cents per hour more than their subordinates, yet produced 50+% more work output, performing the same job and having very few additional responsibilities. One such manager's only additional role was to be the first of the group to arrive and the last to leave, just before the Department Supervisor.

A Manager and a Leader, then, are not necessarily the same. In addition, effective management is a skill needed by leaders when they hope and plan to rise in the workplace to higher, more responsible, and better-paying job titles during a long-term or lifelong career.

Different Job Personalities

Leadership
Leadership is one characteristics of an Effective Manager.

The goal a manager is to maximize work output for the company. To do so, effective managers must:

•Organize
•Plan and schedule
•Hire, staff, develop, and fire as needed
•Direct assigned operations
•Control production and costs
•Act as a role model - e.g. work in production him(her)self as needed

At times, leadership is not even required in management - very self-motivated teams do not always need a central leader (this is more like a democratic Horizontal Team). Other times, a natural leader may arise in a work group, and is not the Manager. This may result in conflict.

Points of View
Managers often think in terms of production and Leaders think in terms of the future.

Managers may follow manuals and quotas while Leaders follow their own vision and innovation.

Managers work, while Leaders think and create.

Managers are often a cog in the company wheel of production, while Leaders are outside production as stand out in their un-cog-like differences.

Aside from the foregoing discussion, effective Managers need these skills. We can remember them by recalling:

I CEEE CAT (I see cat.)
Integrity
Effective, Appropriate, and Timely Communication
Enthusiasm/Energy
Empathy
Competence
Calm During Crises - Confidence and skillful problem-solving
Ability to Delegate
Team-Building Skills

Additional characteristics, skills, and personal qualities will enhance the work of and the results achieved by both Leaders and Managers, and the above list is a very good foundation upon which to build an effective Job Personality.

How To Select Team Members

2010-01-09T13:43:00.000-08:00

Selecting Team Members from within the Organization Selecting team members from within your organization follows roughly the same process as hiring someone from outside the company, but tends to be much less formal because you already know something about the people being suggested for the team. You might actually have less say in which existing employees are on your team than you would if you hired someone because other factors, such as availability, priorities, relationship with the functional manager, and so on, contribute to the decision. Establishing Team Structure and Roles One of the advantages of virtual teams is that team members tend to focus more on getting the job done than on the office politics and gossip that often derails colocated teams. To facilitate this focus, managers and team leaders must be explicit about expectations, structure, and roles.

Expectations As a team leader or manager, your expectations, assumptions, and responses to questions and situations set the tone for the project. In addition, team members come to the project with expectations, assumptions, and needs of their own. When establishing the team, it is important to identify such expectations and to ensure that, by the end of the initial meeting (see the section in this article titled “Initial Meeting”), the team is focused on the same objectives and has the same expectations about the project. Think about and document the following areas when defining your expectations:

- Communication between team members, with upper management, with functional groups, with customers, and with other employees - Vision for the project - Behavioral expectations (e.g., time, how well people play in the sandbox with each other, conflict management, and so on) - Escalation pathways for conflicts and disagreements that cannot be resolved within the team

- Recognition and reward

- Percentage of available work time that each person will devote to the project - Relationship of project to other priorities

- Hierarchy

- Percentage of time for billable work and for administrative work (it is unrealistic to expect much more than 80 percent billable hours, particularly if the job requires intense concentration or creativity)

- Methodology for measuring success. Some expectations may require negotiation with the team, so be prepared to discuss areas of disagreement or misunderstanding during the initial meeting. Be conscious of conflicts that arise as the project progresses due to unspoken or unconscious expectations. As they arise, document team decisions, and ensure that the entire team is aware of the expectation. Structure, Roles, and Responsibilities The structure of the team and its relationship to the corporate hierarchy forms the framework upon which the roles and responsibilities hang.

The structure of the team defines how each functional area will work together, as well as who shows up for reviews, who manages changes, who works with whom, and how often meetings are held. Each member of the team should have a clearly defined and documented role and set of responsibilities for the project. These responsibilities might have significant overlap with the person’s overall job description.

Then again, they might be highly specific to the particular project. For example, one medical company had a major product recall due to a malfunction that was causing serious injury and death. The company pulled its top performers onto the recall team to address the problem. Team members found themselves performing duties that, while outside their typical responsibilities, were necessary to save lives and to find out how to fix the problem. Be careful of the “other duties as assigned” statements; such phrases tend to be a catch-all and, if you are not careful, can often distract the team from its primary task due to conflicting priorities from project management and line management. For areas of overlap, be sure to define decision trees to help determine who deals with the issue. The more clear you can be, the fewer conflicts you will have within the team and the more easily team members can direct someone to the appropriate person. Leadership On virtual teams, leadership is shared. While one person might be assigned as the project manager, responsible for the budget and schedule, everyone on the team provides leadership in some area. For example, team members who are experienced with working virtually typically take extra time at the beginning of the project to find ways of establishing rapport with their distant colleagues, and are very proactive about their communication.

Other team members are good at planning teambuilding activities, and connecting people comes naturally to them. Still others are highly competent technically and become the “go-to” person on some aspect of the project. A good team leader actively encourages these unofficial roles because the team becomes more invested in the project if each member feels that his or her contribution matters. As mentioned in Article 1, the leader’s attitude, particularly at the beginning of a project, sets the tone for the entire team. It is important, therefore, that the leader resolve any conflict or doubt about the goals of the project before setting up the team. Core Team The core team on a project typically includes the functional leads from each discipline required to complete the project. These team members get involved at the very beginning of the project and stay involved throughout the process.

These core team members typically include the following roles and areas of expertise:

- Project manager

- Requirements analyst

- Design engineer/developer

- Documentation

- Localization manager

- Marketing

- Regulatory affairs (medical or other regulated products)

- Testing/quality assurance

- Manufacturing/packaging

Depending on the complexity of the project, these core members might have additional people working for or with them on the project. However, the team leads are the ones who provide the continuity, attend most of the project-related meetings, and review or collate their functional group’s comments before presenting them to the project team. Associated Subject Matter Experts In addition to the core team members who stay with the project for its duration, subject matter experts (SMEs) might be brought in to assist with specific aspects of the project.

These SMEs typically have specialized skills or knowledge that the project team needs to access for a short period of time. Examples include reviewing the final engineering diagrams for electrical issues, providing assistance with troubleshooting a particularly complex testing issue, evaluating the ethical issues that arise during a clinical trial, and so on. These experts typically work with the core team members on a specific task and then move on to other work. The core team members are responsible for ensuring that the SMEs have the information that they need to accomplish the tasks assigned to them. Localization and Other Vendors Companies often hire contractors or consultants to assist with aspects of a project that are outside the company’s primary focus. Localization is a primary example. Bringing localization into the project early can reduce costs and problems later on. Particularly for large projects that involve many languages, it is a good idea to include the localization vendor in the initial project meeting and to keep the vendor apprised of project status throughout the project. Many companies assign a localization manager to act as a liaison between the localization vendor and the project team. This localization manager identifies issues that may affect the schedule or localizability of the product. Some companies also have a vendor manager who works with subcontractors on a project to ensure that they have everything they need. This arrangement is particularly helpful if the vendor in question is developing a component that must later be integrated into the product as a whole. (See Article 6 for more information on working with vendors.) Setting the Ground Rules Once you have established the team structure and have identified the core team, it is time to get the project started. The tone and organization of the start phase has lasting implications on how well the entire project goes, so it is imperative that you carefully plan the initial meeting, teambuilding activities, and guidelines for team interaction. In addition, if you have members of your team who are not experienced in working virtually or in multicultural environments, consider assigning them a mentor who can work with them and guide them as they learn their role.

Initial Meeting The initial meeting sets the tone for the project, so during this meeting it is vital to accurately set expectations and ensure that everyone understands the goals, deliverables, and schedule for the project. Perhaps even more important, however, is the rapport building and teambuilding that occurs. It is best if this meeting can take place in person. The cost of getting everyone together for a few days at the beginning of a big project will be saved many times over with fewer conflicts and better communication. Shared experiences and goals are the fastest ways to build rapport within a team. If you absolutely cannot hold the initial meeting in person, try to hold a video conference. From a psychological and sociological standpoint, it is important for people to be able to visualize their teammates so that they can “hear” and “see” the human being on the other side of the email, instant message (IM), or telephone.

There is a tendency for people to be more blunt, to say things in email that they would never say to someone’s face, and for issues to escalate more quickly when most of the interaction is via email or IM if the people involved have never met in person or via telephone. Nothing derails a project faster than flame wars or, conversely, team members feeling that their ideas and information are going into a “black hole,” where the recipient never responds to anything he or she receives.

Communicating with the Team All the tools in the world are not going to be useful if your team does not understand how to use them to communicate effectively. Before beginning any project, it is critical to establish a set of guidelines for team communications including what information to share, which method of communication to use for each, and specifically how you expect to communicate and how often. Then you can determine which tools are appropriate for the various types of interaction your team is likely to use. Early in the process, establish and distribute guidelines for interteam communications. Enforcing clear, consistent guidelines can help prevent misunderstandings and improve the way information gets shared. Synchronous vs. Asynchronous Interaction The primary consideration when choosing a method for communicating between team members is the urgency of the message. If something is extremely urgent (think “fire alarm”), then you need to use a “synchronous” mechanism to ensure that the team members get exactly the same information at exactly the same time. Synchronous tools include conference calls, meeting software, chat rooms, VoIP, and instant messaging software.

Messages with less urgency can be sent with an “asynchronous” tool that team members can access at their convenience. Asynchronous tools let your team members access the content of messages repeatedly, and are good for reference information such as project plans, schedules, or to-do lists. Asynchronous tools include email, message boards, wikis, intranets, and blogs. One-to-One Conversations The bulk of your daily interteam communication is likely to be one-to-one. When all team members are colocated, a lot of communication occurs as casual conversations or one-to-one in-person meetings. In a virtual team, however, the one-to-one communication requires a bit more planning. If all of your team members are online most of the time, instant messaging software (like AIM, Yahoo! Messenger, or Lotus SameTime) can be a quick and easy way for team members to communicate with each other. Messaging tools generally allow team members to set up the software to display whether or not other team members are online and available, and can be set to store a log of each conversation (though many people do not use the logging feature).

VoIP and chat rooms can also be used for one-to-one meetings, depending on the relative cost and ease of access to the team members, though VoIP technologies might be more complex to set up and possibly more costly than is efficient for brief discussions. One-to-Many Email Most of us are fairly comfortable with email communication. It is easy to fire off a short message, and the message can be sent to numerous recipients at the same time. However, sometimes the ease of sending quick notes to many people can be one of the drawbacks of email. If you are not careful, responses intended for a specific person may get sent to the wrong recipients. Many senders have regretted messages sent in anger or been embarrassed by writing a private message (usually something critical or uncomplimentary) and then sending it “to all.” As with any written communication, the sender can sometimes “hear” one message while typing, but the person on the other end gets an entirely different message. Humor does not often come across very well, and the nuances of language, like sarcasm, metaphors, or informal expressions, can be easily taken the wrong way. Misunderstandings can easily occur, particularly if your team members come from different cultural backgrounds, whether or not they are using the same language.

Many of the drawbacks of email can be avoided or minimized by establishing and distributing a set of guidelines for email communication within your team. The guidelines are likely to vary by team and project. For example, if some team members use email software that cannot handle large attachments, you might want to specify alternative methods for file transfers (such as posting to a wiki or using an intranet). If some people have limited or shared storage capacity, consider establishing guidelines for how long (or where) messages are stored. Establish a subject heading convention that works for your team. For example, you might want to preface each subject line with [project name] for easier sorting, or use more specific tags like [budget], [schedule], or [status] when sending budget, schedule, or status types of email. Or you might decide on a code for very short messages that fit in the subject line so recipients do not need to open the email message at all. For example, [EOM] at the end of the subject line indicates that the entire message is contained in the subject line — there is no content in the body of the email itself. If email is a primary communication mechanism, establish a policy for how often team members will read their email — once a day, twice a day, once an hour, etc. Similarly, you might want to provide a recommended turnaround time.

For example, depending on the specific needs of your group, you might suggest that emails be answered within one working day. Many of the drawbacks of email can be avoided or minimized by establishing and distributing a set of guidelines for email communication within your team. The guidelines are likely to vary by team and project. For example, if some team members use email software that cannot handle large attachments, you might want to specify alternative methods for file transfers (such as posting to a wiki or using an intranet). If some people have limited or shared storage capacity, consider establishing guidelines for how long (or where) messages are stored. Establish a subject heading convention that works for your team. For example, you might want to preface each subject line with [project name] for easier sorting, or use more specific tags like [budget], [schedule], or [status] when sending budget, schedule, or status types of email. Or you might decide on a code for very short messages that fit in the subject line so recipients do not need to open the email message at all. For example, [EOM] at the end of the subject line indicates that the entire message is contained in the subject line — there is no content in the body of the email itself. If email is a primary communication mechanism, establish a policy for how often team members will read their email — once a day, twice a day, once an hour, etc. Similarly, you might want to provide a recommended turnaround time. For example, depending on the specific needs of your group, you might suggest that emails be answered within one working day.

The Best 7 Project Management Applications Online

2010-01-08T06:19:00.000-08:00

Whether you are looking to organize your personal life at home or to collaborate on a team project with your coworkers, here are some of the best web-based project management software that can help you stay organized and on top of your work.

All online project management apps discussed here offer introductory free accounts so you can use them at home or school as well without requiring any budget. And since they are online apps, you can successfully manage your projects, tasks and deadlines from virtually any computer.

1. Basecamp
Keep up with what needs to be done on your project

Basecamp from 37Signals attempts to keep you focused on the tasks at hand with its task-centric interface. The main dashboard shows all the upcoming tasks and milestones of all of your projects organized by date.

While creating to-do lists, you can assign individual items to any of the team members or everyone. There’s a message board associated with every project where you can share project updates or even post questions without having to email anyone – it’s just like an online message board but accessible only to your internal team who’s part of that project.

Basecamp offers wiki-style Writeboards for collaborative writing. Project members can additionally chat with the group through Campfire which is like a web-based instant messaging tool that also save a chat transcript for reference later.

Basecamp offers a free account for 1 project with unlimited users but you cannot add documents and other files to the project. For additional projects and features, upgrades are available starting at $12/month. There’s no learning curve involved.

2. Goplan
Know how long you’ve spent on each task

Goplan is a task-orientated project management tool that provides a discussion board, calendar, document storage (with file versioning), timesheets, tasks and tickets (e.g. for bug tracking and resolution).

One of the very unique features of Goplan is that it lets you easily track the time you spend on different tasks. It works like this. When working on a particular task (or a ticket), you can start the timer inside Goplan (the clock icon) and update your status so that everyone in the team is aware of what you are working on. When you stop the timer, this gets recorded automatically in your time sheet.

When creating new tasks and tickets inside Goplan, you can attach documents and other files to the project. And if you have team members who aren’t part of the project, they can still add tickets to the project by simple emailing a note to a specific email address.

Goplan offers more projects with the free plan than most other project management apps. The free plan provides 3 projects for 2 users, and 100Mb of online storage space for your files. Upgrades are available starting at $10/month for additional projects, users, and storage.

3. Soshiku
Manage your school or college assignments

Soshiku is aimed primarily at high school and college students to help them keep track of all pending assignments and other school work.

The home page shows all of the assignments that are due today, as well as upcoming events and assignments for the full week. You can invite partners (or your classmates) and collaborate on class assignments within Soshiku itself. You can also attach files up to 50 MB in size with assignments.

Although other project management products can be useful for students, Soshiku is designed specifically for students with no extra features and it’s completely free (supported by ads).

4. Harvest
Track Time and Money spent on projects

With Harvest, you can easily track time spent on a task using the web interface or through dedicated desktop widgets available for Mac and PC. Harvest offers integration with Basecamp, so you can use Harvest’s time tracking features along with the other project management features found in Basecamp.

If you are freelancer who’s using Harvest to track the time spent on a project, you can use the same tool to directly produce invoices for your clients for your time and other expenses. Once an invoice is created, the invoice dashboard keeps track of all open, past due, and recently paid invoices.

Harvest offers a free account for one user with up to 2 projects, 4 clients, and unlimited invoicing, and then offers upgrades with unlimited projects and additional users and features starting at $12/month.

5. Co-op
Know what team members are doing right now

Co-op helps you track updates from everyone in the team inside a Twitter style interface. Team members can post anything in their status updates and it is visible to the entire team. The best part is that co-op includes built-in time tracking from Harvest (discussed above) so everyone know what you have been working on and for how long.

6. DeskAway
Know how your project is going with graphs and reports

If you want to keep track of your projects with graphs and reports, DeskAway could be a good service for you. DeskAway supports tasks, milestones, calendar, time sheets and file sharing. You can email all members of the project using DeskAway itself and the messages are also archived in a central location.

DeskAway offers detailed reports and graphs showing information about completed, overdue, and upcoming deadlines, as well as graphs showing your overall progress on various projects. You can also create an internal blog with DeskAway for team members.

DeskAway offers a free account for up to 3 active projects, 5 users, and 25MB of file storage but without support for issue tracking. You may upgrade starting at $10/month for accounts with more features including additional users, storage space and deskmail (a feature that lets you manage tasks via email).

7. Zoho Projects
Stay connected in a group project with social networking

There are quite a few things that set Zoho Projects apart from competition. For instance, if you already have your project plan created inside Microsoft Project, you can import the file into Zoho Projects and easily make that switch from desktop to web based apps.

Like most other Zoho services, you can log into Zoho Projects using your existing Google Account or Yahoo! credentials. Zoho Project is integrated with Google Docs so you can attach documents with your projects that are already on Google Docs. And like other online project management apps, Zoho Projects too offers an iCal feed of the project calendar so you can track milestones, tasks, etc. in Google Calendar or even Outlook.

With Zoho Projects, you can add tasks and milestones to a project, and communicate with your team through wikis, built-in chat, and forums (or message board). Each forum has a unique email address so you can post replies to forums posts via a simple email message.

The free version of Zoho Projects will let you create a single project with 1 wiki and 100 MB of file storage. The premium version of Zoho Projects offers support for timesheets, invoices and additional projects at $12/month.

Agile development methods and CMMI – Factors that Affect Perception - MISUSE - Part 2

2010-01-06T00:07:00.000-08:00

Whether analyzing the CMM or CMMI, there is one thing shared by both works that makes them unique—they are models, not standards, for improving product quality and process performance.

However, for nearly two decades, the software industry has experienced the result of people misusing appraisal ratings as entry criteria, confusing appraisal ratings for measures of business performance,and misapplying a model as a standard in an environment in which products are created
to meet contractual requirements.

Used in this way, CMM and CMMI best practices were misinterpreted and misused. It is not an exaggeration to say that any approach to improve an organization’s achievement of business objectives in such an environment would have difficulty overcoming an emphasis on RFP requirements
and keen competition for multi-year contracts.

Does this situation mean that CMMI is wrong for software? Not in the least. It simply illuminates the following reasons why some perceive CMMI to be incompatible with

Agile ideals:

The context from which the CMM and CMMI originated was specific to a particular customer base having unique challenges and characteristics of high risk and low trust.
The CMM and CMMI were a new paradigm introduced into a large (and dominant) industry where paradigms, including the attitudes and beliefs associated with them, were in place for many years (e.g., command and control).
Agile ideals developed as a backlash against the inefficient software development patterns that arose in this industry.

These points describe the context in which the CMM and CMMI were developed. This context enables us to understand some of the characteristics of the CMM and CMMI and how they have been used over the past two decades. While the language of CMMI, admittedly, may retain some of the flavor and phrasing of this context, each release of a CMMI model grows further away from these roots to embrace a richer and more dynamic set of contexts (Users of older model versions may not fully make the transition as new versions are released, and older beliefs and values may persist. Further, while CMMI and SCAMPI materials continue to evolve, it is simply not possible
to bring all users rapidly forward to the newer versions, government edicts and SEI encouragement notwithstanding.) Users of older model versions may not fully make the transition as new versions are released, and older beliefs and values may persist. Further, while CMMI and SCAMPI materials continue to evolve, it is simply not possible to bring all users rapidly forward to the newer versions, government edicts and SEI encouragement notwithstanding.

Further, this context is not the sole element determining how CMMI should be used, when and where it can be used, or what defines whether CMMI is being properly used. Nor for that matter, does this context determine its applicability in other contexts. The challenge is for the broader community to identify the practices and methods (or practice implementations) that enable organizational maturity in more dynamic contexts (e.g., internet commerce, social networking, and games development). An increasing subset of both CMMI and Agile method users are trying to do just that.

The Origins Of CMMI

2010-01-05T00:27:00.001-08:00

Before receiving the “CMM” name, the first Capability Maturity Model-like framework was published in 1989 by Watts Humphrey in his book, Managing the Software Process. A few years earlier, the U.S. DoD announced a request for proposals (RFP) to address the excessive amount of money being spent on software that was either never delivered or delivered late with little of its expected functionality.

The contract awarded on the basis of the RFP was to establish what we know today as the Software Engineering Institute (SEI) at Carnegie Mellon® University. The SEI brought together representatives from academia, research, and industry to expose and promote practices demonstrated to be successful at avoiding the failures so beleaguering DoD software acquisition efforts. Carnegie Mellon’s framework of practices to address the DoD’s issue became the CMM. If we look at the genesis of the CMM, it predates the internet and nearly everything associated with internet technology. For that matter, CMM predates many software development, deployment, and infrastructure technologies, languages, and methods. We’ve all learned a lot in the past 20 years. When the DoD set out to address their “software dilemma,” the software world was different than it is today.

To color this context even further, everyone working to develop the initial CMM was looking for the solution to the “software problem” from the perspective that software is a component of a larger system and that if it failed, lives would be lost (e.g., aircraft, ships, weaponry, medical devices). Systems were evolved using careful and deliberate development paths according to lowerrisk, standardization-heavy and contractually-driven relationships between the developer and the customer.

In today’s frequent discussions of increasing globalization and the important role played by trust (i.e., level of social capital) in making effective collaboration happen across stakeholders, one might describe such a development context as exhibiting low trust. Users were typically not direct contributors to the evolution of the end product prior to field testing. They instead had to depend on the contracting relationship, requirements, and standards to deliver the product they needed.

This short history of CMMI focuses more on the past twenty years, but as in the case with Agile, the roots for many of the product development, project management, and process concepts found in CMMI have a long history. 7 This definition of trust may be clearer but more elaborate: “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the ability to monitor or control that other party” [Mayer 1995]. For the purposes of this report, the particular question being asked is whether there is a level of trust between the project and its customer that will allow them to effectively negotiate scope as the project progresses, without the customer requiring detailed accounts of project effort.

These comments may be an over-generalization, but they are intended to summarize the DoD software acquisition environment that existed at the time. Further, these comments explain why the practices in CMMI sometimes exhibit some of these same high ceremony and low trust characteristics found in the high-risk, government-contractor environment in which software failure could equal lives lost.Also, within the high-risk government-contractor environment at that time, the prevailing pattern of infrequent and monolithic deliveries contributed to the high costs associated with deployment, upgrade, and replacement (e.g., software embedded in fighter aircraft in the 1980s could not be upgraded over the air or over the internet). Hence, getting it right the first time was critically important.Furthermore, most of the organizations involved in this contractual environment were large organizations working on large complex projects.

Finally, the use of public money in government contracting (or similar high-visibility and highstakes situations) requires a level of accountability by all those involved that often drives all parties toward risk-averse behavior bordering more on protecting one’s own interests than on finding the most efficient win-win solution. Ceremonial but perfunctory activities help address the often competing and incompatible self-interests of all parties, but make operating in an open and transparent manner challenging, and reinforce the perception of low trust. Within a few short years, the CMM was expanded into several other models; these were point solutions developed to address non-software development projects. Also, the CMM and these variants increasingly became used internationally and by commercial industry. Organizations attempting to adopt more than one model on any given project quickly realized the challenges of
doing so and petitioned the SEI to consolidate the various CMMs into one model, which in 1998 led to a joint industry, government, and SEI team to create CMMI.

Of course, over the years that the CMM and CMMI have been maintained, inputs on what constitutes good management and development practice have increasingly come from a wider variety of industries and from users around the world. As a result, new ideas, standards, and practices are continually being incorporated into what is now the CMMI Framework.

The Origins Of Agile Methods

2010-01-04T01:45:00.000-08:00

The cornerstone of Agile methods originated long before the World Wide Web and collaborative technologies (e.g., wikis and instant messaging). This cornerstone is iterative and incremental design and development (IIDD), a method adopted by engineers over 75 years ago.

Early adopters of IIDD included Department of Defense (DoD) engineers who engaged in propulsion-related research and development, which included engineering activities tied to hardware not software. An early progenitor of IIDD was Dr. W. Edwards Deming who began promoting Plan-Do-Study-Act (PDSA) as the vital component of empirical engineering. Early adopters of Deming’s teachings in the aerospace industry include NASA (National Aeronautics and Space Administration) and the US Air Force, each of which developed entire systems using time-boxed, iterative, and incremental product development cycles.

As early as the mid-1950s, IIDD was used in software development resulting in business benefits such as “avoiding management discouragement” and “increasing customer satisfaction.” In fact, a large number of early software development projects, which were often experimental and explorative, shared many of the attributes of today’s Agile methods. However, in a systems world dominated by mainframes, COBOL (Common Business-Oriented Language), and the demand to process large and complex datasets, procedural top-down design and development methods dominated and were perceived by many to be the standard. This situation was influenced by the procedural nature of DoD standards and the proliferation of fixed-price contracts awarded to suppliers of complex DoD systems (the predominant consumer of computer software at that time).

In 1976, Tom Gilb argued that evolutionary development resulted in superior software delivery in his book Software Metrics and launched a movement toward agile, light, and adaptive development iterations that provided rapid results and more frequently visible business benefits. This short history of Agile methods is provided for the benefit of those who might mistakenly believe that Agile methods are a recent innovation without deep conceptual roots. For a complete history, there are books that describe the events of the past seventy-five years that also contributed to the success of Agile methods.
By their nature, the parties to fixed-price contracts assume an unchanging project scope in unvarying development and use environments. This nature makes it difficult to later modify project direction (without highceremony activities) to take advantage of newly-discovered needs and constraints or new technologies.

As the state of software engineering matured, more formal applications of IIDD became available for example, in Barry Boehm’s 1985 release of The Spiral Model of Software Development and Enhancement.

Throughout the 1990s, IIDD gained broad acceptance in the software community in various forms, including rapid prototyping, rapid application development (RAD), and rational unified process (RUP). The seeds of most modern Agile methods were sewn throughout this decade. While most may not expect it, innovative and Agile methods began in the large information technology (IT) shops of several large companies, including an automotive manufacturer and an overseas
bank. XP (eXtreme Programming) began at Chrysler Corporation in 1996 on a project staffed by IIDD advocates Ron Jeffries and Kent Beck, while feature driven development (FDD) started at United Overseas Bank in Singapore, one of Asia’s largest banks. With pair programming and refactoring as XP’s most celebrated features, XP became one of the most recognizable methods of the Agile family. Before the end of the decade, it was clear to many businesses and software engineers alike that in many settings, face-to-face communications, rigorous customer interaction, small rapidly moving teams, and frequent delivery of software ultimately produced superior software.

This enlightenment was occurring simultaneously elsewhere and so-called lightweight methods proliferated with names such as Scrum, Crystal, FDD, and others.
With the proliferation of IIDD methods came the need to coordinate and compare these methods by those interested in their growth and sustainment. The result of this need was a “meeting of the minds” among leaders who were principally responsible for the theory and application of each method.

A group of leaders met, including Kent Beck, Ron Jeffries, Alistair Cockburn, Jim Highsmith, Bob Martin, Mike Beedle, Ken Schwaber, Jeff Sutherland, and others who represented the most successful of the new lightweight methods. Modeling their meeting after an earlier meeting of XP enthusiasts in Oregon the year before, these leaders gathered in the Wasatch Mountains of Utah to ski, relax, and ultimately author the Manifesto for Agile Software Development.
A subset of the Manifesto authors, together with others like Mary Poppendieck, went on to form the Agile Alliance, a not-for-profit organization dedicated to encouraging the adoption of agile methods. The Agile Alliance primarily focuses on organizing the Agile Conference in the United States every year.

While even the organizers of the Utah event expressed skepticism of its outcome, the sessions were a success. The Manifesto documented the guiding principles of Agile development and defined a philosophy around a set of existing methodologies. While the first Manifesto for Software Development focused on programming, three years later original Manifesto authors Jim Highsmith and Alistair Cockburn gathered a similar group of early Agile adopters, including David Anderson, Mike Cohn, Todd Little, and others to establish a set of six management principles known as the Project Management Declaration of Interdependence (DoI) [Anderson 2005b]. The 15 authors of the DoI subsequently formed the Agile Project Leadership Network (APLN), a notfor-profit organization dedicated to encouraging better leadership and management in the IT sector and software engineering profession.

SOFTWARE ENGINEERING INSTITUTE. The Manifesto and Interdependence publications, books written by their original authors, the formation of not-for-profit organizations to promote the Agile approach, and the widespread use of the internet for research by software practitioners, has resulted in the rapid growth and broad adoption of Agile methods throughout much of the software engineering profession. Some methods, most notably Scrum, continue to grow beyond the software industry into professions that desire the benefits provided by the same basic IIDD concepts first pioneered by Deming and his predecessors.

A section of the book “CMMI® or Agile: Why Not Embrace Both” provides the basis for much of this article.

What is Capability Maturity Model (CMM)?

2010-01-03T16:11:00.000-08:00

The Capability Maturity Model (CMM) is a method for evaluating the maturity of the software development process of organizations on a scale of 1 to 5. The CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. It has been used extensively for avionics software and for government projects since it was created in the mid-1980s. The Software Engineering Institute has subsequently released a revised version known as the Capability Maturity Model Integration (CMMI).

Levels of the CMM

There are 5 levels of the CMM. According to the SEI, "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."

Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.
Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes.

Repeatable

At maturity level 2, Software development successes are repeatable. The organization may use some basic project management to track cost and schedule.
Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).

Defined

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods.
The organization's set of standard processes, which is the basis for level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization's set of standard processes according to tailoring guidelines.
The organization's management establishes process objectives based on the organization's set of standard processes and ensures that these objectives are appropriately addressed.
A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization's set of standard processes to suit a particular project or organizational unit.

Managed

Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications.
Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques.
A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Optimizing

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization's set of standard processes are targets of measurable improvement activities.
Process improvements to address common causes of process variation and measurably improve the organization's processes are identified, evaluated, and deployed.
Optimizing processes that are agile and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization's ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.
A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical predictability) to achieve the established quantitative process-improvement objectives.

Materials Resource Planning Software

2010-01-03T16:09:00.000-08:00

Materials resource planning (MRP) is a type of computer software that helps manage a manufacturing process.

The purpose of an MRP system is to reduce the cash needed by a manufacturing organization. This increases the organization's return on investment, directly making the manufacturer a more profitable, attractive investment.

In a classical manufacturing organization, huge amounts of cash are tied up in in-process inventory, parts, that must be assembled and then sold. MRP uses planning and management to reduce this cash to the minimum.

The basic idea is simple. A sales or marketing group estimates how many products it will sell at a future time. The MRP software back-dates using the factory's estimated time to assemble each product. Then, the system explodes the product into lists of parts needed, using the bills of materials developed by Engineering. The parts are ordered at times back-dated from the assembly dates. Finally, the cash flow of the above ordering, assembly, ship and payment process is developed.

The system provides reports about which parts are needed to ship an order. If a high-value order is waiting for a few cheap parts, the planner can ask for the parts to be flow in by air-freight, and usually this will improve profits and return on investment.

Inputs:

A sales estimate for each product.
A bill of materials for each product.
An assembly time for each product.
A complete on-hand inventory of all parts.
Estimated delays from order to receipt for each part, for each vendor that supplies the part.
Estimated prices for each part, by vendor and shipment method.
Inventory deposits and withdrawls.

Outputs:

Needed parts to complete a valuable order.
Invoicing or electronic data interchange to order parts early enough to meet sales forecasts.
Inventory management data.

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning."

- Rick Cook

Project Management - Basic Definitions and Objectives

2010-01-03T16:06:00.000-08:00

An alternate point of view is that project management is the discipline of defining and achieving targets while optimizing the use of resources (time, money, people, space, etc). Thus, it could be classified into several models: time, cost, scope and intangibles.

Project management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and productive mutual interaction of various parties in such a way that overall risk of failure is reduced.

What is a project?

Compare a project to say, a manufacturing line, which is intended to be a continuous process without a planned end.

Typical projects might include the engineering and construction of a building, or the design, coding, testing and documentation of a computer software program, or development of the science and clinical testing of a new drug. The duration of a project is the time from its start to its completion, which can take days, weeks, months or even years.

Approaches

Generally, there are two approaches that can be taken to project management today. The "traditional" approach identifies a sequence of steps to be completed. This contrasts with the agile software development approach in which the project is seen as relatively small tasks rather than a complete process. The objective of this approach is to impose as little overhead as possible in the form of rationale, justification, documentation, reporting, meetings, and permission.

In the traditional approach, we can distinguish 5 stages in the development of a project:

project initiation
project planning
project production
project monitoring
project completion.

Not all projects will visit every stage as projects can be terminated before they reach completion. Some projects probably don't have the planning and/or the monitoring. Some projects will go through steps 2, 3 and 4 multiple times.

Many industries utilize variations on these stages. For example, in bricks and mortar architectural design, projects typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. While the names may differ from industry to industry, the actual stages typically follow common steps to problem solving--defining the problem, weighing options, choosing a path, implementation and evaluation.

Project management tries to gain control over five variables:

time
cost
quality
scope
risk.

"Don't get suckered in by the comments... they can terribly be misleading."

- Dave Storer

Project Management Motivation Quotes

2010-01-03T08:46:00.000-08:00

Here you can find a list of some interesting, useful and motivation project management quotes. The favorite of mine is the first one.

If you aren't fired with enthusiasm, you will be fired with enthusiasm.
The perfect is the enemy of the good.
A little risk management saves a lot of fan cleaning.
A minute saved at the start is just as effective as one saved at the end.
A problem shared is a buck passed.
A project ain't over until the fat cheque is cashed.
A project gets a year late one day at a time.
A verbal contract isn't worth the paper it's written on.
Activity is not achievement.
At the heart of every large project is a small project trying to get out.
Estimators do it in groups - bottom up and top down.
Fast - cheap - good: you can have any two.
If an IT project works the first time, it is wrong.
If it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck.
If it wasn't for the 'last minute', nothing would get done.
If project content is allowed to change freely the rate of change will exceed the rate of progress.
If there is a 50% chance of something going wrong then 9 times out of 10 it will.
If there were no problem people there'd be no need for people who solve problems.
If you're 6 months late on a milestone due next week but really believe you can make it, you're a project manager.
If you can interpret project status data in several different ways, only the most painful interpretation will be correct.
If you can keep your head while all about you are losing theirs, you haven't understood the plan.
If you don't attack the risks, the risks will attack you.
If you don't stand for something, you'll fall for anything.
If you don’t know where you’re going, any road will take you there.
If you fail to plan you are planning to fail.
Sod's Law: It will go wrong in the worst possible way.
Managing IT people is like herding cats.
Metrics are learned men's excuses.
No plan ever survived contact with the enemy.
Overtime is a figment of the naïve project manager's imagination.
People under pressure do not think faster.
Planning without action is futile, action without planning is fatal.
The first myth of management is that it exists.
The more you plan the luckier you get.
The most successful project managers have perfected the skill of being comfortable being uncomfortable.
The most valuable and least used phrase in a project manager's vocabulary is "I don't know"
The most valuable and least used word in a project manager's vocabulary is "No".
The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.
The person who says it will take the longest and cost the most is the only one with a clue how to do the job.
The project would not have been started if the truth had been told about the cost and timescale.
The same work under the same conditions will be estimated differently by ten different estimators or by one estimator at ten different times.
The sooner you begin coding the later you finish.
The sooner you get behind schedule, the more time you have to make it up.
There's never enough time to do it right first time but there's always enough time to go back and do it again.
There are no good project managers - only lucky ones.
There is no such thing as scope creep, only scope gallop.
There is such a thing as an unrealistic timescale.
To estimate a project, work out how long it would take one person to do it then multiply that by the number of people on the project.
Too few people on a project can't solve the problems - too many create more problems than they solve.
Users get the systems they deserve.
Warning: dates in the calendar are closer than you think.
What is not on paper has not been said.
What you don't know hurts you.
When all's said and done a lot more is said than done.
When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.
Parkinson's law.: Work expands to fill the time available for its completion.
You can build a reputation on what you're going to do.
You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
Project management with lot of documents is not project management.
I love deadlines, I especially like the SWOOSHING sound they make as they fly past.
Time is the scarcest resource and unless it is managed nothing else can be managed.
The productivity of work is not the responsibility of the worker but of the manager.
The Pertinent Question is NOT how to do things right — but how to find the right things to do, and to concentrate resources and efforts on them.
The most efficient way to produce anything is to bring together under one management as many as possible of the activities needed to turn out the product.

Agile development methods and CMMI – Best Practices – Part 1

2010-01-03T03:06:00.000-08:00

Agile development methods and CMMI best practices are often perceived to be at odds with each other. If these perceptions or their causes are not resolved, we are likely to see more confusion and conflict as the adoption of each approach increases. In addition, each approach includes principles of good software development often overlooked but needed by the other approach thus being knowledgeable in both is important to project success. In the long term, this discordant situation is not healthy for the software engineering profession.

Why the discord between Agile and CMMI camps? The purpose of this report is to clarify why the discord need not exist and to ask for your help in making the software development community aware that, when properly used together, CMMI and Agile can dramatically improve performance. We believe there are two primary reasons for the discord between the Agile and CMMI camps:

1. Early adopters of both CMMI and Agile methods represent extreme examples of their software development paradigms. Early CMMI adopters were developers of large-scale, riskaverse, mission-critical systems, often with high levels of management oversight and hierarchical governance; whereas the early adopters of Agile methods generally focused on smaller, single-team development projects with volatile requirements in a software-only environment.

These two extremes set the tone for all that followed.

2. The inaccurate information about CMMI and Agile and the misuse of both resulted in misperceptions in both camps about the other. These negative perceptions that position CMMI and Agile at odds with each other arose largely from the following factors:

a. Misuse—two decades of experience, first with the Capability Maturity Model (CMM®) and then with CMMI models, in which practices were sometimes misused or applied to
(i.e., overlaid on) development activities that may have already been perceived by software development teams as productive without them

b. Lack of Accurate Information—a dearth of accurate information about CMMI in the Agile community and the corresponding dearth of accurate information about Agile methods in the CMMI community

c. Terminology Difficulties—the use of terminology in CMMI (e.g., discipline, quality assurance, and predictability) and Agile methods (e.g., continuous integration, testdriven development, and collective code ownership) that carries context-specific connotations and is thus easily misunderstood and abused

d. Top-Down Versus Bottom-Up Improvement Approach—the introduction of an approach that sometimes favors one “voice” (i.e., management versus practitioner) over the other, which neglects the other important voice in how to effectively run the business.

In this report, we identify and discuss the misperceptions we consider most damaging to a correct understanding of both paradigms, and suggest ways to improve our understanding of both of these powerful approaches for effective software development. In hindsight, we acknowledge that the way in which CMMI was developed and introduced may have helped cause some users to misunderstand the true message and nature of CMMI1. Such misunderstanding may have led to inconsistent and ineffective use of CMMI. Further, we identify common misperceptions in the Agile community about CMMI and common misperceptions in the CMMI community about Agile. In many ways, these misperceptions are related to the misuse of CMMI and Agile, but misperceptions can also be attributed to a shortage of accurate information as well as a persistent belief in notions and experiences that are not part of
either approach.

Some misperceptions of CMMI in the Agile community stem from aspects of the CMM that are no longer found in CMMI. CMMI includes many improvements2 that differentiate it from the CMM, which has not been updated since 19933. Some in the Agile community use CMM concepts to judge CMMI unfairly. For example, incorrectly referring to the goal of maturity level 2 as creating repeatable processes persists to this day. In some recent posts to a CMMI-related online forum, a few participants have admitted to not knowing CMMI like they know the CMM. Several participants continue their arguments by writing, “…but if CMMI is anything like CMM, then…” To complicate the problem, there are CMM users who never upgraded to CMMI and therefore persist in using a model that has a less flexible view of software and systems development than
the newer CMMI models. There are also former CMM users who upgraded to CMMI but persist in holding on to some of the more dated views from the CMM.

An important aside is that when practitioners are naming their activities, the labels “CMMI” and “Agile” are often applied too freely when practitioners are not following either approach properly.

These situations contribute to negative perceptions of both approaches.

We now know that CMMI and Agile can be used together successfully. Some of the references at the end of this report include experience reports about the successful use of these approaches together. The Software Engineering Institute (SEISM) continues to be interested in the development of Agile methods and in community experiences with both CMMI and Agile.

A section of the book “CMMI® or Agile: Why Not Embrace Both” provides the basis for much of this article.

Does Project Management Methodology Metter?

2010-01-02T16:17:00.000-08:00

Jesse Fewell posts a repeat piece about "Methodology Doesn't Matter." I've participated in the "method wars" in the past, with no progress. What I've come to understand through the school of hard knocks is that it's the outcomes we're interested in not necessary the path taken to reach those outcomes.

This removes all the theological issues around a method. But there is another important issue solved by this change in perspective.

When we focus on outcomes in place of focusing on the methods, we have made the connection to the business value. In some methods this connection has been made. The agile methods for example. For others, like Earned Value Management, the connection is juts now being discovered.

So what are the outcomes that are needed to make the connection to business value or mission success? here's my standard list.

Can we determine with some degree of confidence what the project will cost when it's done? How does this information match the expectations of the customer and their available funds?
The same answer for the duration? Can we determine the probability of completing "or or before" the need date for the project?
Can we discover, through some method or process, what the customer or funding agency considers "done." That is what are the capabilities that result from the project that allow the customer or funding agency to perform "their" job?
Along the way can we discover what impediments will impact our ability to answer the first three questions?
Can we determine with some degree of confidence that we are actually able to answer the previous 4 questions?

So if you can answer these 5 questions – with the proper degree of confidence - then "How" you answer them - that is what method you is to answer them - is not as important.

The inverse is also true. When ever there is a proposal to change a method, improve the process through a new method, augment the existing paradigm - one that may or may not be working, or conjecture any "new idea" - ask the following:

Does this thing that is being suggested provide improved information to these 5 questions? If yes, this is a desirable approach. If no, you're wasting your time.

Critical Path and Estimates

2010-01-01T03:50:00.000-08:00

Critical Path Method (CPM) is based on two false ideas:

The task duration estimates are accurate;
That the plan (derived from these estimates) can be executed in a deterministic manner, including the idea that variation in task duration does not happen.

This is an argument by obversion. This means "let me speculate that you'll do something stupid and then point out that you're doing something stupid."

We have a saying in the large project management world...

...don't do stupid things on purpose.

This would include:

Stupid Thing #1: Estimating task durations that are not probabilistic or risk adjusted - taking a single value and assuming it represents reality:
- Pick your favorite probability distribution - mine is the Triangle
- Pick a risk adjust percentage spread from the "most likely" duration
- Apply these upper and lower estimates and run a Monte Carlo simulation to expose the sensitivities of the plan to duration estimates
Stupid Thing #2: Treating the CP as something that is fixed - once identified, the CP is fixed for the duration of the project.
- Although I can't believe I'm saying this, this is one of the reasons formal project management training adds value to the software development business. When you have a PMP or even sit through a formal project management training class, you'll learn that the Critical Path is a "conversation" starter.
- The CP is the "current" sequence of tasks that take the longest to execute. The Critical Chain - from the Theory of Constraints - uses this concept, so does the probabilistic models produced by Monte Carlo.
- But no trained project manager would consider the CP to be fixed. In fact we produce a new CP ever Monday morning when the BCWP numbers come in from the week before.
- The CP changes with every updated assessment of "actual" progress.
- A "test question" you might ask yourself on a project is "what is the sequence of work that results in the longest duration for the project?" This is the critical path. If you arrange or re-arrange this work into a shorter path, that would be a useful exercise. In order to determine is you have the shortest path already, you need to do some analysis of this "path."

Time Boxed Scheduling

Many have conjectured that CP is not very useful in a "time boxed" approach to software development. And they are mostly correct. Fixed iterations have little need for "path analysis."

Build and manage the queue of features to be fed into the front of the "time box" machine, get the working code out the back in two to four weeks. From within the time box this works well. From the outside if and only if the work fits inside the time box AND if the amount of work can be known in some way (what is the population of features needed for the system to be useful) and this list is bounded in some way (we've run out of money, stop) then the total duration of the project can be estimated for those on the outside looking in asking annoying questions like:

How much will this cost in the end?
When will you be done spending my money?

The nice thing of course is that "some" of the features can be put to work generating benefits. Again If and Only If, they are carefully planned to do so in some manner suitable for the business to absorb their operational in a benefit producing way - but that another "planing" discussion for a later time.

All of these "time box" concepts are great concepts and actually work - If and Only If the two conditions hold:

Work fits inside the time box or can be partitioned to fit inside the time box, so that when it exits it is done forever and actually provides bookable benefit in some unit of measure recognized by the funding agency (person, system or banker)
Work entering the time is bounded in some way, so the number of time boxes can be estimated for the completion of the project. Although you could make the case that continuous maintenance is unbounded - but in most organizations I've worked the money is not unbounded.

This approach is the core of agile development. It is also the core of other approaches used in many other industries and has been shown to work time and time again - therefore is a logical approach when the two conditions can be met.

If they can't be met, then something else needs to be used to estimate the total duration of the project - the Critical Path.

So Why Is There So Much Misunderstanding About These Topics?

In theory there is no difference between the theory and practice, in practice there is.

In practice the CP methods provide insight into the complexities of projects.

Applied with understanding and skill CP is a powerful tool to sort out what is the impact is the sequence of work on the completion date of the project.

The site “Herding Cats” provides the crucial part of this article.

The Best Articles Submitted to Carnival of Project Management for December/January Edition

2009-12-31T02:31:00.000-08:00

Here is the round-up of the best project management articles submitted to the Carnival fro this December/January Edition:

Elyse Nielsen at Anticlue,post is called Taming Chaotic Project Management - Dealing with Changing Priorities posted at Anticlue, saying, “Prioritization is the art of choosing what not to do, and it is hard for organizations without good business governance to choose what not to do. If you find yourself dealing with changing priorities, here are 5 tactics you can deploy.”

Gilad Lev-Shamur presents What are the 5 basic rules of project management? at a relatively new blog called The Project Management’s Thinker. Not a particularly grammatical title, but it’s good that there are new project management blogs entering the field, and this one looks promising.

Here is another relatively new site, aimed at contract project managers: Steve has been putting some final touches to Contractor Project Manager over Christmas, and the site looks great. He submitted Advice on becoming a PMO/Project Management Assistant, so if any of you are looking for a career change in the new year, this could be a good starting point.

GeekMBA360 presents Is team work overrated in corporate environment? posted at GeekMBA360. A controversial post that I don’t agree with - in a project environment I believe team work is essential. Granted, there are always people who don’t pull their weight, but bad management (or absent/ineffective management) are equally to blame for allowing these situations to continue. Projects are done with teams, therefore teams are important.

SpiKe presents Productivity Down! An Emergency Response Guide posted at Organize IT. A good post on getting going again when you can’t get a grip on what needs to be done.

Finally, here are two posts about public speaking, which I thought were interesting especially as I have just read Scott Berkun’s excellent book, Confessions of a Public Speaker. First, GreatManagement presents How to use the audience for dramatic effect when public speaking posted at GreatManagement Blog, saying, “Many of us would love to start mastering public speaking. One particular technique that works wonders in any public speaking engagement is to involve the audience.” He goes on to discuss how this can be done.

Second, CA has The presentation secrets of Steve Jobs posted at Atlantic Canada’s Small Business Blog, saying, “The glowing feedback after my next presentation indicated to me that following the steps outlined in the book helped. If I can do it, so can you. Here are four tips that, if you adhere to, will ensure your presentation will be a success. To provide some context, my presentation shared the results of a project with senior management.”

That concludes this edition. Submit your blog article to the next edition of carnival of project management using our carnival submission form. The next Carnival will be the February/March edition (regular Carnival followers will know that we are down to bi-monthly Carnivals now) and will most likely be back at the Carnival’s permanent home, A Girl’s Guide to Project Management.

This post was taken from site: PMtips.net

7 Project Management Tips for Satisfied Customer

2009-12-31T00:49:00.000-08:00

The concept of customer satisfaction is make or break. It is the basis of your livelihood. If you’re independent, it means the difference between a referenceable customer and a dissatisfied customer. If you’re working for an organization and dealing with internal customers and/or external clients, then customer satisfaction over time may mean the difference between keeping your job or updating your resume unexpectedly.

PM have the bull’s-eye firmly fixed on their head. Often times they are the highest priced resource on the project and many times the customer sees us as the hardest expense to justify. Here are six ways to keep Project Managers ‘relevant’ on a project….

1. Lead weekly status calls
Every PM on every project should be responsible for leading weekly customer calls and documenting discussions, action items, issues, etc. and re-sending this all back out to the relevant project team members on both sides within the next 24 hours following the weekly call. I find that clients are happy with this approach and they know that everything was captured accurately when they review the notes and issues.

2. Produce weekly status reports
In advance of the weekly status call - preferably at least 24 hours in advance - produce and deliver a detailed status report to the customer and project teams on both sides. The status report should be the basis for the weekly status call and should be reviewed and updated on each call.

3. Deliver revised weekly project plans
At the same time the weekly status report is being revised and delivered to the project team and the client, the project plan must also be revisited, revised and delivered - preferably in both .mpp and .pdf format so users without MS Project can view the plan. A good project manager is reviewing and revising the plan almost daily, but an ‘official’ revised plan should be delivered to the customer each with the status report and reviewed as part of the weekly status meeting.

4. Stay on top of project issues and risks
At a minimum, at the kickoff of a project, gather the project teams together on both sides - assuming a customer-facing engagement - and brainstorm the risks. Document these well using a project register of your choosing…usually a simple Excel spreadsheet will do. Identify the likelihood of the risk as well as the potential impact to the project (budget, timeline, success, etc.) if the risk is realized. Also identify any risk mitigation actions that can or will be taken to avoid the potential risk.

Ideally, this risk register will become part of your weekly status report going forward and will be something that the teams re-visit weekly on the status call. At an absolute minimum, the Project Manager must review the register (and update it) regularly and bring items to the attention of the teams as any risk possibilities arise.

5. Ad-hoc communication with the customer
I’ve mentioned the weekly status calls and the delivery of the weekly status reports and revised project plans/schedules. That’s a given. However, the real communication with your project team as well as with the customer’s project team often happens as ad-hoc communications. This can be by phone, IM, email, etc. This is where the quick, but critical, status alerts happen. As the Project Manager, you must be prepared to share risks, bad news, alerts, changes, etc. with the customer in a very timely manner (after, of course, verifying all info and clearing critical info with executive management). This will gain customer trust and definitely help to ensure that evasive action is taken as quickly as possible when problems arise. It’s never ok or a good option to bury your head in the sand.

6. Be an activist for your project team
As the PM, one of your primary concerns is to remove any roadblocks your project team members encounter. If you have a Business Analyst onsite with the customer performing a design walkthrough and the server is down, you must be ready to get your IT support staff on it and escalate it to whatever exec necessary to get the server up and running. This is just one example, but the general idea is that proactiveness is key to customer success and satisfaction.

7. Keep the executives ‘undented’
My belief is that your tenure as a PM is directly tied to how ‘undented’ your executives are from your customers’ issues. This is probably obvious to everyone, but I just have to say it. The absolute worst thing you can have is your CEO, CTO or PMO finding out about a customer problem from the customer and not from you. Proactiveness with the customer, swift info dissemination to the customer and to your executive staff, and aggressive issue resolution and action will give you the greatest job security. You want your CEO calling you to congratulate you on a successfully run implementation, not asking you why he’s just now hearing about issues with Customer X.

How to Close Down the Project Properly

2009-12-30T23:44:00.000-08:00

A lot of text and attention is given to how to start projects, and how to run projects. But process of properly closing down a project is overlooked. Reasons are:

Implementation and transition to support happened so moving on seems reasonable
Have 4-5 other projects I’m also managing
Just received a new, hot project and I’m preparing for kickoff
Problem-free implementation means no worries, right?

Look at that list…none of them are good excuses for just basically dropping the ball – and the customer – post-deployment. Things still need to happen, proper hand-offs may still need to be taken care of, information needs to be transitioned. It will happen anyway through frantic phone calls and emails, so why not take care of it in an organized fashion? Because we say we’re too busy…but that needs to change.

Here are the list of five key activities that should happen to ensure proper closure of the project you’ve just finished. Your list may differ and I’d love to hear from you if it does.

Make sure all pertinent documents and deliverables have been signed off by the customer. You don’t want this coming back to you after the project is over – especially if there are any question marks our payments outstanding.
Get a final signoff on implementation/solution acceptance. You may have the best relationship in the world with your customer, but don’t skip this step.
Conduct a lessons learned session with the customer and your team. The information you glean from this type of session can be invaluable to you as a project manager going forward, to your customer as they go forth with the implemented solution, and to your tech support as they provide the ongoing support for the solution with the customer.
Hold a proper handoff to tech support. Make sure they have all necessary information in order to properly support the client post-deployment.
Keep in touch with the customer post-deployment. You may have a 30 or 60-day agreement to remain available to the customer and for your team to remain available before the formal transition to tech support. But don’t just drop them at that point, keep checking back. It’s good for your reputation with the customer and for your company’s reputation.

This post was taken from site: PMtips.net
The author is:
Brad Egeland
IT/Project Management Consultant
email: brad@bradegeland.com
website: www.bradegeland.com

Strategy of Project Delivery

2009-12-30T04:23:00.000-08:00

The purpose of strategy is to provide direction and concentration of effort as organizations continually strive to improve their position or gain the upper hand within the marketplace. Basically, it’s a struggle for advantage, and the one with the best advantage wins. It’s that simple. On what areas must businesses concentrate? Businesses clearly have to:

Gain new advantages that increase or improve customer satisfaction, which will differentiate them from their competitors
Either eliminate or minimize their competitors
Achieve speed to market
Re-engineer business processes for improved competitiveness
Align their organizations to the latest economic trends
Implement the strategy through projects
Evaluate the success of the strategy by measuring project success

From project management’s point of view, there is no need to manage any project if the project manager has no idea why it’s being done in the first place. It’s crucial for any project manager to address the larger issues of the business strategy and see where the project fits in the overall framework. It isn’t easy—but it needs to be done.

Therefore, organizations must focus on project management as the key business driver that will achieve these advantages for them. With sound project management methodology and processes in place, project management is able to support the overall business strategy of an organization with these logical benefits:

1. Reduced delivery costs. Project management can provide products and services more cheaply by following a structured and formalized project methodology and by ensuring that excessive costs are not spent without due consideration.

2. Quicker product to market. The advantage permits the business to deliver products or services more efficiently than the competitors and the business is able to react more favorably to market demands.

3. Focused advantage. The projects will be focused more on the client needs and products, instead of having a solution that does not deliver the expected returns.

4. Quality and timely deliverables. Project management builds quality into the products or services right from the start, ensuring that the right things are developed at the right specification.

5. Proven customer advantage. Project management gains advantages for their organization by working together with the customer and by accommodating their needs and requirements.

Summary

Today’s organizations are challenged, as they need to keep pace with competitive markets, client needs, and marketplace trends. Winning is basically about who has the upper hand - either with new technology or quicker project implementations. The only winners will be those executives who are able to reinvent their companies quickly enough to take full advantage of the efficiencies that solid project management practices can offer.